Reflection on Interoperability
By narayanaa on Apr 10, 2007
After listening to the talk of Karen I started reflecting about interoperability and what all it means to the Computing in the SOA based world. Interoperability at the outset connotes several things, but to start with lets have a definition for interoperability:
“ 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” -- ISO/IEC 2382 information technology vocabulary
Indeed a very broad definition, but if we can split apart we can muster several things. The stuff that came to my mind I will try to list here and go over each one so that it makes more sense.
Execution of programs
Transfer of Data amongst various functional units – this involves data flow or “ Business Process” apart from data transfer
User should not know the unique characteristics --- It means unified management to the heterogeneous systems and also needs identical or inter-operable way of credential checking for security reasons .
Lets add one more to the list here because architecture of such a system should not leave behind the already built or legacy systems.
If at all such system needs to be developed we need a common way of communication / data transfer amongst heterogeneous systems that language happens to be “ XML” since could be easily understood, universally adopted. That said lets examine whats involved in each of the above layer.
Communication: When we talk about communication it' either on the wire or by wi-fi / blue tooth etc. we have several standards and protocols viz. TCP/IP, DNS. DHCP/BOOTP, 802.1x, AppleTalk, IPX/SPX and NFS/NIS. All the major operating systems have ways in which they communicate via these protocols.
Data Transfer: This can happen in 2 ways Database access and File access. Both the major vendors Microsoft and Java have defined a specific ways in which they access databases in terms of ODBC and JDBC respectively. Any driver complying to these specifications can be used to connect to the specified database. Here when file is referred the file of “XML” in nature since XML has Serializers and De-Serializers on all the major platforms
Programmatic Compatibility: Programmatic languages have different type systems and in-memory representation of objects which is the primary cause of incompatibility. Different ways were found to bridge these incompatibility and inter-working amongst different languages. They are
Binary level compatibility: We have 3 kinds of binary channels from different kinds of programmatic environments.
RMI in the Java world – client and server both in Java
IIOP in the CORBA conformant world – defines IDL and partners need to conform to the IDL. They will generate stubs on server side and proxys on client side to access the objects seamlessly.
.NET remoting / DCOM way: DCOM is a binary level protocol. Any language which implements this protocol can access a DCOM component deployed. .NET remoting is based on WCF (Windows Communication Framework codenamed Indigo). WCF applications can be developed in any language which can target the .NET runtime. The WCF programming model unifies Web Services, .NET Remoting, Distributed Transactions, and Message Queues into a single Service-oriented programming model for distributed computing.
The advantages with this approach are performance, statefulness of the data and IPC applications
WS-I gives the standards for WS defined standards interoperability amongst the conferment systems.
WS-I has given security profile as well as attachment profile.
OASIS has also defined inter-operable standards for several requirements.
Rest way of communication has come into vogue which has its base in HTTP.
Process Compatibility: Traditionally processes for compatibility have either pipelined using Message Queues (MS MQ/ IBM MQ Series etc..) or by using Mainframe / Middle range integration (BLI/SLI / Data RPG etc.) and lately using BPEL based orchestration using adapters for each vendor (Sun JCAPS, Microsoft's Biztalk, TIBCO etc.). But here also the BPM is vendor specific. JSR 208 is right step in this direction where it specifies only the how the messages are routed. The specification only says about components conforming to the standard set of interfaces can talk to the external systems or process the business logic. You can have a look at Sun's implementation of this JSR at open-esb and has several components developed under open source. The specification is SOA based and all the components expose their operations in WSDL.
I will talk about Credential Compatibility(User logon/ SSO etc) and Management or Administration Compatibility in my next post which are required for interoperability.