15th Jan 2001
	By Dr. R. Srinivasan, CTO, iCMG, Bangalore

Having seen the importance of "middleware" and the advantages of Component-based Application Development in e-Governance, let us revisit this topic which I introduced few weeks ago. Dale Skeen, CTO of Vitria, California, USA says, in his article on "The Seven Myths of EAI" that EAI is not about what you integrate - it is about what you enable. This is what is important in e-Governance where the aim should be to enable the common man to get his information; he should not be bothered to access more than one application and get the integration done in his head and achieve the desired result. Naturally this will not yield what e-Governance is being planned for as far as information dissemination is concerned. Unfortunately, if we go to proprietary solutions for application development, either a solution may not be found to cater to all types of applications from a single vendor or it may be difficult to integrate from various vendors. The reason for the later one is that, in today's scenario, each application has got its own interface and, as a result, application integrators, in our case each department in a government, need to look for separate "connectors" or "adapters" for each interface. Incidentally connectors are the interface components of an EAI solution that move data in and out of applications. I mention once again that this calls for a single standard to which all applications are designed employing component-based technology. This will be similar to the situation we had few years ago with respect to accessing a relational database. Until the ODBC emerged , we had to have the interface unique to each vendor of RDBMS. In the case of EAI, it is expected that connectors/adapters designed with the interface to CORBA and IIOP (Internet Inter Object Request Broker Protocol) will be the future. The benefit will not only be a seamless integration between applications but also each application itself could be reused by another department or another government rather than reinventing the wheel all over again.

So, the suggestion is that, any government going in for automated system through e-Governance, should decide the architecture of the entire integrated system and adopt uniform method of application development with common interface to an universal standard. Thus there are two important aspects towards design of e-Governance : the "system architecture" and the "Universal Standard" for application development and integration. Dr. Thomas Mowbray, Chairman iCMG, writes, "as systems become more and more complex, standards become increasingly important. Standards provide one of the most accessible ways of assuring component compatibility" (Ref. The Essential CORBA by Thomas Mowbray and Ron Zahavi). As mentioned by him the key benefits that standards provide comprise, Portability, Interoperability, Risk /Cost Reduction, interchangeability, risk reduction in system obsolescence etc. Under the design efforts of a government going for e-Governance these parameters are absolutely essential. Because different departments in a government or different governments may be using different hardware, different operating systems, networked employing different environments and protocols, portability is vital in such heterogeneous environment so that any application is capable of being ported in the overall system. Similarly, as discussed earlier, the applications should be capable of interacting with each other to facilitate the frequently required functions like data interchange. Interchangeability provides flexibility for both product level and subsystem level interchangeability. Standards do not change very often where as technology obsolescence is frequent; but as long as the new technology also is confined to interface with the same standard that has been in use, there will be no possibility of facing system obsolescence.

Under the efforts involved in bringing out e-Governance, we will be aiming not only in developing new applications employing state-of-the-art technology using Java, C++, Small Talk ,etc. but also we may have to use legacy systems that have been developed in the past spending hundreds of man hours and consisting of millions of lines of code. It may so happen that these legacy systems have to interact/interface with other applications and hence techniques have to be deployed to wrap the legacy applications with the interface akin to the standard chosen as part of the middleware. A typical system, meeting all these requirements, in EAI will be based on an architecture that would include a "Container", the "Connectors" and "Adapters". We will discuss a typical architecture in the next article.