The Web has always been service-oriented. Services such as auctions or ticket-buying services are available today to general Web users. Essentially, what the Web did for interactions between business functions and their users, Web services will do for interactions between functions spread out across multiple business units or even across multiple businesses.

Because of this, a number of organizations are trying to design and build a Web service-oriented architecture (WSOA). The good news is that most of them are already on the right path to getting there. This next wave of application development is a natural extension of the move toward component-based standards such as J2EE and COM. Web services are unique in that they rely entirely on Internet-standard technologies. (Note: Web services rely on existing standards such as XML messaging [SOAP], Internet standard transport [HTTP, FTP, SMTP], and emerging standards such as WSDL, UDDI, and WSFL.) They build on distributed, component-oriented environments, rather than throwing them away and starting from scratch.

The biggest departure from component-based development (CBD) is that a WSOA is likely to be very process-centric as opposed to the program-centric applications of the earlier waves of application development. That's because organizations will use Web services to provide access to higher-level business functions rather than to their components or legacy systems. For example, car rental agencies want to expose the process of renting a car or checking on its status, and not the inventory system or the order entry system that implements parts of those business functions. Similarly, an insurance company wants to expose the process of renewing an insurance policy or checking the status of a claim, instead of providing access to the legacy systems or databases that contain the required information.

A critical enabling technology is business process integration (BPI). BPI extends integration capabilities by providing a graphical interface that enables business users to model business processes that are core to an organization's operations. BPI allows the use of functionality from existing applications, regardless of the technology with which the applications were developed. BPI also handles issues such as load balancing, fault-tolerance, and scalability, so business processes can be executed at any time by as many customers and partners as necessary.

Essentially, BPI enables organizations to create an internal WSOA that lets them effectively leverage their existing investments and take advantage of Web services. Basic to the WSOA paradigm is the shift away from the traditional approach of building customized systems to focusing on the business process. Organizations have heavy investments in existing systems, applications, and people. A WSOA built on the foundations of BPI provides a practical approach to delivering business value while preserving existing investments. BPI enables the WSOA to evolve incrementally and forces it to stay closely aligned with business drivers. It provides an alternative to the endless treadmill of application rewrites and custom coding.

Building a WSOA
In a WSOA, components are aggregated in a simplified manner to accomplish a specific business function. Components are binaries that have a defined interface and perform a specific task, for example "authenticate user," "debit account," or "approve credit card." A service is simply a logical grouping of these components to accomplish a business function such as "renew an insurance policy" or "rent a car" or "process a loan application." This logical grouping of components can then be exposed to the outside world over the Internet as a Web service.

With a WSOA, the focus on the business process enables a much higher level of application development than in the past. It's also more closely tied to business requirements than technical requirements.

For this potential to be realized, the BPI technology must enable processes to be quickly and dynamically created from functionality in multiple, preexisting, back-end systems that are incompatible. It must allow deployment of those processes to a robust execution engine. Finally, it must facilitate the exposure of these processes or various parts or combinations of these processes via the Internet-standard technologies of Web services.

Newer, emerging BPI products enable model-driven visual definition and automation of business processes. Using a sophisticated modeling environment, organizations can define business processes and leverage a powerful connectivity framework that includes numerous point-and-click wizards for interacting with existing legacy business systems as well as newer component-based systems, including J2EE, COM, and Web services themselves. Some even provide a high-performance, high-availability engine for deploying and executing these business processes in an extremely reliable manner. Any such process, portions of the process, or groups of these processes may be exposed to the outside world in the form of Web services.

Building a WSOA with BPI
Using an insurance industry example helps illustrate how to build a WSOA. Many insurance companies have a large number of existing monolithic applications that have been built up over the years using a variety of incompatible technologies. They performed well on the tasks for which they were originally designed, but little thought was given to interoperability between these systems. Many of these organizations now want to deploy a WSOA that provides access to key business functions such as "renewing an insurance policy" or "checking the status of a claim" in a standardized manner over the Internet. They want to build and deploy the WSOA incrementally by automating business functions in bits and pieces, adding to them over time, leveraging existing applications, and building on those successes.

The WSOA is built in layers using existing technology. Below is a description of the layers and then an overview of the combined work at the end.

Components
A component is a binary piece of code whose sole purpose is to do one and only one thing. In the example, there are four components, each having its own purpose:

