CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

Applying Web Services cont'd...

Eventually most software functionality will be published and consumed as Web Services. Three years ago this statement would have met with considerable skepticism, today many will agree. The entire industry is focused on this direction and, whilst there will be continuous evolution and morphing of the concepts, the momentum is now unstoppable.

However it will take some considerable time before this happens. First the standards, practices, tools and platform infrastructure are immature, second enterprise and ISV organizations have a both a huge portfolio of existing applications which need to be upgraded and a significant infrastructure and skills and practice development task. So meantime organizations need to a direct their energies in a manner that a) minimizes risk, b) enables learning in a controlled manner and c) maximizes the business impact of their early learning activity.

In this report we provide a framework to assist organizations in making these critical decisions.

Originally, Web Services were primarily presented as a way to expose object/component interfaces in such a way that they could be accessed across the Internet and outside the firewall - hence "Object Access" in SOAP. However, as SOAP went through the standards process the Web Service concept morphed into something more broadly applicable. Particularly important is the realization that the implementation behind a Web Service need not necessarily be object/component based and that it is equally valid for a Web Service to simply exchange documents as well as call methods.

Table 1 - Web Service "Conversion" Scenarios

Table 1 illustrates the wide variation of scenarios and styles that Web Services will be used in, all using the same protocols. Looking at many of the applications of Web Services so far it is clear their usage has been in what we term "Conversion Scenarios", as listed in Table 1. Organizations are typically converting or extending some existing business process and technology scenario to use Web Services, and whilst this has brought many benefits they have not yet exploited the new capabilities offered by Web Services to re-engineer their processes. For example there is little use so far of the more dynamic capabilities enabled by Web Services such as publishing, locating and consuming services at run-time.

It's not unusual that new technologies are initially deployed as an incremental or alternative function. No surprise therefore that Web Services often used in parallel to the existing business process and technology to provide an alternative access to information.

The challenge for organizations today is that each of these existing scenarios is normally associated with its own set of proprietary technologies. That is, the technology used for EDI is not suitable for distributed computing, which in turn not suitable for EAI, etc. As a consequence we have 5 times the products, 5 times the cost, training and skills etc

This can becomes a problem as organizations extend integration with new business processes that span not only their own organization, but also their partners and customers, then none of these existing solutions is really adequate. When customers, partners and internal systems are all involved in the same end-to-end process then organizations need to question the following

• Where for example, does EAI end and B2B Start?
• Is there a break in the process between them? Is the end-to-end process broken by manual steps, or batch transfers that introduce delays and errors?
• Does the need for the Real Time Enterprise or Straight Through Processing stop at your organizational boundary?
• How is the accuracy and visibility of information improved if the real source is external? Is the information you supply your customers and partners accurate and visible in real time?
• How does your partner provide information to your customer? Directly or via you?

As the scope of integration grows organizations need to use aspects of each of the existing scenario for the complete solution. But today because of their proprietary nature is can be very complex to string them all together. A key advantage that Web Services brings is that you can start to adopt a single standard framework that can be applied to all of these existing scenarios rather than continuing to use point solutions.

Ultimately, the use of Web Services blurs the distinction between the existing scenarios but as they are often the starting point for Web Service projects the following section examines in more detail some of the reasons for using Web Services in them.

Distributed Computing with Web Services

Web Services are simply a vastly improved form of distributed computing. Whilst some organizations have been successful with distributed computing deployments, the limitations are obvious.

Exposing existing or new component interfaces as SOAP has been made very easy by the various platform vendors, and is the most common application of Web Services to date. Web Services protocols are now effectively embedded within the platform making their usage transparent to the developer.

Advantages

• Technology independent
• Protocol Based
• Open Standards
• Loosely coupled
• Works inside and outside across the firewall
• Richer Specification

Suitability

• Exposing business algorithms, not just exposing information
• Component/object based systems
• Potentially complex transactions with emerging Web Service protocols
• Remote Procedure Call behavior. Though current best practice is now moving towards recommending the asynchronous document exchange style of Web Service for many implementations.

Web Site to Web Service

Converting existing website functionality to enable application to application connectivity through Web Services is one of the easiest of conversions to perform. There is no reason why existing e-commerce applications cannot be converted to Web Services either.

Advantages

