Creating multi-tier information systems using MIDAS by Natalia Elmanova

By: David Intersimone

Abstract: Using MIDAS is a very effective way to solve many problems with data access maintenance in client/server systems. Multi-tier systems with MIDAS are easy to configure, maintain, and upgrade.

Creating multi-tier information systems using MIDAS

Natalia Elmanova

Note: The following paper was presented at the 1999 Inprise/Borland Conference in Philadelphia Pennsylvania. Click on the source code link to download the examples used in this paper.


This session is devoted to creating multi-tier information systems with Inprise MIDAS (Multi-tier Distributed Application Service Suite). Using MIDAS is a very effective way to solve many problems concerning data access maintenance in client/server systems. Multi-tier systems with MIDAS are easy to configure, maintain and update.

This technology and software are designed to maintain remote COM and CORBA data access servers created with C++Builder or Delphi. In most cases these servers provide their clients with an access to SQL servers, but it is possible to use any DBMS as a data source.

MIDAS Development Kit is a part of Delphi Client/Server Suite and C++Builder Enterprise. You can use it to develop data access servers (but not to deploy them).

The questions to be discussed are:

1. Why is it advantageous to use distributed computing?

2. When can the Automation be used to create a data access server?

3. How to create a data access server?

4. How to create a thin client using sockets?

5. Using Active Forms

6. Creating a Java "thin" client

7. Using a briefcase model

8. How to organize a multi-user data processing in a multi-tier information systems

9. Creating additional methods of Remote Datamodules

10. The referential integrity of data

11. Different Service Control managers: using DCOM and OLEnterprise. When must directory services be used?

11.1. Using DCOM

11.2. Using OLEnterprise

11.3. Using sockets

11.4. Using CORBA

12. How to deploy "thin" clients and data access servers

12.1. How to deploy clients

12.2. How to deploy data access servers

13. Possible troubles with the use of MIDAS

14. Different architectures of multi-tier information systems

15. Creating Web MIDAS applications with Delphi 5

16. Acknowledgements

 

 


1. Why is it advantageous to use distributed computing?

This section describes problems of data access support and fail-over safety of information systems, as well as the ways of solving these problems, including the use of multi-tiering.

The “classic” two-tier client/server information system contains:

  1. A database server for managing a database which contains tables, indices, triggers, and other objects for storing data and business rules;
  2. One or more client applications which contains the user interface (forms, etc.), the code for data processing and data access, and, in most cases, data access libraries (Fig. 1).

Fig. 1. Standard two-tier information system

In most cases, client applications use directly DBMS client API calls (for example, by using Oracle Call Interface, etc.) or by means of intermediate libraries, such as Borland Database Engine (BDE). Therefore, the client application requires a DBMS client software to be installed and configured. In addition, it often requires BDE to be installed and configured too. It is possible that the client application requires the use of ODBC drivers. So, usually the system administrator or software developer must take care of:

1) installing the DBMS client software and configuring it for a successful database server access;

2) installing BDE and SQL Links, configuring database drivers, creating and configuring aliases;

3) installing ODBC drivers and ODBC administrator, describing ODBC Data sources;

4) and, finally, providing enough resources for data access. ODBC driver, some libraries from BDE and SQL Links, DBMS client software libraries must stay in memory while the client is working with data; so they require some resources of client workstation.

If we want to deploy our client application by creating installation with InstallShield Express, we can solve correctly only the second problem. In most cases, we can’t include DBMS client software into this installation, because we must buy and use DBMS vendor installations and follow the license agreements. In many cases, we must also install ODBC drivers separately.

Let us assume that we have solved all these four problems. What happens if the chief system administrator decides to change DBMS server IP address after configuring all data access software at thousand workstations?

The reality is that the more complicated the software configuration is, the more often it is destroyed spontaneously. Reconfiguring and supporting software spends your time (three days or more per workstation during a year), and money.

It seems strange, but there is another problem connected with a very high popularity of Delphi, C++Builder, and Borland C++ (opinion polls show that more than 60% of developers use these tools in Russia). There is a lot of different commercial software, which uses BDE (reference books, directories, guides, etc) in the market now. In this case, there is not any guarantee that the BDE version installed with this product is up-to-date or at worst it is not older than the BDE version used in your information system. There is also no guaranty of the correctness of this installation. For example, it can replace all BDE configuration files and registry entries. It is against the rules, but, unfortunately, it happens very often… And, of course, Your client applications may begin working improperly (or, very likely, may become non-functional at all) after installing such software over them.

I know many cases of producing such software. One of my colleagues (he is a software developer from one of the European countries) told me an "unsuccess story". In his country a telephone directory written with Delphi 2 was released as CD. Delphi 3 was released when this CD was being produced. So there had been some information systems developed with Delphi 3 before this telephone directory CD become available. Shortly after releasing this CD, many of client applications of information systems written with Delphi 3 began to work improperly. The reason was that the users of these information systems have installed the telephone directory from this CD, thus replacing their BDE with its older version. Who do you suppose these users claim the rights to? Please believe me, it was not a phone directory developer… It was Delphi 3 programmers who received much reclamation from their customers! The main argument of reclamation was that this phone directory was on sale in all shops, so it seemed to be a high-quality product. My colleague, who told me this story, received such reclamation, because he used the latest Delphi version.

What should be done for this problem not to arise at all? We can, certainly, use Delphi 1 or Delphi 2, but it is not a good way (and somebody can produce such "phone directory" by Borland C++ 4.5 with BDE being older than in Delphi 1.0).

We have not yet discussed many other problems connected with high network traffic due to a database growth. They can be partially solved using SQL servers instead of desktop or network file-oriented databases, but in some cases these problem cannot be solved on the whole. Neither have we discussed the problems of using some shared resources (for example, a high-speed multiprocessor server that can process data more effectively than client workstations). Neither have we considered the problems linked to territory scattering of some enterprises (it is a typical situation in gas and oil mining plants in Siberia), or to low quality of flow lines (another typical situation for gas/oil plants: the flow line was destroyed by landrover, it needs to be repaired, but now it is a long polar night and blizzard - and users do not know what to do with their cached updates…).

So, as a rule, software developers and system administrators have a serious headache due to installing, configuring and maintaining data access software, preventing the users from "phone directories", and solving other problems described above. How to get rid of this headache?

The guillotine can be a solution of a headache problem (it seems to be too radical, but works for sure). In this case, it means that we use guillotine to split our client application up into two parts. These parts are appreciably different in their interface and functionality.

The first part contains only the users interface (forms, etc.). We can call it a “thin” client. It must be installed on user workstations. It does not contain BDE (or BDE replacements), ODBC, and DBMS client software.

The second part is a data access server. It has a minimal user interface (or it has no user interface at all). But it is a real client of SQL server, so it uses BDE, DBMS client software, and possibly ODBC. It must not be installed on user workstations, and it can exist on one or several computers in a local area network. You can configure your network to prevent a direct user access to the corresponding directories of these computers. This part can also implement the functionality different from the data access (for example, calculating something, generating repots, etc.). In this case we can think of it as a functionality server. Data access is, undoubtedly, one of the possible functions of such servers.

