The new infrastructure
- Reduce text size Decrease text size
- Increase text size Increase text size
- Print article Print
- Jump to comments Comment
- Share this article Share
- Email article to a friend Email
The new middleware architecture requires new types of products. Choose with care.
The emergence of SOA (service-oriented architecture), BPM (business process management) and web services has had a classic, disruptive, effect on the software industry. Most customers are now thinking about a new type of software platform - or a new architectural approach - to link up all their systems, both new and old. The question is: what type of platform - or architecture - should that be?
Suppliers have been grappling with the same problem, and throughout 2003 and into 2004, have been engaged in a blitz of re-engineering, acquisitions, and repositioning. In almost every case, the objective has been to leave behind an established but vulnerable pre-web services niche and become a key component, even a platform, for the SOA.
Bob Sutor, IBM's global director of web services technology, outlines the customer's problem: By using SOA, and keeping services to a small number, it is possible to link applications using simple point-to-point integration, he says. But as systems become more complex and more services are introduced - and as a greater degree of interaction between services is required - they become far harder to manage.
"If you have inter-dependent web services, you introduce security requirements, or if you want to audit message traffic, point-to-point suddenly has a lot to do," he says.
The answer is to introduce middleware brokers or buses that can consolidate all the necessary information about the interfaces, orchestrate the services, handle transformations, store audit data and monitor performance.
These platforms can also be used in conjunction with process modelling tools to manage both automated and semi-automated processes, to provide analytical information, and as a platform on which to host new, 'composite applications'. Organisations preparing to move from a simple SOA or web services environment to a complex, mission critical architecture, are already finding that choosing the right architecture and platform is a complex business.
First, there are still issues with the standards and with product maturity. As ever, the marketing messages give an impression of maturity that is not necessarily supported in practice. This is critical, because the SOA model heavily rests on an assumption of openness, stability and re-use.
Web services standards, for example, adequately deal with finding and using a service, but important new standards dealing with how different services can be interlinked - such as BPEL4WS (business process execution language for web services) - are still not finalised. Many enterprises, even those using web services in live systems, are unwilling to take the risk of deploying unapproved standards for mission-critical applications, even though products are available from suppliers such as IBM and Microsoft.
"The open vision of everyone freely communicating using standards for all this stuff just isn't there yet," says Laurence Wilkes, technical director of think tank CBDI. "There's no reference implementations for transactions and BPEL out there. And you have to look at what suppliers are qualifying these products for use in. Will they give you production support?"
Second, and related to this, many organisations are still grappling with a complex environment with dozens, even hundreds of different systems in place. For example, many have development platforms, application servers, integration brokers, proprietary messaging systems, and, of course, large applications - some packaged, some bespoke.
"Despite web services standards, most SOA applications will remain locked into the platform vendors, application servers, integration suites, portal product or application platform suites," Gartner analyst David McCoy told a recent conference.
This is a warning to all IT directors that a single, central, orchestrating product is unlikely to be able to solve all their SOA problems. And even if such a product can do this, it may take a long time for users to fully exploit it. This may be a factor that plays to the strengths of certain incumbent integration leaders, who can offer an evolutionary - rather than revolutionary - route to the SOA, supporting older methods alongside new services.
Mike Gilipin of Forrester Research suggests that the answer to this complexity may lie in creating an SOA 'fabric'. This will consist of some heavyweight nodes carrying out multiple functions (such as application platform suites) and others that are lightweight, carrying out services such as integration.
This, he stresses, does not mean staying with the disjointed architecture of the present and past. "Such a runtime fabric will appear more like a single consistent framework for application development, deployment, integration and management," he says.
This is one of the paradoxes of the SOA. There is clearly a need for new, orchestrating products to manage processes at the centre; but the technology also makes it easier to do just the opposite - incorporate best of breed 'point solutions', even at the service layer.
Clearly, software suppliers are keen for their products to play a central, orchestrating role, where the licence fees are higher and the architectural influence is greater. There are four distinct groups from four distinct backgrounds all staking a claim:
- Application platform suites, from IBM, BEA, Oracle and Microsoft. These are primarily application servers coupled with a range of tools and functions added in.
- Integration vendors, such as See Beyond, Tibco, webMethods and Iona.
- BPM and other pure play web services orchestration suppliers, including Staffware and Intalio.
- Application vendors - most notably SAP, Oracle and PeopleSoft.
Of these groups, the integration vendors, led by See Beyond, Tibco and WebMethods, have most clearly set out on the SOA path. This is partly because SOA is an integrating architecture, and partly because they have no choice: non-SOA approaches will be wiped out.
Tibco, for example, stresses the importance of process management, while SeeBeyond is now positioning itself as an SOA and composite application platform. WebMethods' marketing director, John Dillon, describes the company as "transitioning to web services orchestration".
These companies are technically well-positioned compared with some of the newcomers in the orchestration field. Their expertise in areas such as transformation, reliability and transaction handling addresses almost exactly the areas where web services is weak. But they are also battling against falling margins for basic integration products.
Certainly, SeeBeyond, which has moved its product suite onto a J2EE application server base, has been rejuvenated by the SOA association - winning a huge contract with the UK's National Health Service and several others in recent months.
But the landscape continues to change. "We are at a critical point in the integration software market," says Jonathan Ebsworth, Cap Gemini Ernst &Young's global leader for integration services and solutions, referring to the entry into the market of SAP (with Netweaver) and Microsoft (with its revamped Biztalk 2004 product). "These two new entrants will change the market forever."
Gartner is now preparing the software world to drop many of the labels it has been used to for years, and adopt a new set of terms. It is now outlining four new categories of web services platform products covering development (ws producer platform), integration (ws provider platform) collaboration (ws management platform) and interaction (ws consumer platform).
Some products, of course, will claim to do all of this - and if the company making the claim is IBM or Microsoft, it might even be true. But customers should also remember that the SOA, if it all works as planned, gives customers the opportunity to mix and match services and platforms as never before.
| |||





