This article is more than 1 year old

SOA is not open - discuss

Mix don't match?

Of course SOA is open; its whole raison d'être is to enable services from different sources to work together with ease. The development of Web Services standards SOAP, WSDL etc. have made this possible and a practical reality.

But the ability to connect to services is only the basic building block of SOA. The really interesting stuff happens when these services are joined together to create a Composite Application. Composite Applications use SOA as the way to integrate together:

  • People (through portals)
  • Processes (using business process management)
  • Data (through some form of federation)
  • Business Partners (through business to business technology)

All of these parts have to be put together in the development environment and I am finding it increasingly difficult to see how this can be done if the parts are from different vendors. If you listen to the big boys in this field (in particular, IBM with WebSphere, Oracle with Fusion, BEA with FreeFlow, and Microsoft with BizTalk) then the message is clear about being able to openly connect to services, but there is little or no discussion of the integration infrastructure being open and made up of products from different vendors. To take an extreme example: is it really feasible to define a single business process partly in Fusion and partly in WebSphere?

The message from established integration specialists such as WebMethods or Pega Systems, or newcomers such as Cordys, is even plainer: the great advantage of these products is that they are internally complete and the productivity you get from them is because you do not have to integrate the infrastructure.

However, standards do not exist to enable development to be shared. Eclipse helps, but this does not include a shared repository and a shared definition of the artefacts to be put into such a repository.

Using a single development environment is not too serious and has very obvious benefits. The interesting difference between SOA and more traditional development (such as COBOL or Java) is that the distinction between development and run time is much more fluid. One of the advantages of Composite Applications is that they can be modified instantaneously, changing the flow, or rules, or even the services used, to meet new business requirements. This dynamic 'development' environment means that the run time has to directly support the development environment. The two are integrated at the hip.

This integration goes even further and cuts right across the lifecycle: strategy, design, development, promotion to production, operation, real time monitoring, post hoc analysis and change management. For example, the real time monitoring of a business process must understand the process flow that was defined at the design stage.

We cannot even make a clear dividing line between business and IT. IT has to understand the relationship between the hardware and software services it provides and the individual business processes built on top of them. The business will talk in terms of business processes being critical, or not working correctly, or not meeting SLAs. IT has to be able to map that on to the IT infrastructure so they can plan for future loads, resolve problems and make business aware of the impact of IT issues.

SOA enables and encourages the integration of IT, the business, the stages of the lifecycle, people, processes, partners and data. To make this open will require further standards and this will not happen quickly. In the meantime, to get the full benefit of SOA users will need to stick to a solution from a single vendor as far as that is possible.

The choice of vendor can not now be made independently by development or operations, or IT or the business. The decision now has to be made group-wide.

© IT-Analysis.com

More about

TIP US OFF

Send us news


Other stories you might like