There can be a lot of "thin" clients in the information system. As for data access servers, there must be a few of them (1,2,3…). They can be installed on computers, which are under the system administrator control and are inaccessible for other users.

"Thin" clients do not obtain data from the database server directly by client API calls or using BDE. Instead of obtaining data directly form the database server, they obtain data from the data access server, which is a data source for them. The data access server gets client queries and connects to the database server with its own query, because it is a real client of the database server. After obtaining the query result, the data access server passes the requested data to the "thin" client.

In this case, the client software of DBMS server, ODBC drivers and BDE (or any BDE replacement) should not be installed at user workstations. The “thin” client needs the only library to support obtaining data from the data access server (in MIDAS case it is dbclient.dll). The “thin” client must also “know”, where the data access server is, and what its name (or GUID – Global Unique Identifier, or UUID – Universal Unique Identifier) is. Or, in a general case, it must know where the directory service, which must find a computer with server implementation, is.

Therefore, our information system becomes a 3-tier, and the data access server is a middle-tier in it. We can say that it is a middleware server implementing the middleware service(s) (Fig. 2).

Fig. 2. A three-tier information system

2. When can the Automation be used to create a data access server?

This section describes different ways to create a distributed data processing system. It also describes the conditions under which the use of OLE Automation for creating data access servers is reliable.

How to realize this technology in practice? There are many ways to do it.

All these ways are based on the old idea of RPC and marshalling. Marshalling is a data packet exchange between an object inside the client application (it is called a client stub or a proxy) and another object inside the server process (it is called a skeleton or a server stub). The particular terminology depends on the technology implementing the distributed computing.

The server stub is created inside the server process when the server receives a client call. It represents the client in the server process, so the server “thinks” that it works with its local object. There can be one or many such stubs. Their quantity depends on the number of clients, share rules, etc. Client stub is created in the client process. It represents the server in the client process, so the client also “thinks” that it works with its local object. It usually has the same list of methods as the corresponding server stub, but it never contains their real implementation. Instead of real implementation it may contain a special proxy code, for example, with API calls to libraries responsible for creating data packets, marshalling them to the client by any possible way (for example, writing to sockets, etc.) and unmarshalling other packets with the results of requests and queries, which are received from the server stub (Fig. 3).

Fig. 3. Remote procedure calls

In particular, distributed computing can be based on DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), etc., and in these cases we can choose a non-Windows platform for server and client.

But if it is desirable to make Windows distributed applications without spending a lot of money, we can use COM, and remote Automation in particular (of course, it is based on the same idea of RPC and marshalling). Automation allows us to operate some applications (they are known as Automation servers) by other applications (they are known as Automation controllers). Automation servers must expose some methods for such operation.

In this case, we can create our data access server as a remote Automation server. This Automation server can create remote COM objects inside its address space, and these COM objects must contain data access components and interfaces to reach them. In this case, we can use Windows for both a client and a server application.

3. How to create a data access server?

This section contains a detailed example of building data access server with a Remote Datamodule containing several tables.

To create a data access server, we must have any DBMS with some tables. Our example uses Oracle Workgroup Server 8.0.4 for Windows NT, but it does not matter what DBMS is used (you can even use dBase or Paradox tables of DBDEMOS database).

To illustrate this, we must create a new database user (if we use Oracle, we must grant roles CONNECT and RESOURCE for it), login to the server as a new user, and copy CLIENTS.DBF and HOLDINGS.DBF tables from DBDEMOS database to Oracle by means of the Data Migration Wizard. Now we are ready to create our data access server.

Let us create an ordinary form, which must be an indicator of a server being running. So it must not be large, and it is better to place it on the screen corner and set its FormStyle property to fsStayOnTop (Fig. 4).

Fig. 4. The main form of the data access server

It should be mentioned that it is not necessary to create the main form at all, because most of such servers do not have any user interface. However, we have already created the main form. So let us place the TLabel component on it and set its Caption property to "0" . This label will be used later as a client counter. Let us also place the TDatabase component on this form and set its properties, as shown in Fig.5:

Fig. 5. TDatabase properties of the main form

It is necessary to uncheck the Login Prompt checkbox and to enter the password value into the Parameters list. Why is it so important? Because the user access dialog must appear in a database client application. It means that it must appear in a data access server, but not in a "thin" client application, which is actually controlled by the user. However, in a general case a client application and a data access server can be executed on different computers (and, possibly, in different countries!). Therefore, we must prevent the appearance of this dialog by all means.

It does not mean, of course, that the user access to the database with the user name and password is impossible in a 3-tier system. We shall discuss this task later.

Then let us open the Object Repository of Delphi or C++Builder and choose the Remote Data Module icon (Fig.6).

Fig. 6. Choosing Remote Data Module from Object Repository

Remote Data Module is a COM object, and it can provide interfaces, which are used by its clients.

After choosing the Remote Datamodule icon from the Object Repository, the Remote Data Module Wizard must show us its dialog. We are to type the Class Name for storing information about this server in the Registry. All COM servers are to be registered in the Windows Registry, because COM uses it as an implementation repository and an interface repository.

We must also select how many instances of Remote Data Module our server can create. The Multiple Instance option (it is the default option) means that the server can create many instances of Remote Data Module. The Single Instance option means that the server can create only one instance of Remote Data Module, so it is necessary to run a separate server instance for any client. The Internal option is not interesting for this case. It means that we must create a DLL, and it would be difficult to make the server to be remote in this case (some possibilities of creating such remote servers will be discussed later).

Then we can place two TTable components to our Remote Data Module. Let us bind them to the TDatabase component placed on the main form earlier, and set their TableName properties to CLIENTS (Table1) and HOLDINGS (Table2). Let us also place the TDataSourse component and bind it to the Table1 component (Fig.7).

Fig. 7. Components in Remote Data Module

The next step is to create a Master-Detail relationship between these tables (the ACCT_NBR field is a common one for both tables).

Now our project contains the following parts (Fig. 8):

Fig. 8. Data access server project

Thereafter, we can right-click on the Table1 component and select an Export Table1 from data module option from the pop-up menu.

Now the properties and methods for the data access are available to clients in the COM object interface. You can open the Type Library editor and find them. Type Libraries store an interface definitions for COM objects, and they are often used in COM servers (and, sometimes, in COM clients, Fig. 9):

Fig. 9. The Type Library of the Remote Data Module

In a general case, it is reliable to store the GUID (Global Unique Identifier) of MyRDM CoClass in a text file somewhere in a shared network disk, because we shall use it later.

Then we must refer to the main form in the RemoteDatamodule unit. Now let us create two event handlers of the Remote Data Module to update the client counter placed on the main form. C++Builder code for these handlers is:

void __fastcall TMyRDM::MyRDMCreate(TObject *Sender)
{
Form1->Label1->Caption =
IntToStr(StrToInt(Form1->Label1->Caption)+1);
}
//------------------------------------------------------------
void __fastcall TMyRDM::MyRDMDestroy(TObject *Sender)
{
Form1->Label1->Caption =
IntToStr(StrToInt(Form1->Label1->Caption)-1);
}

The corresponding Delphi code is:

procedure TMyRDM.MyRDMCreate(Sender: TObject);
begin
Form1.Label1.Caption := IntToStr(StrToInt(Form1.Label1.Caption)+1);
end;