• Policy: Provides access to policies that have been issued, including detailed policy information. It will need to access a legacy IBM mainframe system in order to provide this functionality.
• Claims: Provides access to the company's claims system, including the status of any claims or the list of outstanding claims against a particular insurance policy. The claims system is also implemented via a legacy IBM mainframe system but is accessed via MQSeries.
• Quotes: Uses the latest information available to generate a quote for a particular insurance policy. Given existing policy information, new policy requirements and other information about an applicant, this component can compute the premium for a new policy. The quotes system was recently rebuilt using EJB technology and runs in the WebSphere environment.
• Payment: Provides access to payment information, including premiums that have been paid for a particular policy, payment dates, etc. This system runs in a Microsoft environment.

As Figure 1 shows, the most convenient way to access each component is different. BPI technology allows each component to be created using the most appropriate technology for that platform. However, it doesn't preclude the creation of internal Web services to expose the functionality in each back-end system.

By and large, most organizations are already well down the path toward componentizing using one or more technologies. BPI technology can leverage these efforts and build on top of existing component strategies to enable the WSOA.

Services
A service is simply a logical grouping of these components to accomplish a business function such as "renew an insurance policy" or "check the status of a claim." This logical grouping of components becomes a Web service if it is exposed to the outside world using Internet-standard technologies such as SOAP and WSDL.

In this case, the business requirements are to provide access to several business functions. Customers should be able to check the status of a pending claim and agents should be able to generate quotes for new policies or renewals. Executives would also need reports describing the number and kind of new quotes that were generated and policies that were issued in any given time period. The following services are a subset of these business requirements (see Figure 2):

• Check Claim Status: This service is utilized by end customers or by insurance agents to check the status of a pending claim.
• Renew Policy Quote: Agents use this service for quoting a premium for a policy renewal.
• Daily Report: Managers can obtain reports about daily activity.

It doesn't require all components to be created using one particular standard such as EJB, COM, or XML. The process can mix and match components created using incompatible technologies.

Service Manager
The service manager is the runtime engine that enables client applications to access and execute the services that have been created above. The engine must deliver high performance and high reliability to the WSOA without requiring the organization to invest significant expertise on infrastructure and middleware.

A BPI engine can provide a very high-performance, scalable, robust execution environment for internal as well as collaborative business processes. The engine is equally capable of executing long-running processes that may run for weeks as well as short-running straightthrough processes that are fully automated and may run for a few milliseconds.

Client Access
The WSOA provides services that are designed for programmatic access and does not include a user interface layer (see Figure 3). This provides maximum flexibility. The same service may be accessed from a user interface such as a Web browser via a JSP or from a business partner application via an XML SOAP message sent over the Internet. BPI provides the ability to expose the business process via a variety of technologies. The same business process can be accessed:

• As a Web service using XML messaging over HTTP
• By a Web browser through a portal using JSP, ASP, servlets, etc.
• By fat clients such as Java or VB applications
• By mobile devices such as cellular telephones or wireless PDAs.

The variety of applications and technologies typical of most organizations can be incrementally incorporated into the integration via wizards, tools, and adapters provided by the same modeling environment. The business process models are then deployed to an execution engine that automates all the issues normally associated with complex, distributed systems, including performance, scalability, load balancing, and fault tolerance. The engine provides access to the business process models through a wide variety of client protocols.

Typically, the system can be easily administered from a single, centralized location using nothing more than a Web browser. A powerful, sophisticated security infrastructure, based on existing corporate and Internet security standards guarantees secure access to the business functionality embodied in the exposed business processes and ensures that access is provided only to authorized entities.

Finally, the modeling environment provides a single, unified graphical user interface that business users and developers alike can use to do their work and share among those users. This reduces training issues and costs associated with deploying multiple tools.

Summary
Web services enable organizations to automate interactions between business units, thereby reducing the cost of doing business and making the overall process more effective, efficient, and flexible. Ultimately, Web services improve customer satisfaction and favorably impact the bottom line.

To effectively implement Web services, many organizations are already designing and building a WSOA. Fortunately, this new wave of application development is a natural extension of component-based standards and architectures like J2EE and COM. Web services are built on the distributed, component-oriented environment that is already in place at many organizations.

A critical enabling technology for implementing a services architecture is business process integration. BPI lets organizations create an internal WSOA that allows them to effectively leverage their existing investments and take advantage of Web services. A WSOA built on the foundations of BPI provides a practical approach to delivering business value while preserving existing investments in people and systems. This is because BPI enables the WSOA to evolve incrementally and provides a seamless alternative to endless rewrites and custom coding.

Author Bio
Dr. Ashish Deshpande, CTO and cofounder of Metaserver, is a leading authority on the business process integration space and has more than 15 years of experience with B2B technology, network computing, and distributed parallel processing. He holds a PhD in computer science from Yale University, an MS in computer science from the University of Virginia, and a bachelor of technology in computer science and engineering from the Indian Institute of Technology at Bombay. info@sys-con.com