28th Feb 2001
	By Dr. R. Srinivasan, CTO, iCMG, Bangalore

In the last article it was mentioned that "Middleware" under the Internet-based transactions, like e-Governance, will facilitate multiple processes or applications running on one or more machines to interact across the network. It was also brought out that there are different types of Middle ware like Message-Oriented Middleware (MOM), Transaction Processing Monitors (TPM), Object Request Brokers (ORB) and Remote Procedural calls (RPC). Each has its own characteristics and serves specific services towards transactions over the net. For example the organization, called Netweave, has a specific architecture based on their Netweave Server, which has all the characteristics of a middleware, having the following services: Client/ Transaction Service: to facilitate transactions between a client and a remote server. Message Queuing Service: to ensure secured delivery of messages even during network failure Message Broadcast Service: to syncronize remote applications. Transaction Service: to ensure consistency of all data bases Data Conversion Service: to take care of data format differences between platforms Security Services: to impose access control restrictions and authentication Directory Services: to allow data and servers to be freely moved about the network. File Transfer Service: to transfer files in the network Replicated Data Service: to replicate the data over a large population of remote client platforms with support for client updating all replicates Client/Database Service: to facilitate a client application to access and update file systems in remote data bases.

As could be seen from the above example, the different services indicate the flexibility and ease with which applications can be made to interact with each other including the associated data connectivity. But in reality, majority of the middleware products that are available in the market tend to be proprietary in nature that restricts their flexibility to cater to new applications from different vendors or developed under different environments. So while deciding the architecture for e-Governance, care should be taken not only to develop applications to interact with each other but also the middleware selected must have flexibility for future applications, scalability, reliability, etc. To make their computing environment manageably simple, application developers from the various departments must select a small number of services that meet their needs for functionality and platform coverage but with the facility for future expansion. Bernstein in his paper on " Middleware: A model for Distributed Services" (Communications of ACM, Feb. 1996) says that "while middleware services raise the level of abstraction of programming distributed applications, they still leave the application developer with hard design choices", i.e it is left to him to decide the client side and server side functionalities in a distributed environment like e-governance.

In order to overcome this situation, the developer should fully understand the value of the middleware services on which his application has to rely on- it means that he has to decide those middleware services that is needed and choose the middleware accordingly. Under the parlance of e-Governance this is where each department is developing its own applications to be put on the net for interacting with each other to provide a useful information, there is a need for a thorough "Systems Study" at the initial stage itself. On the contrary, what is happening now is that every department in a government is getting computerized with a view to providing information in an isolated manner. If a citizen has to get an information that might need the seamless interaction of applications, the Government should take proper care in the design stage itself.