procedure TMyRDM.MyRDMDestroy(Sender: TObject);
begin
Form1.Label1.Caption:= IntToStr(StrToInt(Form1.Label1.Caption)-1);
end;

(We have used bold characters for parts of these event handlers, which must be typed manually).

Now we can save, compile and run the server. As a result, it must have been automatically registered in the Windows Registry (You can use Regedit utility to check it). Now it is ready for use.

What is the main part of this data access server functionality? SQL queries are. Our server uses the Borland Database Engine to generate them. In a general case, such servers can use other ways to generate SQL queries.

It was mentioned above that the main form is not an essential part of the data access server. Such servers can be made as a console application or as a Windows NT service. In a general case such servers can be created for non-Windows platforms. It is clear that in these cases GUI may be unavailable at all.

 

4. How to create a thin client using sockets?

This section contains a detailed example of creating a "thin" non-configurable client with TCP/IP access in the form of a Windows application. This example must contain a TClientDataSet component with a "nested" table emulation for representing a master-detail relationship.

Let us make a client application. For example, let it use the TCP/IP protocol to reach the server.

First, we must run Borland Socket Server (scktsrvr.exe) in Delphi 4Bin or CBuilder4Bin (it is also available as a service, if necessary) at the PC, where our data access server must be running. Later we shall discuss the role played by such services, and why we must use them.

Second, let us create a new project. It is possible to do it using both the server computer and any other computer. Of course, the client PC and server PC must be able to reach each other via the TCP/IP protocol.

Third, we must place the TSocketConnection component on the main form and set its Address property to IP address of the server PC. Instead, you can also use the Host property of this component. Please note that we can face some troubles in a network with DHCP servers. These troubles will be discussed later.

Then let us open the saved file with the server GUID and copy a string with a saved GUID to the ServerGUID property. If you use the server PC, ServerName must be automatically filled. If you use another computer, the ServerName property may remain empty. In a general case, such client can connect to the data access server through the Internet, and the server must not be registered in the client computer Registry. So the client PC may "know" nothing about the server name and its GUID.

The next step is to try to set the Connected property to True. It must lead to an automatic server startup. The Delphi or C++Builder IDE is now a client of the data access server. Now our connection counter must be equal to one.

Fourth, we must place the TClientDataSet component on the client main form and set its RemoteServer property to SocketConnection1. Then we must place the TDataSource component on a form and bind it to the TClientDataSet component.

TClientDataSet is used to cache data obtained from the data access server. It is a TDataSet object, so it has all methods for navigating and editing data. Moreover, this component has also the SaveToFile and LoadFromFile methods to store this cache in a file. Therefore, it can implement a "briefcase model". It means that the “thin” client can edit data in the off-line mode and occasionally connects to the server to upload the edited data or to download the new data.

Now we can choose the ProviderName property of the TClientDataSet component from the list of available values (in our case it contains the only Table1 value). Then let us set the Active property of the TClientDataSet component to True.

Fifth, we can place the necessary DataControls components on the client form (Fig.10).

Fig. 10. The main form of the client application

It should be pointed out that the TClientDataSet component could contain a cached data of two or more tables, which are linked in a master-detail relationship. In this example, CLIENTS table and HOLDINGS table are linked in a master-detail relationship established in our data access server. This results in the TClientDataSet component in the client application containing all fields corresponding to the real CLIENTS table fields, and, in addition, a new TDataSetField corresponding to the related detail records in the HOLDINGS table. In other words, TClientDataSet emulates “nested” tables, which in other cases are available only in object-oriented databases, such as Oracle 8.

Client datasets store both the original uploaded data in their Data property and the change log in their Delta property. To initiate uploading the edited data from the change log the ApplyUpdates method of the TClientDataSet component must be used. This method takes the changes in the change log and sends them to the data access server. This method has an integer parameter, which indicates the error tolerance to permit before canceling the update process.

Why are the potential server errors foreseen? Because generally the client application cannot have a complete information about the server constraints and other business rules; for example, it can know nothing about the new primary key values, which appeared in the time period between downloading the original data and uploading the changes. Therefore, only an attempt of uploading edited data can show that some business rules were violated.

Therefore, we must create two event handlers for buttons placed on the client form. The C++Builder code for these handlers is:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
ClientDataSet1->ApplyUpdates(-1);
}
//------------------------------------------------------
void __fastcall TForm1::Button2Click(TObject *Sender)
{
ClientDataSet1->CancelUpdates();
}

The corresponding Delphi code is:

procedure TForm1.Button1Click(Sender: TObject);
begin
ClientDataSet1.ApplyUpdates(-1);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
ClientDataSet1.CancelUpdates;
end;

Now we can start our application. Please look at the server main form: connection counter must be equal to two. The first client is the IDE; the second client is our running application (Fig. 11).

Fig. 11. The "thin" client at runtime

Let us click on the Table2 column. We can see that the secondary form with the corresponding detail records appears. These records can also be edited and uploaded by the ApplyUpdates method.

Please note that we can use the SQL Monitor utility to trace SQL queries produced by the data access server. SQL Monitor must be running at the server PC.

If you want to deploy your client application to another PC, you must also deploy dbclient.dll to this PC. It must be placed to the WindowsSystem directory or to the client executable directory. Borland Database Engine, ODBC and DBMS client software must not be deployed to the client PC at all, because the “thin” client does not use them. So workstations with such "thin" clients are very easy to configure, and they require less resources than workstations with standard client applications using BDE, ODBC and DBMS client software.

5. Using Active Forms

This section contains an example of creating a "thin" non-configurable client as an Active Form, and using it as a part of a Web page.

Another type of “thin” clients is an Active Form client. In many cases, it is very convenient to use and deploy.

It was mentioned above that “thin” clients are easy to configure. So it is possible to deploy them both by means of creating installation and through the Intranet (or Internet). The web server can be a source of new client application versions, and the web browser (MS Internet Explorer 3.0, 4.0, or Netscape Communicator equipped by the necessary plugins) can be a tool for installing and executing them.

If we want to deploy such “thin” clients, we must be able to upload files to any Web server, for example, to the Internet Information Server for Windows NT. It is also possible to use any other Web server, operated by any operation system, because it is used only as a file supplier. In a general case, it is possible to place the “thin” client, the data access server and the Web server in three different countries.

How to make such ActiveX client? First, we can select all controls of our client application, and select the Component/Create Component Template option from the IDE main menu (Fig.12):

Fig. 12. Creating component template from the client components

Let us accept the default values of all parameters. Therefore, we have created a new component template - TSocketConnectionTemplate. Now we can close the client application project.

Second, let us open the Object Repository and choose the ActiveForm icon from the ActiveX page (Fig. 13):

Fig. 13. Choosing the ActiveForm icon from the Object Repository

In the ActiveForm Wizard dialog, we must type the COM class name for our ActiveX object and the project name for an ActiveX library (Fig. 14).

Fig. 14. ActiveForm Wizard

It is better to check the Include Version Information checkbox. Then we can press OK. Now we have obtained an empty "form" of our new "thin" client. And, at last, let us place our TSocketConnectionTemplate on this "form".

