It is possible to generate distributed applications run in different tiers, by using the
.Net remoting communication protocol between them
A model with the following objects will be generated:
Running on client side: a main Work Panel (Wkp01) calling a procedure (Prc01) to add records in a table, passing as parameters all data in order to make the insertion in the table.
Running on the application server: the procedure made by insert on the table.
Note: Client and application server will be simulated in the development equipment.
Three-tier application will be run by using IIS.
-
Create a prototype / production model by selecting:
§ Language: .NET
§ User interface: Win
-
Setup Dbms Options properties:
§ Access technology to set: ADO.NET
§ Database name: <Database name>
§ Server name: localhost
§ Use trusted connection: No
§ User id: user
§ User password: password
-
Setup execution properties:
§ Compilation = csc.exe (Ander framework installation directory)
-
Run database creation (the database created is supposed to exist)
§ Build / Create Database
-
Setup model properties
Into the “General/.NET specific/ADO.NET specific” section set:
§ Protocol: Using .Net remoting
§ Application Server host: http://localhost/3tierNET (“3tierNET” is the name of the virtual directory to be created in ISS, which points at <Application directory>\DATAXXX\srv )
§ Multi tier location: appserver
6. Setup programs that will be run in the server:
-
-
The procedure that will be run in the application server must have the following properties setup:
§ Main program = True
7. Generate programs:
§ Build / Build All
8. Compile and execute
§ Run execution dialog (F5). Compile main objects that you have
§ Create 3tierNETvirtual directory pointing at <Application directory>\Dataxxx\srv )
§ Execute Work Panel (F5). To execute the Workpanel from outside GeneXus you must just click on the executable file created in “dataxxx/bin” model directory.)
In this case, it is necessary to take into consideration that everything that is generated in the following directory:
<Application’s directory>\DATAXXX\bin – is everything that matches up with what is run in the client.
<Application’s directory>\DATAXXX\srv – is everything that matches up with what is run in the server
A distributed system is based on the concept of logically distributing the execution of an application that may also be physically distributed or running in the same PC.
The main idea of a distributed system is the logic division of the application in several tiers, so as to distribute the responsibility of executing specific tasks in each of them. In this case, distributed applications will be based on a 3-tier architecture; that is to say, each one of the tiers will be specialized in executing specific tasks.
The first tier has the application components that implement the application interface with the client (Presentation Tier). The second tier has the components in charge of executing the application business logic; that is to say, everything related to the system behavior (Application Server). The third tier has the components in charge of performing data handling and persistence (Database Server).
Unlike traditional Client/Server applications (2 tiers), where the application of the entire application code (business logic) is performed in the client, in 3-tier applications the code is distributed; a portion is executed in the client and the other portion in the applications Server. This allows gaining scalability, security and performance, as shown further on in this document.
It’s suitable to say that in an architecture like this one, the application Server may also communicate with other application servers thus distributing the responsibility for the services provided to the client. In the same way, the database Server does not necessarily be just one, there may be several servers.
In this type of architecture, clients communicate with the applications server through a specific communication protocol, according to the application language and the server used. In turn, the applications Server communicates with the database through a specific communication protocol or driver according to the DBMS used.
The communication modality between the client components and the applications server is performed with
.Net remoting, which implies the creation of messages traveling under HTTP or TCP (.Net Channel Services) for the information transportation.
The communication modality between the database server and the application Server is through
ADO.NET
Generating 3-tier applications is only possible using ADO.NET as database connection method. Generating a 3-tier application using ODBC is not possible
Besides, 3-tier applications can be generated only with Win Interface. Generating 3-tier applications using Web Interface is not possible.
This property allows defining if the application will be generated in 2 or 3 tiers. If you choose the latter, you must select the communication protocol between the client and the server that you will be using.
Values
Using.Net remoting – The application is being defined in three tiers
No – The application will be generated in two tiers. This is the default value
Default value: No
Application Server Host
It allows specifying the reference to the “host” where the applications server is running.
Values
Default value: Anyone
In case of modifying Channel ref ="tcp” the application Server host must be specified under the same protocol.
Multi tier location
It specifies the name of the “Location” where the remote part of the application will be run
The remote part of the application consist of the accesses to the database and the objects logic will be executed in the client or the Server, according to the object properties settings. Specifically, to execute procedures and/or reports logic in the server, you will have to setup the ‘Location’ property with the value specified in this model property.
Values
Any logical name may be specified for “Location”;
Default value: Appserver
Location
This property allows defining, at main procedures and reports level, whether the object is generated to be executed completely in the applications Server, which means that not only the database accesses but also its entire logic and the logic of the objects called by it will be remotely executed.
If no Location is defined to an object, it is assumed that it will be executed in the caller Location; therefore, there is not need to define Location for each one of the procedures and reports of the calls tree since by defining the main and location of the first one, all the other will take this value. Therefore, since an object can be called by different objects, this object may sometimes be entirely executed in the applications Server (i.e.: remotely) while in other cases part of it may be executed in the client and the database access in the applications server, depending on the caller Location.
The calls tree must not have objects with interface, such as a call to a work panel or a transaction in a procedure defined as remote or called by another remote procedure. Take special care to this situation, since it may cause an error or it may be visualized in the applications server (where the object is being executed) but not in the client.
Values
The value is a logical name. If it coincides with the value of the modelo Multi tier location, property, then the corresponding object runs in the server; otherwise, it runs in the client.
Optimize for multi tier location
This property allows defining if the transaction rules are executed in the client and not in the applications server
In 3-tier application by default all the rules of the transactions are executed at the server. But the transaction may have certain rule that generates some type of user interface (for example that it calls a work panel or a screen report). In this case it can’t be executed at the server and this property allows executing it at the client.
Values
Yes: All the rules of the transaction are triggered at the server
No: All is triggered at the client, including the code that access the database
Default value = Yes
Execute load events in application server
Allows executing the load event of a work panel at the server.In three tiers application by default the load event of the work panels are executed at the client.
Configuring this work panel property, it is also possible to determine if all the Load event logic will be automatically executed in the server as the accesses to the database do.
When working in a distributed application, as a general rule to achieve a good performance you must try to execute as much code as possible
in the applications server; basically, you should execute everything but the interface in the applications server. This is why this property exists, to delegate the entire work panel Load event logic execution to the applications server.
Values
No: The logic executes in the client and only the database accesses executes in the server.
Yes: Executes all the load event of the work panel in the server, both the logic and the database accesses.
Default Value = No
Considerations
If this property has value “Yes”, you must take into account certain programming points of the Load event.
Since this property indicates that the Load event will be executed in the applications server, nothing related to the interface can be programmed there; e.g.:
Calls to a work panel form control method
Change of work panel form properties
Calls to other programs with interface, such as a “call” to another work panel or transaction
On generating the model, the required objects are created according to the object type.
<Application Directory>\DATAXXX\bin – is everything corresponding to what is executed in the client
< Application Directory >\DATAXXX\srv – is everything corresponding to what is executed in the server
Every generated component is a .Net (
Assemblies) component that follows the “Factory Design Pattern” standard.
Only one “Factory” object, which is shared by all the clients (Singleton), is published in the applications server. This allows the client accessing the remote object and activate it (Client Activated Objects–CAO), using two methods: getProcedure and getDatastore. The applications server is in charge of keeping them alive while there is frequent interaction between the object and the client
As two clients access the same object, a new object instance is created in the applications server. There is no reuse criterion as in COM+ objects pool; i.e.: an object is used by a client until it does not need it any more.
Below, you will find details about settings for each one of these cases, with possible values for the Application server host property.
In order to run an application by using IIS as application server, you must Create a virtual directory called "VirtualDir" targeting the “srv” directory, under the model
There follows a description of IIS use characteristics:
-
The server is automatically started up by aspnet_wp (or w3wp) upon the first request.
-
It is restarted each time web.config is modified. This is the configuration file containing all the information on the application server, the database connection and other. This file is located in “dataxxx\srv” model directory.
· If processes take more than 90 seconds (timeout by default), they hang up giving timeout error. For this not to happen, you must setup
Http Execution timeout in the “web.config” file with a higher value.
If you choose using GeneXus applications Server, there are two ways of starting it:
Console
The server must be started up by running GxDotNetAppServer.exe, found in: <Model’s directory>/srv/bin.
The messages output is in the console and in the client.log file.
Windows service
The first time, it is necessary to install it with the following sentence:
installutil GxDotNetAppServerWinSrv.exe
This executable is found in: <Model’s directory>/srv/bin.
Then it must be manually started up and handled such as any Windows service
Error messages output is through the event viewer and the client.log file.
In both cases the service must be halted when recompiling objects.
GeneXus applications Server reads its settings from the “server.exe.config” file. This file contains from the application host information to the database connection data. It is located in “dataxxx\bin” model directory.
Running it under IIS is probably the most comfortable option when working in prototype, because it is the simplest way. Furthermore, security from the IIS itself is ‘inherited”.
In this case, update of dll versions may be performed without downloading service, because aspnet_wp is in charge of this.
Performance is one of the disadvantages, since it may turn out to be a bit slower than other options.
The best performance in remoting occurs with TCP communication and binary format; the lowest with HTTP and SOAP format.
Under IIS there is HTTP communication with binary format or with SOAP format; the former would be “intermediate” in terms of performance.
The format is configurable in the “server.exe.config” or “web.config” file, and it is a binary format by default.
Another point to take into account is providing some tolerance or failure system if you have it as console or Windows service, which is not necessary with IIS.
That is to say, if the service hangs up for some reason, it must be manually started up when using console or Windows service. When using IIS, aspnet_wp must be automatically raised in the next request.
One of the advantages of implementing a 3-tier application is the possibility of managing database connections in a more centralized and under-control way, since it is not accessed from the client, like in a 2-tier application, but from the applications Server. For this, you can use a database connections pool.
A connections pool is a limited group of connections to a base, handled in a way that these connections can be reused by different users. This pool is managed by an applications server that assigns the connections as the clients make queries or data updates.
In.NET applications with access to SQL Server or Oracle, which use ADO.NET as data access protocol, the pool is managed by the framework using ADO.NET "Connection Pooling".
You can modify the values of the connections pool setup by default. For this, you must setup the “Additional connection string attributes” property of the DBMSs within “Properties/Access technology settings/Connection information”.
The following properties are available in the connections pool provided by ADO.NET:
· Connection Lifetime
· Connection Reset
· Enlist
· Max Pool Size
· Min Pool Size
· Pooling
For example, you can setup the “Additional connection string attributes” property with:
Enlist=true;Max Pool Size=40
Connections pool properties are always separated by semicolon.
If a connection reaches a specific time non-configurable without activity (30000 milliseconds), it is returned to the connections pool.
For further details on this feature and on how to setup the properties you can access the following pages:
SqlServer and
Oracle
Web.config
It has the settings about the location of the applications server, when using IIS.
It is located under the “Dataxxx\srv” model directory and its structure is similar to the following:
<configuration>
<configSections>
<datastores>
<appSettings>
…
<add key="NAME_HOST" value="http://jlarrosa/rotulos"/>
<add key="SPONSOR_LIFETIME" value="420"/>
<add key="SPONSOR_RENEWONCALL" value="300"/>
</appSettings>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http">…
<lifetime leaseTime="5M" renewOnCallTime="2M" leaseManagerPollTime="10S"/>
<service>
<wellknown mode="Singleton" type="com.genexus.distributed. …i="factory.rem"/>
</service>
</application>
</system.runtime.remoting>
<log4net threshold="OFF">
<system.web>
<trace enabled="false"/>
…
</system.web>
</configuration>
Messages format
<channel ref="http">
<serverProviders>
<formatter ref="binary"/>
</serverProviders>
</channel>
The “formatter ref” can be "SOAP" if the “channel ref” is “http”.
server.exe.config
It has the settings about the location of the applications server, when using GeneXus application server.
It is located under the “Dataxxx\srv\bin” model directory and its structure is similar to the following:
<configuration>
<configSections> …
<datastores> …
<appSettings>
<add key="NAME_HOST" value="http://jlarrosa/rotulos"/>
<add key="SPONSOR_LIFETIME" value="420"/>
<add key="SPONSOR_RENEWONCALL" value="300"/>
</appSettings>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http">…
<lifetime leaseTime="5M" renewOnCallTime="2M" leaseManagerPollTime="10S"/>
<service>
<wellknown mode="Singleton" … ="factory.rem"/>
</service>
</application>
</system.runtime.remoting>
<log4net>
</configuration>
Messages format
<channel ref="http">
<serverProviders>
<formatter ref="binary"/>
</serverProviders>
</channel>
Channel ref can be ="tcp" (not for IIS),
The “formatter ref” can be "SOAP" if the “channel ref” is “http”.
Client.exe.config
As detailed in the
two tiers model, this file has information on the model properties and the log. In distributed applications, it does not have information on the database connection, but information is added on the channels, singleton objects (Factory) and format as well as on relevant properties such as the location of the applications server and keep alive.
The structure is similar to:
<configuration>
…
<appSettings>
<add key="NAME_HOST" value="http://localhost/srv"/>
…
<add key="KEEP_ALIVE_INTERVAL" value="90"/>
</appSettings>
<system.runtime.remoting>
<application>
<channels>
…
</channels>
<client>
<wellknown type="com.genexus.distributed. … url="http://localhost/srv/factory.rem"/>
</client>
</application>
</system.runtime.remoting>
<log4net threshold="OFF">
….
</log4net>
Proxy Handling
The following applies when there is a Proxy between client and application server.
Default setup files do not have any information setup about Proxy.
For setting up Proxy in the client (Internet options), and for the communication to work, you must setup the following in client.exe.config, depending on the following cases:
· Client and application Server in the same LAN:
<channel ref="http" port="0" proxyName="" >
<clientProviders>
<formatter ref="binary"/>
</clientProviders>
</channel>
This way, access will not occur through the Proxy setup in the Internet options.
· Client and application Server in different LAN:
<channel ref="http" port="0" useDefaultCredentials="true" >
<clientProviders>
<formatter ref="binary"/>
</clientProviders>
</channel>
This way, the Proxy is accessed by setting up Internet options.
The labels previously mentioned are “Case Sensitive”; this means that they must be written respecting upper and lower case. For example: proxyName.
The .Net platform does not use the registry and allows setting up the dll versions to be used; therefore, installing the application consists just in doing a xcopy of the following:
- bin directory for the client
- srv directory for the applications Server
The generator provides a tool, Publication Assistant, to perform the automatic Deploy of the client part.
Application server
- .Net Framework Redistributable
- Access to a Database server
- IIS or GeneXus application server
Client
- Visual J#
- .Net Framework Redistributable