Wednesday Jul 09, 2008

Why Interoperability? And What it takes to be really interoprable?

Why Interoperability?

Organizations invest time and money for building information systems over a period of time. These systems are built with the best of hardware and software that are available during that time. Due to the change in the socio-economic-political and opportunity reasons organizations are constantly challenged to update update themselves temporally, technology wise also. If we want that the existing solutions run as is (Which the client obviously wants since invested time and money) and yet see that these disparate systems talk to each other seamlessly we need interoperability amongst the systems.

When ever we think of such solutions in heterogeneous systems for integration we tend to think of SOA or WebServices. We also that these solutions are of panacea to all the ills of heterogeneous systems while integrating. But it takes more than just WS Software systems to be truly inter-operable. Lets examine what it takes to be inter-operable.

Lets get to the definition of interoperability:

ISO/IEC 2382 Information Technology Vocabulary defines interoperability as:

“The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units."

By this definition we can deduce the following areas or levels are at which systems to be inter-operable:

    \* Network and Infrastructure Layer - For interoperability amongst different protocols like TCP/IP, DNS, DHCP/BOOTP, AppleTalk, 802.1x, NFS/NIS (Different OS have different tools for making file systems accessible) etc..

    \* Data Layer - For data access JDBC, ODBC, OLEDB, ADO, ADO.Net etc. Apart from that we are talking about file formats like XML and the different variants of XML organizations (the XML Serializers and De-Serializers available on different platforms make these documents inter-operable)

    \* Program Layer - For taking care of Program level interoperability. We create services / programs that deal with the data in the Data Layer. These are of the following Channels

          o Technology specific binary formats -- RMI/IIOP in case of Java, .Net Remoting or COM interop. with respect to MS technologies. These can deal with the stateful data and have good performance numbers. But these have a caveat that they are proprietary that is the other end of the system also needs to be either Java in case of RMI and MS based COM/ .Net object in case of .Net Remoting and COM inter-op. But there are some tools like J-Integra, etc. for inter-operability between the MS – Java worlds. IIOP is supported by both Java and MS worlds.

          o WS - \* Standard programs for exposing services. There are built on several set of standards like security, transaction, co-ordination and trust etc. for building robust inter-operational heterogeneous systems. WS stack is supported by both Java and MS worlds.

          o Rest style services using HTTP. These deal with stateless data.

    \* Process Layer - This layer builds on top of the program layer and helps in orchestrating the programs or services. The need for this layer is because of the geographical / temporal dispersion of the organization of the Business and Systems. And also the raising business demand calling for

o Asynchronous Availability of the systems for
          o High Availability
          o Transactional Nature of the Heterogeneous systems
          o Reliability

These requirements of the systems are met by the industry in terms of

          o Messaging Infrastructure (support for Queues and topics). Most of the MQ vendors have adopted to JMS standards and gave API for accessing the MI.
          o Mainframe Infrastructure – These are of BLI/SLI/Data and RPG types. These systems provide for unlocking of existing production systems but at the same time require callable interfaces. Again most of the systems have provided Java API for accessing the systems.
          o Business Process Infrastructure – these are evolved as open standards like BPMN and BPEL4WS etc.. These process infrastructure is supported with Adapters for connecting to the data channels. These are typically supported in Integration Servers of the vendors like Sun's Glassfish with Open-ESB, MS Biztalk server etc..

    \* Security Layer – This layer integrates the users with the systems in a secured way. We can call this identity layer also. Here we see AAAs (Authentication, Autherrization and Accounting) for Inter/Intra Organization.

o Authentication : Kerberos / Directories / X.509 / SSL/TLS etc..
o Authorization : ACL systems / RBAC systems
          o Here We further talk about the SSO (Single Sign On) and the other inter-operable standards like SAML, WS – Federation, User token profile, CardSpace etc.. WS – Security standards deal with message level security too for maintaining integrity and non repudiation of the message that is traveling. The IDM (Identity Management Suites) comes into picture at this layer and all the major vendors like Sun/MS have their own IDM Suites for comprehensive solutions for organizational needs.

    \* Management Layer – When we think of all the above infrastructure and disparate systems talking to each other for different needs, we need a way to manage the solution that is offered from some console. There comes need for Management protocols like SNMP/ WMI/ WBEM/CIM/JMX etc. for managing the application exposed interfaces and configurations. Every integration vendor offers some management connector for deployed applications.

So when look for a truly inter-operable system we need to keep in mind all the 6 layers in mind during system design. Proper care for all these will ensure that the systems will not only be inter-operable but at the same time scalable,  and be furure proof with technology. Lets examine some of the layers from the JCAPS perspective and how does JCAPS offers interoperability in my next post.


I was part of Sun R&D in Java CAPS and later Glassfish ESB. I moved from R&D to Consulting. I am currently working as a Solution Architect in Oracle Consulting Services (India). I was sharing my experience w.r.t. Java CAPS and other technologies during Sun period. Now in Oracle world I share my experiences with Oracle FMW product line as well as other Oracle Technologies and products.


« August 2016