Such active forms allow placing on almost all components from the component palette, except the TMainMenu component. But if you categorically insist on using it, you can, of course, use many labels and pop-up menus instead.

Once the Active Form has been designed, we must set the web deployment options for it. So we must select the Project /Web Deployment Options... from the IDE main menu, and fill the dialog appeared. Target Dir is the name of the directory for our ActiveX library from the point of view of Web server administrator (for example, it can be a local directory or a shared LAN directory). Target URL is the name of the same directory, but from the point of view of a "guest" of the Web server. HTML dir is a directory where HTML file with the reference to the ActiveX library must be placed. The Use CAB file compression option is used when we want to decrease the load time of our ActiveX library through the Internet (Fig. 15).

Fig. 15. ActiveX Web Deployment Options

We must also include dbclient.dll into our deployment. If we have used the Build with Run-time packages project option, we must also include these packages into the deployment. They must be added using the Additional Files tab and the Additional Packages tab.

The Include File Version Number option is good to select, if we want our library to be automatically upgraded in a user PC, when the user visits the page referring to this library, and its Versioninfo resource is not the same as in its previous downloaded version.

To deploy this library, we must select the Project /Web Deploy option from the IDE menu. The deployment files must be created and transferred to the Web server. This deployment includes an HTML page with a reference to our ActiveX (by <OBJECT> tag). It is generated by IDE and its name is the same as the library project name. It can, of course, be edited to satisfy your needs.

Now we can open this page in MS Internet Explorer using any PC connected to the Web server, and test it (Fig.16).

Fig. 16. An Active Form in MS Internet Explorer 4

Please note that the Internet Explorer properties must differ from the default values, because its user must permit this ActiveX to be executed. It is desirable that this ActiveX library be code-signed. We shall discuss these details later.

6. Creating a Java "thin" client

This section describes a possibility of using MIDAS client for Java.

Another way to create a "thin" client is to write it using Java. It allows us to use non-Windows operation systems at workstations.

For example, we can use JBuilder 2 Client/Server and the MIDAS Client for Java (JMIDAS) components, which are the set of Java Beans. This set includes the CorbaConnection component and the ClientDataSet component.

Our server project created before is accessible via DCOM or sockets. However, Java clients must be cross-platform applications. So it would be better for them not to use COM, because COM is a Windows-specific technology for distributed computing. We can use CORBA instead of COM. CORBA is a cross-platform technology for distributed computing, and Delphi 4 or C++ Builder 4 allows us to create CORBA MIDAS servers.

So before creating a Java "thin" client let us make a copy of the MIDAS server project and then modify it. The first, we can turn the COM server created with Delphi into a CORBA server using the appropriate option of the pop-up menu of the Code Editor containing the Remote Data Module implementation unit. Some lines of code will be added automatically to this unit in its initialization section:

TCorbaVclComponentFactory.Create('rdmd4Factory', 'rdmd4',
'IDL:pmid/rdmd4Factory:1.0', Irdmd4, Trdmd4, iMultiInstance,
tmSingleThread);

Now we have a server object, which is accessible via COM and CORBA.

Second, let us delete the DataSource1 component from the Remote Data Module. The ClientDataSet component of the current version of JMidas does not support the nested table emulation. Therefore it is better to create a master/detail link between tables at a client application. So we must also export the detail table from the Remote DataModule. Now we can save and compile our server application and close the IDE.

Before creating a Java client, we must make our server accessible. At first, we must start the VisiBroker Smart Agent at the server PC. It is a special CORBA service, which provides access to CORBA servers. Thereafter, we can run our CORBA server. It allows us to use the application server interface while the client application is being built.

Now let us run JBuilder with the JMidas installed and begin to create a Java client. First of all, we must connect to the MIDAS server. Let us create a new application in JBuilder (by using File/New/Application option from the JBuilder main menu) and accept all defaults. Then we must click the Frame1 item from the AppBrowser and choose the Design tab.

Now we must drop the CorbaConnection component from the MIDAS page of the Component palette into the Component Tree. Then let us click on a button near the connectionDescriptor property and answer the questions of the appropriate dialog.

The Repository ID value can be copied from the code generated in the Implementation unit of the CORBA server. In our case it is 'IDL:pmid/MyRDMFactory:1.0'. The Object Name is the name of our COM/CORBA object, and the Host Name is the name of PC where our CORBA server is running.

Then we can try to connect to our server. If the test is successful, we can see that our connection counter increases and decreases immediately (Fig.17).

Fig. 17. Testing connection with CORBA server

Now we must drop two ClientDataSet components into the Component Tree. Then we must click on a button near the clientDataSetDescriptor property of theClientDataSet1 and ClientDataSet2 components and answer the questions of the appropriate dialog (Fig.18).

Fig. 18. Setting ClientDataSet properties

Then we must click a button near the masterLink property of the ClientDataSet2 component and fill the appropriate dialog. We must select the ClientDataSet1 component as the Master Dataset (Fig.19).

Fig. 19. Setting Master-Detail link between ClientDataSets

Now we can test the link.

If the test proves to be successful, we can create the user interface of our Java client. For example, we can place two NavigatorControl components and two GridControl components to our frame and bind them with the corresponding ClientDataSet components. The result is shown in Fig.20.

Fig. 20. A Java “thin” client at runtime

7. Using a briefcase model

This section describes how to organize editing data in the off-line mode with the deferred uploading to the database server. It also describes some ways of using client datasets in 1-tier and 2-tier systems.

The TClientDataSet component is an intellectual cache “manager”. It can store the metadata associated with the cached tables. It also stores all history of editing data in the cache.

In addition, the TClientDataSet component has the SaveToFile and LoadFromFile methods for saving to and retrieving from files the cached data downloaded from the database server through the data access server. These methods can be used by different ways. For example, a user can connect to the data access server, download some data, save it to a file, take his notebook home (or to a business trip, etc.) and begin to edit this data separately. He can periodically save edited data to a file, and retrieve them to continue editing. He can also return to his office, connect to the data access server and try to upload his data retrieved from a file. This way of processing data is known as a “briefcase model”.

The next idea of using the TClientDataSet component is to download data to a ClientDataSet cache, save them to a file, and then forget about the database server and the data access server at all. We can, for example, make a "phone directory" or another reference book by this way. We must only write our client executable, dbclient.dll, and the "briefcase file" with a stored cache to a CD, and this reference book does not require BDE to be installed!

It is also good to use the ClientDataSet component in two-tier systems. In this case, we can emulate nested tables using the server tables linked by a master-detail relationship. We must only place the TClientDataSet and TDataSetProvider components on a form or on a Datamodule and bind them to each other.

Another way to use client datasets is to store locally lookup tables, which are updated rarely. It reduces the network traffic and allows the client application to work faster. It is also possible to create calculated fields in such datasets.

The TClientDataSet component has also the AddIndex and DeleteIndex methods. It allows re-sorting data in the cache without sending additional queries to the database server.

 

8. How to organize a multi-user data processing in multi-tier information systems

This section describes how to handle the OnReconcileError event to correctly resolve possible collisions caused by simultaneous editing the same data by several users.

Let us discuss a typical case of simultaneous editing the same record by two users. In 1-tier and 2-tier systems, we can use locking records or pages. In these cases, the first user can edit a record, and the second user must wait until the first user releases this record.

