You can’t buy a service-oriented architecture (SOA). You can only buy enabling products. So says a report from the New Rowley Group, one of the many companies now advising organisations on how to tackle this important area.
But which tools? Where do they all fit in? As the article on architecture points out, choosing the software is no trivial task.
The products described below make up the main components that are likely to be used to build the SOA. But these are not clearly defined and overlap in function, sometimes heavily.
A lot of businesses will already be using all or most of these. They therefore have to choose which tools to use when – and quite likely, a solution will involve several. As the Gartner Group’s Massimo Pezzini advises, “The goal is not to avoid heterogeneity.”
A (web) service
The SOA is built on the assumption that software functions are delivered as services. This will probably, but does not necessarily, mean web services. In a web service, the consumer of the web service sends an XML document to the web service provider, which carries out a function or transaction, and then returns it with the task completed. In an SOA, each service needs to be registered and managed by controlling middleware, the SOA backbone or infrastructure layer. Services are not products – but no SOA can work without them.
Application platform suites
Although the application platform suite is emerging as the dominant software component in the modern, service-oriented enterprise, it might be argued that the APS doesn’t really exist as a distinct product. That is because, with the possible exception of the highly integrated but proprietary Microsoft .NET Framework, the APS is often not as technically integrated as the marketing suggests. In fact, most APS’s consist of loosely integrated products that the leading suppliers have brought together under one name.
There are, and probably only ever will be, five companies that play at this level: IBM, Microsoft, SAP, Oracle and BEA. Each of these provides a stack of products that spans development and modelling tools, an application server, an integration broker, business process management and analytics.
Over time, these suites will become increasingly integrated and, arguably, become more valuable to the customer. Clearly, the ability of the suppliers to offer complete, bundled solutions will persuade many customers to use these products for their SOA backbone.
The likelihood is these ‘vertical suites’ will between them take more than 80% of the market, but they are unlikely to push all the smaller suppliers out, analysts say. These smaller suppliers have specialist strengths and good technology. Many customers also question the business sense in becoming so dependent on one technology supplier.
Service enabling tools
To build composite applications, it may be necessary to integrate twice – once at the application level, and again at the platform level. At the application level, functions must be exposed and presented as services. Enter a group of suppliers with the expertise and products to delve into the legacy applications, find the functions, and wrap them up as a service, ready for use in an SOA. Among them are Micro Focus, WRQ, and Seagull.
Application development and deployment tools
In order to gain the full business benefits of the SOA, businesses will need to be able to carry out three distinct functions: model business processes for later deployment using packages or new applications; build new applications or services; and create ‘composite’ applications using existing applications.
These three functions can be carried out by various tools, and the choice will depend on the focus of the user company. In most cases, an application server and development tool (J2EE or .NET) will be required to build new services, just as they are used now to build new applications. Development and modelling tool providers such as Compuware, as well as application development and deployment software providers such as Borland and BEA, are now creating tools that enable customers to build and test services, to assemble composite applications made up of multiple services, and to handle changes to external services.
Integration tool providers such as SeeBeyond, and even business process management software suppliers, are also providing software to enable organisations to build composite applications based on services. Gartner analyst Charles Abrams advises: “If you do not deploy a web services producer platform, you will fail to be more agile than your customers.”
Integration and orchestration platform
The SOA needs an orchestration and integration platform to manage the way that all the different services interoperate with each other, to ensure performance, scalability and security, and to provide a platform for composite applications and for services such as analytics.
“The middleware infrastructure for the SOA will be the enterprise service bus,” says Massimo Pezzini of the Gartner Group. This is sweet music to a small handful of suppliers that are positioned as ESB specialists and pioneers – such as Sonic (a subsidiary of Progress Software), Blue Titan and Cape Clear.
The enterprise service bus strips out many of the higher-level transform and adaptor functions found in traditional broker products, and instead operates as a simple messaging service. Web services standards are used as the de facto standard for interfacing with the bus, which is a distributed system, not a centralised hub.
However, definitions of the ESB have shifted lately. The ESB, originally seen as a low cost tool for carrying out standardised, lightweight integration, will increasingly be used as a platform into which a variety of functions, including traditional integration broker tasks, can be plugged. In the process, traditional integration vendors, and even application server providers, claim they carry out ESB functions.
Gartner recently categorised most of the major integration broker companies as players in the ESB category – despite their higher price tag and complexity. Regardless of the terminology, enhanced integration products will form the basis of the SOA in most cases.
* For more on ESBs, see Information Age’s September 2004 edition.
Service oriented business applications (SOBA)
The SOA requires that functions traditionally embedded in ‘monolithic applications’ be exposed as services. In the process, it should be possible to compose and decompose packaged applications using third party tools.
A few suppliers have announced plans to do this. SAP, for example, has begun to unravel hundreds of processes and components, which can be accessed for use and re-use as services. These will then be integrated and managed by its Netweaver tool, which is now a key and mandatory component of mySAP.
Gartner calls this the SOBA – the service-oriented business application. It is advising customers that if their vendor does not have a clear roadmap for service orientation, they should “evaluate alternatives”.
