By Dr. R. Srinivasan, CTO, iCMG, Bangalore

Before getting into the topic on Middleware in e-Governance, let us look at an episode under the title, " The Brilliance of Dumb Questions" by Michael Jay Tucker (http://eai.ebizq.net/enterprise_integration/Trucker_2) where he talks about the experience of Ms. Emilie Schmidt who took up the job as CTO, in North Carolina's Department of Commerce in 1992 after working for Digital Equipment Corporation for 13 years. Emilie had no experience in the State Government but she said that she accepted to take up this job and said, " it turned out to be an advantage, because I got to ask dumb questions, which usually turn out to be brilliant" . The task that was assigned to Emilie was to develop a "statewide architecture" towards strategic information technology planning and policy development and establish an Information Resource Management Commission. It was a challenging job because according to her it had to deal with everything from zoos to prisons!! While deciding the statewide architecture, she had to take care of twenty three agencies in the executive branch of the government, and they all have their own secretaries, their own staffs, their own business process, their own software and hardware tools and their own web sites. Like IT people everywhere, she has been given the task of integrating software that is far easier to join in theory than in practice. This shows Emilie had to face the Enterprise wide Application Integration (EAI) problems of staggering proportions. In the end she could successfully get into the act of implementation on the appropriate architecture which is the real Middleware for her project. Her advice to the IT people working on similar integration efforts is, "don't get discouraged, because the rate of adoption is never as fast as you would like". The lesson that we learn from this episode is that the agencies involved in e-Governance should decide on a suitable architecture at the planning stage and should design the applications toward that architecture to get a very good integrated system.

Under the parlance of e-Governance, the Middleware will address the needs of a networked Government to create, integrate and manage large-scale distributed applications within a department and also between various departments. These applications may comprise of those which are legacy systems as well as the web based ones. It should also cater to the development and management of new applications that are robust and scalable. Typical specifications of a robust Middleware should provide interoperability, integrity, reliability, scalability, security and manageability. It will be located between the Applications and the Operating Systems of the platforms on which the applications are supported . Traditionally every application is connected to the Middleware through an Application Programming Interface (API). Schreiber (Datamation April1, 1995) in his article on "Middleware Demystified" describes that Middleware services provide a more functional set of API's than the operating system and network services to allow an application (a). to locate transparently another application across the network providing the required interaction, (b). to be independent from network services, (c). to be reliable and available and (d). scale up in capacity without losing the function.

There are different types of Middleware and the scope of the problem to be solved will determine the type of Middleware architecture to be adopted. Typical classifications are: 1. Message Oriented Middleware (MOM), 2. Transaction Processing Monitors, 3. Object Request Brokers (ORB's), and 4. Remote Procedure Calls. Associated with each category are the types of services that will be provided as part of the enterprise which will be described in the next article.