In a 3-tier system, it is impossible to use locking. If the briefcase model is used, the possible time delay between downloading record for editing and uploading the edited record back to the database can be very long. Therefore, the multi-user data processing in 3-tier systems differs from the traditional one.

During uploading the edited data to the database server, the actual version of the uploaded record stored in the database is compared with its previously downloaded version stored in the client dataset cache. If these versions are different, the OnReconcileError event of the TClientDataSet component occurs.

Why can these versions be different? Because two or more users may create their own locals copies of the same record and edit them separately and differently. Let us suppose that two users have edited the same record and then try to upload their edited versions of it. The first user can do it without any problem. However, the second user must be notified that somebody has already changed this record.

To provide this notification, we must handle OnReconcileError event of the TClientDataSet component. This event occurs when another user changes an uploaded record during the time period between downloading it, and uploading its edited version from the cache back to the database. The simplest way to handle it is to use the ReconcileError Dialog from the Object Repository.

Let us open our previous project created in the part 4. Then let us open the Object Repository and choose the Reconcile Error Dialog icon from the Dialogs page. A new form will be added to our client application (Fig. 21).

Fig. 21. Reconcile Error Dialog from Object Repository

Then we must refer to the new form from in the main form unit of our project. We must also move our ReconcileError Dialog to the Available Forms list in the Project options dialog. Otherwise, it would appear immediately on a client startup.

Then we must create the OnReconcileError event handler of the ClientDataSet1 component. The C++Builder code for this handler is:

void __fastcall TForm1::ClientDataSet1ReconcileError(
TclientDataSet *DataSet, EReconcileError *E, TUpdateKind UpdateKind, TReconcileAction &Action)
{
Action = HandleReconcileError(Owner, DataSet, UpdateKind, E);
}

The corresponding Delphi code is:

procedure TForm1.ClientDataSet1ReconcileError(DataSet: TClientDataSet; 
E: EReconcileError; UpdateKind: TUpdateKind; var Action: TReconcileAction);
begin
Action := HandleReconcileError(DataSet, UpdateKind, E);
end;

HandleReconcileError is the method of the Reconcile Error Dialog.

Let us compile and save our client application. Then let us run it twice. In both instances of our client, we can change the same record in different ways. Then let us try to apply updates from both instances of the client application. The first attempt will be successful. The second one will lead to the appearance of the Reconcile Error Dialog (Fig. 22):

Fig. 22. Reconcile Error Dialog at runtime.

The grid in this dialog contains the values, which have initiated the collision. They are the old value and the value to be uploaded. The second user can decide what to do with this record (to edit, to upload though a collision, etc).

We must note that the detail records in "nested" client datasets can also be processed by the same event handler if such collision occurs.

Of course, you can change the Reconcile Error Dialog and its unit to satisfy your needs.

 

9. Creating additional methods of Remote Datamodules

This section describes how to make a user registration in a "thin" client and to transfer the user name and password to the SQL server through the data access server by creating new methods of Remote Datamodules.

Remote Data Modules are COM objects. Therefore, we can create additional methods for them using the Type Library Editor. Let us create a method for the user access verification when connecting to the database server.

It is obvious that we must now place the TDatabase component on the Remote Data Module, because now all its instances must use their own database connections instead of the only connection they share. The user name and password are the properties of this TDatabase component.

We must also place the TSession component on the Remote Data Module and set its AutoSessionName property to True. Then we must select the SessionName property of the TDatabase component for it to be the same as that of the TSession component. It prevents possible collisions of different database connections (Fig. 23):

Fig. 23. Modified Remote Data Module with non-shared database connection

Now we can set the TDatabase component properties. We must leave the User Name and Password blank (Fig. 24):

Fig. 24. Database properties for Remote DataModule with Login method

Now we must set the DatabaseName properties of TTable components to the TDatabase component name. Thereafter, we can delete the old TDatabase component from the main form, because we do not need it now.

Finally, we can create the Login method of the Remote Data Module. Let us open its type library and create a new method of our COM object (using the New/Method option of the pop-up menu of its interface).

The parameters of this method are the user name and password. We must choose the Parameters tab, press the Add button twice, and rename the parameters created. Their type must be WideString in the case of Delphi and BSTR in the case of C++Builder (Fig. 25):

1162y.gif

Fig. 25. Describing the Login method in the Type Library

After pressing the Refresh button we can open the implementation unit of the Remote Datamodule and add the implementation code of the Login method. The C++Builder code of this implementation is:

STDMETHODIMP TMyRDMImpl::Login(BSTR username, BSTR password)
{ 
try
{ 
 m_DataModule->Database1->Connected=false;
 m_DataModule->Database1->Params->Values["Password"]=password;
 m_DataModule->Database1->Params->Values["User Name"]=username;
 m_DataModule->Database1->Connected=true;
 m_DataModule->Table1->Open();
 m_DataModule->Table2->Open(); 
}
catch(Exception &e)
{ 
return Error(e.Message.c_str(), IID_IMyRDM); 
}
return S_OK;
};

The corresponding Delphi code is:

procedure TMyRDM.Login(username, password: WideString);
begin
Database1.Connected:=false; 
Database1.params.Values['Password']:=password;
Database1.params.Values['User Name']:=username;
Database1.Connected:=true;
Table1.Open; 
Table2.Open;
end;

Now we can compile and save our server.

Let us change our client application. We can create a new form, which must be the user access verification dialog (Fig. 26):

Fig. 26. User access verification dialog

The PasswordChar property of the Edit2 component is to be set to *. We must also refer to the main form in this unit.

Let us create the OnClick event handler for the Connect button. The C++Builder code for this handler is:

void __fastcall TForm2::Button1Click(TObject *Sender)
{
Form1->ClientDataSet1->Close();
Form1->ClientDataSet2->Close();
Variant svr=Form1->MIDASConnection1->AppServer;
svr.OleProcedure("Login",Edit1->Text,Edit2->Text);
Form1->ClientDataSet1->ProviderName="Table1";
Form1->ClientDataSet2->ProviderName="Table2";
Form1->ClientDataSet1->Open();
Form1->ClientDataSet2->Open();
}

The corresponding Delphi code is:

procedure Tform1.Button1Click(Sender: TObject);
begin
Form1.ClientDataSet1.Close;
Form1.MIDASConnection1.AppServer.Login(Edit1.Text,Edit2.Text); 
Form1.ClientDataSet1.ProviderName:='Table1';
Form1.ClientDataSet2.ProviderName:='Table2';
Form1.ClientDataSet1.Open; 
end;

Now let us change the main form of client application. We must refer to our user access verification dialog. We can also place a new button on our main form and set its Caption property to "Login". Then we can create the OnClick event handler for this button:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
Form2->ShowModal();
}

The corresponding Delphi code is:

procedure TForm1.Button3Click(Sender: TObject);
begin
Form2.ShowModal;
end;

10. The referential integrity of data

This section describes how to use business rules in "thin" clients.

In the case of using SQL servers, business rules and referential integrity rules are implemented by indexes, triggers, stored procedures, etc. This approach to data design allows us to use these objects by all clients without writing any additional client code.

