Distributed Information Systems. From A to Z. - Part IV. Using multiple TSOAPDatamodules or multiple TDataModules.

By: Serge Dosyukov

Abstract: This is a 4th article from a list, it shows how to transfer multiple TSOAPDataModule into one and use multiple TDataModules instead.

Copyright ) 2003 by Serge Dosyukov

4th article from "Distributed Information Systems. From A to Z" seria.
If you would like to find other articles, there is a list which will help you:

Introduction

In last article we've created a Standalone Web Service with more then one TSOAPDataModule. It allows us split our logic between different Data forms to make them smaller. This means our application will spend less time and resources creating and using them when processing a requests from client application.

As you were be able to see it is possible and very useful especially when your application has just few Data forms and business logic is split between them.

But in some situation it is not like this. For example, you could have a business object where logic is split by groups of providers which belong to multiple TSOAPDatamodules. Logically it is still one object, but when you look at your WSDL publication you will see many IAppServerSOAP instances... This could be not what you expected.

To be or not to be

So if you really looking for answer, there it is.

You could move your providers from TSOAPDataModules into TDataModule. You could say what then you will not be able to see your providers from client side.

But there is a way to publish your providers which located on TDataModule dynamically via your SOAP interface.

Lets find out what exactly going on when a client request a provider data from a server.

If you look into a source code of constructor for TCustomProvider (Provider.pas) you will see what there is a little code which is invoked here, code which registers your provider instance in some global list of available (read "published") providers.

There is a IF case but we looking for a last couple lines:

if AOwner.GetInterface(IProviderContainer, ProvContainer) then
  ProvContainer.RegisterProvider(Self);
IProviderContainer is one from a set of interfaces our TSOAPDataModule implements and it is how our provider get published.

So, as you can see only one thing we have to do is to call method RegisterProvider:

if AOwner.GetInterface(IProviderContainer, ProvContainer) then
  ProvContainer.RegisterProvider(Self);

From Help-Online:
Adds a provider to the list returned by AS_GetProviderNames.
Call RegisterProvider to make a provider available through the SOAP data modules IAppServer interface. Pass a reference to the provider as the Value parameter. Once a provider is registered, its availability to client applications can be turned on or off using its Exported property.
There is no need to call RegisterProvider for providers that are added at design time or when the SOAP data module is assigned as an Owner in the providers constructor. These are registered automatically.
Before a registered provider is destroyed, it must be unregistered using the UnRegisterProvider method. Providers that have the SOAP data module as an Owner are unregistered automatically from their destructo.

You can implement exactly this when you create an instance of TDataModule in your application. Dont forget, your SOAPDataModule should exists at this point and should remain static or you will need reregister your providers each time when TSOAPDataModule instance created.

Ghost house

Remember all this scary movie when kids staying in a house which appear to be empty and when night fall all old nice ghost appear from nowhere?

What I am talking about? Hm, lets build a ghost house.

In some situations you will not like to have all this TDataModules sit in a memory all the time as well as to have TSOAPDataModule instance, or even reregister your providers each time when instance of TSOAPDataModule created.

In this situation we could use our ghost house: a storage with information where our providers are defined (where out Provider class implemented and what is a name of the Provider), but no actual instance exists until it required.

If we come back from our TV-world into computer one, our ghost house became to be Factory object, object which will register and keep information about Providers and allow perform all necessary logic by request. There is still some coding required to make information available off-line, when TDataModule isnt created yet, but I think, as it is in many cases, we could accept it.

In Part II we've created sample project to illustrate how to build Standalone Web Service. Im going use it as a prototype and modify it to implement our Provider Factory object.

Result of this modification available here.

Factory Object allows:

  • Create and destroy instance of the factory
  • Provide method to register TDataModule and Providers
  • Find Provider by name or index (this is part of request logic what TSOAPDataModule will use when trying find provider)
  • Create and return instance of TDataModule and Provider class
  • Populate a list of all providers registered

Note. In a sample project both TDataModules publish the same data but via different providers.

Contact:

Authors web-site: http://www.dragonsoft.spb.ru
Full list of Articles available in Articles section.


Server Response from: ETNASC03