• Leverage investments already made in web enabling existing systems
• Convert the existing information, forms etc., presented through web browser for customer, employee and partner self-service
• Use existing technology infrastructure, with minimal amount of effort required to upgrade to support Web Services
• Web Services directly supported, and relatively easy to implement in current Web Servers such as Apache, WebSphere, Windows Server, Weblogic, etc
• Technology used to provide secure external Web Sites can be used to used to provide external, secure Web Services

Suitability

• Information provision and Simple transactions. Even with emerging standards it is probably that existing form based website functionality has been designed in a way to support more complex transaction scenarios.
• Simple e-commerce transactions. For example providing Web Services to enable business partner to embed them in their own portal and resell products, but have the transaction made directly with the provider
• You don't expect communications to be any more reliable or robust than to your current web site

Portal with Web Services

The use of Web Services to extend portal usage is equally useful to the service consumer and provider, who

• Consume Web Services to build the portal. This doesn't really differ from consuming Web Services in any other scenario, except that portals by their very nature tend to consolidate information from diverse sources which makes Web Services ideal as a mechanism to provide that information.
• Provide Web Services by converting existing Portlets to enable remote consumption

Wider use of Web Services within portal scenarios will increase as emerging standards (WSRP ¹) are adopted

Advantages

• Portal Technology independence. Portals are often built using proprietary portal engines.
• Ease of integration for remote portal builder
• Portal vendors now providing Web Service support

Suitability

• As with web site

EAI with Web Services

Limitations of conventional EAI can be addressed to a great extent by Web Services. By converting the Enterprise Applications to provide Web Services natively for their interfaces, you can eliminate most requirements for adaptors. Many of the Packaged Applications that are the centre of EAI scenarios, for example SAP, have already been converted by their vendors to expose Web Services. However EAI doesn't disappear completely.

Web Services may not an immediate solution for all legacy applications as end-user organizations may not have the time or resources to build wrappers around them. Conventional EAI can continue to provide the adaptors that convert them to Web Services. The platform vendor that underpins the legacy application may also provide such a solution.

Adaptors will still be needed to now wrap existing applications with Web Services, where they are not provided natively

• The EAI hub typically provides other functionality that is still required for integration - most notably Business Process Orchestration. Though this is becoming Web Service based too. The challenge for EAI vendors will be to make their BPO engine Web Service compliant.
• Semantic conversion. Even though XML based, semantic conversion may still be necessary to convert documents passed between service consumer and provider unless they adhere to the same semantic standards - many of which are only just emerging.

So EAI doesn't go away - it just adapts to Web Services. Web Services should make it easier and faster to deliver EAI solutions. And perhaps most importantly, provide an EAI solution that is based on Open Standards rather than proprietary technology.

Advantages

• Standards based
• Remove some need for proprietary adaptors
• Leverage existing EAI infrastructure providing vendor provides Web Service upgrades
• Web Services can continue to use existing messaging infrastructure that may be part of the EAI architecture

Suitability

• Internal Web Services
• Exposing Web Services from Legacy systems
• Document exchange style of Web Services

EDI/B2B with Web Services

EDI and B2B is one of the most commonly presented Web Services scenarios. Today proprietary EDI and B2B gateways are widely used by large organizations but the high cost of implementation has prohibited their many smaller suppliers and partners from utilizing this approach. Frequently EDI is batch type of operation, and is not suitable to providing more real time information feeds, such as accurate stock availability, that may be required.

Thanks to the work of the EDI community, document exchange standards already exist and these are being evolved into XML and Web Service formats by initiatives such as XML.org. Additionally, ebXML.org has done much work to provide a XML-based standard protocol stack that includes SOAP messaging and a process orchestration mechanism that is needed to support standardized business processes to complement the document standards. However, much of the ebXML stack is in conflict with various similar Web Service initiatives. See the section on Web Service Protocols for more information.

Until the Web Service protocol stack matures, organizations can use ebXML for a comprehensive EDI/B2B solution though clearly there is the uncertainty of how these initiatives will merge in future.

Alternatively, organizations with simple EDI/B2B requirements can use the web site to Web Service or distributed computing conversion scenarios above to provide alternative lower cost access mechanisms for their partners, and deliver more timely information.

Advantages

• Lower cost of implementation, hence effectively available to all participants regardless of size
• Open standards rather than proprietary gateways and networks
• Enable real time exchanges

Suitability

• Near to middle term, complement existing EDI scenarios with Web Services for smaller participants

Contents...

• Abstract
• Introduction
• Conversion Scenarios
• Where to apply Web Services
• Exploitation Scenarios
• Application Policy
• Managing Participation
• Roadmap Actions