Deployment mode of Up ! Virtual Technical Machine

Deployment Mode of Up ! Virtual Technical Machine

Classical Deployments of Up ! Virtual Technical Machine

If you use one of the folliwng offers:

then it is mandatory to first deploy Up ! Virtual Technical because they are grounded on this last one.

What ever the deployment mode you choose:

Any program of Up ! Application System, in standard delivered or developed in Up ! 5GL, is an assembly of modules at the time of running. The minimum modules to create a subssystem are: To that is added the main module of one application. In the following examples, it is name as MyModule.

The initialization file to execute the main module is given by the file:

Starting-Up the Main Module

The life-cycle of execution of the application is:

To do this, it is needed to activate an intermediate code between the operating system and the application. This is the adaptor of Up ! Modules Manager for the target operating system.

Executable Program

When you generate with Up ! Compiler a native executable program from some source files written in Up ! 5GL, the adaptor of Up ! Modules Manager is included into the produced executable.

The adaptor of Up ! Modules Manager for the target operating system is automatically activated.

The application is compiled with:

upscmp.exe Source=MyModule Prm=...

The application is started with:

MyModule.exe Prm=...

Interpreted Program

When you make interpreted by Up ! Script Engine the source files of a program written in Up ! 5GL, the adaptor of Up ! Modules Manager is included into the executable of Up ! Script Engine.

The adaptor of Up ! Modules Manager for the target operating system is activated automatically.

The application is started with:

upssng.exe Source=MyModule Prm=...

Interactive Program

When you start Up ! Shell, you are in direct interaction with Up ! Virtual Technical Machine and you can invoke all of its Application Program Interfaces (API) through a command in Up ! 5GL.

More over, you can dynamically load a module written in Up ! 5GL into the virtual machine, may it be compiled or interpreted, and then invoke its API through a command in Up ! 5GL.

The adaptor of Up ! Modules Manager for the target operating system is activated automatically.

The most frequent used modules are declare into ${UPS_HOME}/upssdk/sources/${UPS_LANGUAGE}/upsshl.upl.

The application is started with:

upsshl.exe Prm=...

A less frequent used module is declared while typing to the console:

ImportModule MyModule(<MyModule.upi>, ImportDefinitions);

Here are some commands:

SystemDate();
1.0+Cos(Pi);
ChangFolder("/tmp");
ListFiles("/tmp");
ListProcesses();

Module Loaded Dynamically

When you generate with Up ! Compiler a dynamic native module from some source files written in Up ! 5GL, the adaptor of Up ! Modules Manager is not included into the dynamic librairies that are produced.

The adaptor of Up ! Modules Manager for the target operating system must be explicitly activated.

upssng.exe Source=MyModule Prm=...

The application is compiled with:

upscmp.exe Source=MyModule Prm=...

The application is started with:

upsmmr.exe Module=MyModule Prm=...

Subsystem

A subsystem is a set of processes sharing a pool of resources. These processes are isolated from other processes.

The advantage of partitionning computers into subsystems is:

The disadvantage of partitionning computers into subsystems is:

Up ! Object Management System allows an automatic partionning into subsystem and also the automatic management of implicit synchronizations to access in an optimized way to shared resources. For the particular cases, Up ! System offers some explicit synchronizations via the type Synchronization.

Isolated Subsystem

By default, each application of Up ! Application System is running into their own subsystem. This is the case for Up ! Compiler for example.

When the application is simple or when the execution time is relatively short, this choice is judicious.

The application is started by:

MyModule.exe Prm=...

Shared Subsystem

When the application is complex because it beholds numerous tasks or when it is a server continuously running, it may be interresting to create a specific subsystem to share tasks or somes resources. This decreases work load on computers.

The life-cycle of execution of the application becomes:

Except for a particular case, any programs can be runned into a shared subsystem.

The subsystem is started with:

upssrv.exe Kernel=my-sous-system.ini Server=upssrv Prm=...

The application is started with:

MyModule.exe Kernel=my-sous-system.ini Server=upssrv Prm=...

Service-Oriented Architecture

Up ! Application System is based on the concept of Service-Oriented Architecture.

Bus in Up ! Object Request Broker Technology

The mecanisme to call services from Up ! Virtual Machine is set up by Up ! Object Request Broker. It is very easy to set up because you only have to use the remote access operator:

Here is a small example to copy a file from a host named SunSolaris:

Source Component "Example of remote access" Version 1.0.0;

Main
Variable

Debut
MyServeur=Server("SunSolaris", "UpsKrn");
/* Localization of the server. */
F1=File("c:/autoexec.bat", ReadingText);
F2=File@MyServer("/tmp/autoexec.bat", WritingText);
/* Open the remote file. */
Size=256;
While Size==256 Do
End While
File1.Close();
File2.Close();
End Main

The remote access can be applied to any call (procedure, function or method), any type and any object (module, warehouse, exception and variable). The localization of the server is done by Up ! Object Request Broker and the communication is made by Up ! Network.

Some Application Program Interface (API) of Up ! Application System support moreover the remote acces into the values of their parameters. This is especially the case for the ones that handle names of files or folders. Thus, to copy a file from a computer to another one, the previous example is not the more powerful. You should only use CopyFile of the module Up ! System that supports remote access for its parameters:

CopyFile("c:/autoexec.bat", "/tmp/autoexec.bat@SunSolaris");

Bus in Third-Party Technology

Up ! Application System is also compatible with the third-party technologies following:

This is done thanks to the adaptors to integrate services in order to either:

These technologies can be mixed inside the same application.

To know how to create an client or server adaptator for a module, you will be please to refer to the page Distributed modules.

When the application is a services provider, it is most of the timer possible either to include Up ! Virtual Technical Machine into the process of the client application or to isolate it. For further precisions, you will be pleased to refer to the guide for deploying each technology.

Internet, Intranet or Extranet Server

Up ! Application System is also a server for the following Internet, Intranet or Extranet technologies:

For the content management, it is possible to: