SOA today and tomorrow.

Today there is no developer who does not talk about SOA. It is a very interesting topic to me as well. I have been involved with SOA related development for quite some time now. There are two interesting aspects of software development that come to the fore front when we think of SOA.

1. Re-Usable.
2. Interoperable.

These are the two things we try to achieve to the best possible limits when we implement an SOA solution.

These are the two aspects that will take SOA to the next level.

Here i will like to collate some of my thoughts on the existing limits and the potential limits.

1. Re-Usable.

Re-usability is commonly confused to be copy-paste by few developers, many developers as of today make the truly re-usable components but couple them to the context they use it in. the coupling may be with the parameters or the output. well, if we sit back and think how different is this from copy-paste. The best example is some of the design patterns that come to our help provided by the IDE's. Few smart developers are matured to truly make re-usable components that are developed once and deploy able in many projects out of the box.

SOA takes re-usability to the next level. SOA preaches true re-usability of the components. In SOA terms re-usability means develop once, deploy once and use it in many projects.

Re-usability tomorrow: according to visionaries, the re-usability has still to go to the next level. The software vendors will develop and deploy the software components pertaining to the specific business needs and will host them and make them usable at a specific price. The consumers will just own the business process built specifically for there business goals. These business processes will be built around the components hosted by the software vendors. This is when truly your fridge can order for milk as envisioned by the XML/SOAP visionaries back in early 2000.

2. Interoperability.

Interoperability is been a concern for over a period. This is the major challenge is true collaboration and enterprise integration. Over a period of time there have been various industry efforts and industry initiatives to address the Interoperability concerns. The evolution of interoperability once was just divided into two layers the network layer and the application layer. Various initiatives that have been revolution start right from the network protocol definitions such as TCP/IP, HTTP, SNMP, SMTP/POP, IMAP and many more. When these network layer was evolving there has been little effort in evolving the application interoperability concerns. The well known once are CORBA and DCOM.

Interoperability at the application layer had a major breakthrough with the introduction of XML. With the introduction of XML enterprises started having self defined (home grown) business protocols, which helped them achieve interoperability at lesser cost between various applications.

This lead the standard body such as OASIS to define business protocols across industries for the participants to inter operate.

There are two classes of interoperability specification evolving hand in hand based on XML.

1. Infrastructure Level.
2. Application Level.

Infrastructure level interoperability specification for example SOAP, ebXML and ws-* are the specification that defines the meta data for the messages which carry the message state such as security, reliability, traceability and non-repudiation. The messages adhering to these specification can be understood and used to invoke the desired/mentioned service.

Infrastructure Interoperability Tomorrow: Interoperability has a very long way to go to reach the maturity of consolidation and universal data formats. SOAP over any network is the defacto transport specification. Based on the wide industry support, flexibility and adoption WS-* specification looks the ideal way further, but the consolidation and maturity ebXML demonstrates is very much appreciable with the current context. The mix of these two set of specification will provide an strong platform for message interoperability in which ebXML addresses the essential requirements of the message communication and WS-* provides optional specification for finer activities such as transactions, large messaging and message transformation.

Application level interoperability specification for example HL7, Rossattenet and OTA-XML are the specifications that defines the meta data for the business message. These specifications define how the business message is structured and what level of information is required for a specific business transaction.

Application interoperability tomorrow: The different specifications for different industries posts a greater challenge towards evolving a universal specification. The challenge is not technical, the challenge is the significant difference in the business process in each industry. The participation of an enterprise with different industry partners in a specific business processes is quite likely to happen. One of the possible options is to have a data model for an enterprise and message adapters to be built to transform the business domain specific message into enterprise domain message. This will be enabled by various tools that business analysts would use to map the domain specific elements to the Enterprise domain as one time configuration activity.

Kalimulla Shariff.