In the case of classic 2-tier client-server system without using cached updates, executing the Post method of a TTable or TQuery component in a client application leads to an attempt to save the edited record to the database. If this record is not consistent with the referential integrity rules, the appropriate transaction rolls back, and the client application is informed about this rollback by the database server. If it happens regularly, the network traffic increases.

For reducing traffic, we can contain some of business rules in the client application by using TFields objects or by creating data dictionaries. In this case, we must rewrite the client application, if some of the business rules are changed. Therefore, we need to reinstall and reconfigure them at all workstations.

In 3-tier systems, we can obtain the metadata and businesses rules from the database server, and store them in the data dictionary, which is used by the data access server. It is easier to reinstall or reconfigure one or several data access servers than to do the same work with hundreds of workstations.

In 3-tier systems, we can also use the ConstraintBroker. It allows us to deliver business rules, which are stored in a data dictionary used by the data access server, to client applications. They are stored in the TClientDataSet cache along with the data. So it is possible to provide the data analysis when executing the Post method inside the client application without connecting to the data access server. Using business rules in a client application reduces the network traffic and increases the efficiency of server operation.

11. Different Service Control managers: using DCOM and OLEnterprise. When must directory services be used?

This section describes differences between using MS DCOM, OLEnterprise and sockets. They are the rules of configuring, the requirements of additional client software installation, a possibility of providing the load balancing and the fail-over safety. The advantages of using CORBA are also discussed.

How can we provide the remote access to the server? In all cases, the remote client must interact with a special application or a service running on the server PC. This special application or service allows or forbids to run the server application or to connect to it in accordance with the rules of giving permissions. The necessity to interact with such services is due to the safety. It would be not very good if any LAN or Internet user could run any application inside the address space of your computer…

In the Microsoft documents such services are often called Service Control Managers (SCM). DCOM Service Control Manager is a Windows NT service, and, in a general case, it is already installed and running on Windows NT PC.

11.1. Using DCOM

We can use the different ways of access to the remote MIDAS server, because it is an OLE Automation server. For example, we can use Microsoft DCOM directly (it means using the TDCOMConnection component, or the TMIDASConnection component, or the TRemoteServer component in a client application). In this case, Windows NT must operate the data access server. The client application must be operated by Windows NT or by Windows 95/98, equipped with DCOM95 or DCOM98 (they are the DCOM clients accessible on the Microsoft Web site).

How to use DCOM? First, we must configure DCOM parameters on the server PC. The first step is downloading the Windows NT user list from the primary domain controller to the server PC. DCOM is a Windows specific technology, and so it uses the Windows user list as a list of persons or groups who can be granted the permission to use or to configure the particular COM server. In addition, DCOM uses the Windows Registry as a COM object implementation repository. Therefore, your network must have the primary domain controller; otherwise, using DCOM seems to be impossible. You, of course, must also be granted a permission to download this user list to server PC.

Having the NT user list, you can grant or revoke permissions to users or user groups to run or to configure your DCOM server by means of the DCOMCNFG utility. You must run it and choose our data access server from the list of the registered COM servers. Then you must describe the rules of using this server, i.e., who can run it and who can configure it. Finally, you must point the location where our data access server must be executed. In this case it is necessary to select the "Run application on this computer" option. The general rule of DCOM access to server is: “The access to this specific server is possible for network users who have the DCOM client installed on their computers and are granted a permission to launch this server” (Fig. 27):

Fig. 27. Describing rules of access to DCOM server

Configuring a client PC is very simple. First, we must register our DCOM server in the client computer Registry (for example, by running it once on the client PC, or by exporting an appropriate *.reg file into the client computer Registry). Second, we must select the "Run application on the following computer" option in the DCOMCNFG utility and enter the name of the server PC in the appropriate field of this dialog (Fig. 28):

Fig. 28. Configuring DCOM on a client PC

On the one hand, if we use DCOM, any client is able to connect to the only server computer, whose name is kept in its DCOM configuration data. If this server fails, client cannot connect to the other server containing the same server object implementation without reconfiguring DCOM on a client computer.

On the other hand, using DCOM allows us to create data access servers as Microsoft Transaction Server objects (they are DLLs supporting the IObjectControl interface). In this case, client connects to the MTS executable, and server objects are instantiated in its address space. MTS can provide additional services, for example, sharing database connections and object pooling (i.e., creating a few server objects that can serve many clients). MTS allows us to save the server resources. But in this case we need to create a “stateless” code in the server object instead of exporting tables, for example, similar to:

function TmyMTS.GetMyData: OleVariant;
begin
Result:=Provider1.Data;
SetComplete;
end;

Such code allows the MTS DataModules not to store the specific client data, so several clients can share it.

MTS objects can instantiate other MTS objects, and it allows us to manage distributed transactions. Different parts of a distributed transaction can be implemented in different MTS objects. For example, this part of code is an example of initiating distributed transaction:

type
TmyMTS = class(TMtsDataModule, ImyMTS);
...
private
 FPart1: IPart1;
 FPart2: IPart2;
...
procedure Tpays.DoTrans(Param1: Integer; Param2: Double; const Param3, Param4: WideString);
begin
try
OleCheck(ObjectContext.CreateInstance(CLASS_Part1, IPart1, FPart1));
OleCheck(ObjectContext.CreateInstance(CLASS_Part2, IPart2, FPart2));
FPart1.Method1(Param1);
FPart2.Method2(Param1,Param2,Param3);
Method3(Param1,Param3,Param4);
except
DisableCommit;
raise;
end;
EnableCommit;
end;

 

 

11.2. Using OLEnterprise

Using DCOM directly is not the only way to create a distributed system. For example, we can use OLEnterprise, which is a good DCOM extension. It is a part of MIDAS, and it allows us to create a load-balanced fail-over system.

In this case, the OLEnterprise Object Factory is an analog to DCOM SCM. It must be running at the server PC. Client applications must connect it for the remote COM server access.

Using OLEnterprise makes it possible to apply two different ways to build an information system. The first one is similar to using DCOM, i.e. any client application knows about the only server implementation. But in this case, the access rules differ from those of DCOM. The general access rule for the specific PC is “Any client, who has the OLEnterprise client installed on his computer can access any published COM server on this computer by means of OLEnterprise”.

What does it mean? It means that we do not need the network user list (and we do not need to have the primary domain controller at all). In addition, OLEnterprise allows publishing COM objects in Windows 95/98. So we can use these operation systems to operate remote COM servers.

Publishing objects means making some registry changes by the Object Explorer utility by choosing the Export option for a specific object (Fig.29):

Fig. 29. Exporting a server object by the OLEnterprise Object Explorer

After exporting an object, we can run the same utility on a client computer and connect to the server Registry. Running the Object Factory on the server PC makes it possible to read the published part of the Registry by the another instance of the Object Explorer running on a client computer, and to import the remote server information to the client Registry (Fig. 30):

Fig. 30. Importing a server object

We can see that in this case we must not run the server application on a client PC for registering it.

The second way to build an information system using OLEnterprise differs from the previous one. It allows any client to reach multiple servers implementing the same server object. To make this possible, we must use the Business ObjectBroker, which, in fact, is a directory service of a distributed system.

To use the Business ObjectBroker, we must reconfigure our server computers. In particular, we must describe that the Business ObjectBroker must find all server implementations, and we must set its location (Fig. 31):

