Dr. Sean Baker is Chief Corporate Scientist, a member of IONA's Board of Directors, and a Co-Founder of IONA. Sean is based in IONA's Dublin headquarters with responsibility for research activities and regular contributions to technical publications. In the nine years since IONA's founding, Dr. Baker has served in a variety of roles, including executive vice president of customer and professional services, and vice president of Applied...
Research. Dr. Baker was a key contributor to the IONA e-Business Platform strategy, and he played a significant role in the development of IONA's patent-pending Adaptive Runtime Technology. He holds a Ph.D. in Computer Science from Trinity College in Dublin and has published a number of books and articles in the area of distributed computing.
Web services represent a significant new phase in the evolution of software development. As such they are attracting a great deal of media and industry hype. Vendors from all areas of the market are claiming leadership in the Web service arena -- most with little justification. As with so many new technologies, the immediate opportunities have been overstated, although the eventual impact may be huge.
There are already compelling reasons for investigating Web services, although they may not be the ones currently attracting the hype. The immediate and key role of Web services will be to provide paradigm shift in the way business manages IT infrastructure. They will overturn the accepted norms of integration and allow businesses to rapidly and effectively leverage the existing IT and information assets at their disposal. As with most seminal shifts this will not be revolution, but evolution and will stretch over a number of years. There will be three key steps, and the first steps should be taken now if firms wish to benefit and capitalise on the opportunities that Web services can deliver.
The state of IT integration today
The majority of businesses today are in an extremely dis-integrated state. Years of piecemeal IT development and investment have led to a situation common in all but the smallest organisations where there are numerous non-compatible systems. Each was developed or implemented to provide a specific function and there was no thought of integrating these systems. Many have been developed on different platforms using different languages -- not to mention the fact that each supports its own logical and business processes. Thus organisations have created numerous barriers within their own IT infrastructures.
The great business process re-engineering trend of the 1980s and 90s saw a drive to rationalise the way organisations operated, focusing end-to-end processes that streamlined the core business of an organisation and broke down barriers between departments and functions. Middleware and enterprise application integration grew on the back of this providing a way of stitching together different systems to support a centralised business process. Middleware or EAI projects have had some notable success and are often the best solution for specific, mission critical and high-performance systems, we should know -- Iona's first successes were built on its CORBA infrastructure. However, there are some serious limitations and drawbacks to the EAI approach when it is applied to enterprise-wide integration and inter-enterprise integration.
- It is very expensive. The complexity and bespoke nature of almost every integration project demands hundred of hours of EAI consultant's time in addition to the cost of the middleware solution itself. Gartner estimates that 40% of a project's costs and time are spent on integration issues. It further predicts a $500,000 entry point and 12 months to see any value even from discrete internal integration projects.
- EAI solutions depend on many point-to-point links that connect specific elements and functions of each system. Every one of these links has to be created and maintained. Moreover, once implemented each of these links is inflexible and needs to be updated to respond to any changes to the integrated systems or the processes. Not only is the maintenance bill in these cases astronomical but the on-benefit diminishes with each integration.
- However, by far the biggest danger with EAI integration project is that they simply produce larger islands of data, functionality and complexity. The old silos that BPR tried to destroy have simply been replaced by bigger and more complicated ones. Any business wishing to integrate a new application, or change a business process has a serious issue.
- This is what Iona terms the dis-integrated state. The mixture of non-integrated and point-to-point integrated systems that provides a very poor infrastructure for the agile connected business.
Step 1 -- Internal integration using Web services
Overcoming this state of disintegration is the key first step for an organisation, not just as the foundation for future integration with suppliers, customers and other third parties, but also in ensuring the continued competitiveness of the business overall. The creeping sclerosis of dis-integration, and the spiralling costs of constantly integrating and maintaining systems threatens organisations. Web services, first and foremost, provide a way to break-out of this value destroying cycle.
This first element of Web service integration, the essential prerequisite for further Web service projects, clears-up this internal mess to provide a flexible, scalable internal infrastructure that supports the needs of the business going forward.
Iona has used the Web service standards to create an integration platform capable of crossing internal boundaries between intra-enterprise applications and connecting middleware islands with m2m (middleware-to-middleware) integration. Gartner, Butler and other analyst groups agree that this is likely to be the first and most prevalent use of Web service technology in the short term.
Web services define a transport method for processes defined in XML. They are not about providing a user interface to applications nor are they applications in their own right and they do not process data. However, at the core of the Web service revolution is their ability to allow code to speak to code without human intervention. With this in mind organisations should see Web service integration as the next phase in the evolution of the tried and tested software bus model.
The existing accepted norm for integration is a point to point approach that connects A to B and then A to B to C to D to A as in the diagram below:
A more effective approach creates an end-to-anywhere approach that connects individual applications into a software bus that provides integration with any other application connected to it.
Using the Web service standards of UDDI, SOAP and WSDL, the Web service integration platform Web-enables internal application technologies. This does not mean that they need to be exposed on the Web, but it creates, for the first time, a software bus that bridges the boundaries between proprietary platforms, languages and code using a standard Web infrastructure.
This bus, christened Service Orientated Architecture (SOA) by the analysts, not only dramatically simplifies the integration of disparate systems, but also virtually eliminates ongoing management issues. The traditional approach quickly leads to hundreds of adaptors and interfaces for every new application or process change, whereas the 'bus' approach requires just one integration point for each. Moreover, non-Web-enabled technologies such as CORBA and EJB can now be integrated.
The benefits of this are easy to see. New systems, platforms and applications can be 'plugged in' to the bus to be immediately integrated with all the other systems on the bus. Just as with any other bus the SOA, powered by Web services, delivers information to all the connected applications (with necessary permissions and privileges). Time and cost of integration are massively reduced, and, in many cases, can be undertaken in-house. The result is standards-based ensuring flexibility and scalability as requirements change.
Even greater benefits become apparent when we examine how Web services integrate existing middleware implementations. Middleware, by its nature creates proprietary solutions. The languages used are also generally not compatible. This makes it very difficult to connect up the various islands of functionality that are often created inside a single organisation. The problem is exacerbated when a new application needs to call data or code from applications in different middleware islands. Crossing the boundaries between these implementations is the key challenge for business and one that many have already fallen foul of as they have tried to incorporate eBusiness or CRM applications.
Since Web services are the first standard for integration platforms they can be used inside the enterprise to integrate different middleware islands. Bespoke EAI projects and existing investment can therefore be protected and leveraged. So, an organisation that may have selected a CORBA-based integration in one area and used J2EE for another can integrate the two without needing throwing out either. Legacy applications and data can be treated in the same way allowing key elements of legacy infrastructure to be integrated even if only as a transitional measure. Web service integration thus ensures a fast and high return on assets and drives value from existing investments in IT.
For More Information:
- For insightful opinion and commentary, read our Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.