Fig. 31. Configuring server access through Business ObjectBroker

Thereafter, we must run the Business ObjectBroker on the PC specified in the configuration dialog, and export our COM servers to the Business ObjectBroker. The client application must only "know", where the broker is (we must refer to it in a client application instead referring to the server PC name). The client application can "know" nothing about all server computers (how many of them are available now, and what their names or addresses are). When the broker receives a client call, it finds one of suitable server implementations, and informs the client application about its location. If there are many servers with the same server objects, the Business ObjectBroker must provide a load balancing by choosing an implementation randomly.

This case is a good way to provide a fail-over safe system. If we should write a client code, which makes the client to periodically connect to and disconnect from the server (it is better to write a "stateless" code, which allows the server object not to store data of the specific client), the client application will connect to different server implementations randomly. If one of server computers fails, the client should not know about this failure, because it will be simply reconnected to another server implementation next time.

In the case of using OLEnterprise, we can write the client application using the TOLEnterpriseConnection (or TMIDASConnection, or TRemoteServer) component. Configuring them depends on the chosen architecture (for example, whether we use broker). You can find the details in the Delphi or C++Builder documentation.

We must note that Delphi 4 and C++Builder 4 allow to create load-balanced systems by placing the broker functionality into the client application. This functionality is implemented by the TSimpleObjectBroker component. This component contains a list of computers with the same server object implementation installed on, and provides a random choice of one of these computers in attempt of connection to the server. It is not an equivalent to using commercial directory services, but it can be useful in many cases.

11.3. Using sockets

We have already created a client application using sockets. In this case, the Borland socket server works as a Service Control Manager and, in addition, as a data transport tool. In this case, we can achieve the load balance only by using the TSimpleObjectBroker component. However, using sockets allows us to make a non-configurable client, which does not need any client parts of DCOM, OLEnterprise or any other communication software (of course, the TCP/IP support is necessary). Therefore, using sockets is the best way to provide an Internet deployment of client applications, because such deployment is only available when we do not need any specific client software to be installed and configured on a client computer.

11.4. Using CORBA

We have already created a CORBA MIDAS server and a Java client. Of course, we can create a Delphi or C++Builder client too. In this case, we must use the directory service (the VisiBroker Smart Agent), which also provides a load balance.

CORBA is a multi-platform specification. Therefore, it must not use Windows specific tools and objects, such as the Registry. If we need to instantiate the CORBA server automatically by client request, we must register it in CORBA specific databases, which are the interface repository and the implementation repository.

A great advantage of CORBA is that it is possible to create a CORBA server portable to other platforms. C++Builder 4 allows us to do it by choosing the appropriate project options.

12. How to deploy "thin" clients and data access servers

This section describes what is necessary to deploy MIDAS data access servers and what kind of software must be used and licensed.

12.1. How to deploy clients

It was mentioned above that the “thin” client deployment is a very simple process. It demands dbclient.dll to be installed in the WindowsSystem directory or in a client executable directory. If our “thin” client is an ActiveX library, we must only choose dbclient.dll in the Additional files tab of the Web deployment options dialog. If we want to create an InstallShield Express installation (or to use another tool for creating installations), we must not include BDE and SQL Links. We must include only dbclient.dll and the other necessary files (packages, data files, etc.).

It should be mentioned, however, that possibly we must include some libraries from the WindowsSystem directory, which must be the replacements for outdated libraries of the earliest version of Windows 95. Nevertheless, it is a general problem of creating installations.

If we want to deploy an ActiveX “thin” client through the Internet, it is better to choose the Use CAB file compression option to reduce the download time.

It can also be mentioned that we can create Web installations of executable “thin” clients, for example, by using the InstallWeb software of InstallShield Corporation.

12.2. How to deploy data access servers

Data access servers need BDE and some libraries to be installed. They are IDPROV32.DLL (it must be at the same directory, where the BDE is located), DBCLIENT.DLL and STDVCL40.DLL (they must be placed in the WindowsSystem directory, and they must be registered).

It should be mentioned that Delphi 3,4 Client/Server Suite, C++Builder 3 Client/Server Suite, and C++Builder 4 Enterprise contain only the MIDAS Development Kit, which is used for developing data access servers and “thin” clients. But it is not allowed to use the MIDAS Development Kit for deploying them. Using and deploying such servers requires one of the possible MIDAS licenses, for example, the unlimited client MIDAS license or the Limited MIDAS Server Deployment License.

 

13. Possible troubles with the use of MIDAS

This section describes possible troubles, which may occur while connecting to server, showing an ActiveX "thin" client in a browser, deploying "thin" clients divided into packages, working in unreliable networks, etc., and how to solve these problems.

Using MIDAS we can face some problems. Here are the short descriptions of some of them and ways to solve them.

1. The problem, which occurs very often, is that an ActiveX “thin” client is not properly represented in a browser. The possible reasons for such problems are:

  • MS Internet Explorer 2.0 or Netscape Communicator is used instead of MS Internet Explorer 3.0 or 4.0;
  • The browser settings do not allow execution of ActiveX controls downloaded from this Web site.
  • The user does not have a permission to modify his Registry.

To show and execute ActiveX controls correctly, a user must choose the View/Internet Options/Security option and allow execution of ActiveX controls downloaded from all Web servers or from the specific one. If your control is unsigned, your users may choose appropriate option, but a browser must inform them about possible troubles during execution of the unsigned code.

If you want to use the Netscape Communicator to show and execute ActiveX controls, you must equip this browser with an appropriate plug-in. Netscape is a multi-platform browser, so it must not execute ActiveX controls by itself, because ActiveX controls are Windows-specific objects.

2. ActiveX is not properly represented in a browser in spite of the permission to execute it.

This may be due to the fact that this ActiveX was divided into packages, and they were not deployed along with *.ocx file. In this case, it is expedient to check the project options and, if necessary, add the run-time packages to Web Deployment Options.

3. In an attempt to open the TClientDataSet, the error message about loading library problems occurs.

The reason must be the absence of dbclient.dll at the client PC, or the absence of the MIDAS server libraries on the server PC.

4. If we use an unreliable network, a client application can lose its connection with the server. In this case, the best way to maintain the client application functionality is to provide the client application with a possibility to save cached data to a file. It prevents the possible loss of the edited data and allows the user to upload it later.

5. In some networks (usually containing both Windows NT DHCP servers and UNIX servers) we can confront with some troubles. They are due to the fact that in such networks any workstation can have two IP addresses and two names. The first one is for the Microsoft network, and the second one is for the UNIX network and Internet. It should be pointed out that you must use the Microsoft address and name for the DCOM type of connection and the UNIX address and name for the socket type of connection. To obtain the UNIX/Internet address and name, it is possible to use IPCONFIG and NSLOOKUP utilities.

14. Different architectures of multi-tier information systems

This section contains some examples of multi-tier information system architectures recommended by us to some of our customers in Russia, the Ukraine, Moldavia and Latvia (oil plants with remote oil-rigs, trade companies with remote stocks, regional electricity supply services, banks, etc.)

There are many different ways to make a distributed system. Its architecture depends on the current and planned number of users, the degree of territorial distribution of an enterprise, the need for centralized data storage, the frequency of upgrading client applications, etc.

The first case is a compact enterprise with LAN. In this case, all enterprise data are often stored in the only database. Three-tier architecture in this case is used to reduce expenses for configuring and maintaining workstations (installing and configuring DBMS client software, configuring BDE, upgrading client applications, etc.), to reduce the network traffic, and to increase the reliability of the information system. In this case, it is desirable to use several computers with the same data access servers installed, and a directory service to provide the fail-over safety and load balancing. This architecture can be based on both OLEnterprise with Business ObjectBroker and VisiBroker with CORBA directory services (Fig. 32):

Fig. 32. The example of an information system architecture for a compact enterprise with LAN

The use of CORBA may be recommended in the case of a perspective of replacing the data access server PCs by computers with non-Windows platforms (for example, by Unix servers). In this case, such upgrading will be easier, because it will not require replacing the client applications (and, possibly, it will not require rewriting the server code, if JBuilder or C++Builder 4 Enterprise is used for creating the platform independent CORBA server code).

It is also good to use Entera data access servers, because Entera exists for different platforms too.

The second case is an enterprise with a wide territory scattering. It is a typical situation for many gas and oil plants in Russia and for many trade companies. These enterprises often use many local information systems, so they have a lot of problems concerned with data replication, data actualization support, joining the data from a few information systems for statistical analysis and report generation.

In this case, a 3-tier architecture can solve these problems. This architecture makes it possible to centralize storing and processing the data and to obtain the actual data, even if a workstation is very far from the database server and the data access server and cannot be connected to the data access server by LAN. In this case, it is possible to use a direct modem connection by a telephone line, or through the Internet. Such connection must not be very reliable: client applications can use caching data, saving them to files and restoring them from files. Using the ConstraintBroker makes it possible to check the relevance of data to the server business rules inside a client application.

In this case, the three-tier architecture is used to reduce expenses for configuring software and to centralize data storage. It is good to place the database server and the data access server at the central office of such company, and the data access server must be equipped with MIDAS and must be accessible through the Internet. As for workstations, they must be equipped with the Internet Explorer 3.0 or higher. Both developers and users must have an access to the same Web server (it does not matter where it is and what operation system it is operated by, because it is only used for uploading and downloading "thin" clients). If client applications use sockets for access to the server, they are non-configurable, because they require the Internet Explorer 3.0 to be installed, and nothing else. Of course, we can use Inprise Entera instead of MIDAS (Fig. 33):

Fig. 33 The example of information system architecture for enterprises with scattered subsidiaries

Such architecture is used or is planned to use in many Russian and Latvian banks, telecommunication and trading companies, because many of them have remote subsidiaries with Internet access.

If the Internet is not accessible, it is possible to use modems and telephone lines with TCP/IP protocol (some engineering supervision services in Russia use or plan to use such technology). In the case of unreliable connection, it is recommended to provide a possibility to save cached data using the SaveToFile and LoadFromFile method of the TClientDataSet component.

Another variant of the information system architecture for "scattered" companies can be implemented as a 4-tier system with an "ultra-thin" client. In this case a "thin" client application is a CGI script or an ISAPI DLL, and workstations are equipped with any operation system and any Web browser. This is better than to use "fat" clients as Web server applications, because Web server applications usually serve simultaneously an unpredictable number of their clients; so it would be better for them to use less resources. In this case, unlike the previous one, the Web server must be operated by Windows NT/95/98, because it is not only a file supplier, but also a host for executing the data access server code written with Delphi or C++Builder (Fig. 34):

Fig. 34 The example of an information system architecture for enterprises with scattered subsidiaries

It should be mentioned that Delphi 5 provides an additional support to this architecture. The features of implementing such MIDAS client in the form of Web server application will be discussed in the last section of this paper.

It is possible to combine these architectures, using, for example, TCP/IP access and directory services together. Inprise tools can provide us with many possibilities to build reliable information systems, which are easy to configure, maintain, and upgrade, and we can use our fantasy to create our own variants of their architectures.

15. Creating Web MIDAS applications with Delphi 5

Note: this part of article is written with a pre-release copy of Delphi 5.

One of the new features of Delphi 5 and MIDAS 3 is the possibility to create Web MIDAS client applications. The InternetExpress components allow to create a Web server a pplication, which is a "thin" MIDAS client. In this case, users can interact with it by working with a Web browser only.

To illustrate this possibility, let us create the MIDAS 3 server. The process of creating this server is not significantly different from described in part 3. The main difference is the fact that during creating a server we must place the TDataSetProvider on the Remote DataModule, bind it with the master TTable component and set its Exported property to True (and, of course, we can use the new graphic DataModule Editor to define a Master-Detail relationship between tables, Fig.35).

Fig. 35. The MIDAS server created in Delphi 5

To build a Web MIDAS client, we must create a Web server application by choosing an appropriate icon from the Object Repository of Delphi 5. After that, we must place a connection component (for example, TDCOMConnection, TSocketConnection, etc.) on the WebModule and set its ServerName property. Next, we must place a TXMLBroker component on the WebModule and set its RemoteServer property to the name of our connection component.

Next, let us place TMidasPageProducer component on our WebModule. It must generate an HTML content for representing in a browser.

Now we must set the IncludePathURL property of this component. It is a path, where our Web application can find JavaScript and HTML files, which are used to produce the HTML content. The *.js and *.html files must be copied from Delphi5SourceWebmidas directory to this URL.

It should be pointed out that the InetpubScripts directory, which is the default script directory of Microsoft Internet Information Server, and a potential place to store Web MIDAS client, is not a good place for these files. The reason is the fact, that by default any file of this directory can be executed, but cannot be read. So it is necessary to change the default settings for this directory or to use another URL to store these files.

Now we must right click on the TMidasPageProducer component and choose the Web Page Editor option from the pop-up menu. In this editor, we can click the New button and create user interface objects, such as DataForms, containing DataGrids and DataNavigators (Fig. 36).

Fig. 36. Designing user interface with Web page editor

After that, we must set appropriate properties for these elements. For example, to create a detail grid, we must set XMLDataSetField property of the DataGrid2 to Table2. Now we have a WebModule similar to Fig. 37.

Fig. 37. The WebModule of Web MIDAS client

At last, we must create a WebActionItem and set its Producer property to MidasPageProducer1, and its Default property to True. Then we can compile our Web application, upload it into script directory of the Web server and try to run it from a Web browser (Fig. 38).

Fig. 38. The browser front-end produced by Web MIDAS client

Thus, Delphi 5 allows us to create Web MIDAS clients which allow to use a Web browser as a front-end to MIDAS data access servers, and that simplifies creating 4-tier information systems.

Acknowledgements

I wish to thank Charlie Calvert for his support and assistance. I am also grateful to all staff of the Moscow Inprise office for their aid during last 3 years.

Natalia Elmanova is a Ph.D., free-lance Delphi/C++Builder trainer and consultant, and technical writer. She has more than 15 years experience in database programming. She also is an author of three popular books about C++Builder, Delphi, COM, and database programming and more than twenty articles about Inprise technologies in Russian computer magazines.
1011.g23@relcom.ru


Server Response from: ETNASC03