Columns

Web services in harmony

• By John D. Williams
• September 1, 2002

The XML Web Services One conference in San Jose provided an excellent opportunity to see the burgeoning growth of Web services, which is still in its early days. Discussions focused on helping developers to understand the concepts and low-level technical details of the technology, as well as how Web services will affect them. Savvy developers focused on finding the best ways to exploit Web services and bring value to the business.

But how will developers deliver new applications rapidly? Through the use of composite applications and orchestrations. A composite application is ''a configurable, user-centric business process fused from multiple applications that make their capability available as services.'' From a technology perspective, ''multiple applications'' and other selected capabilities are made available as Web services. A composite application defines a process that weaves together a set of the available services to create a new capability. A process engine then executes this newly defined process. The value of a composite app is that it allows you to quickly define and deploy new processes to the business. It also allows you to exploit existing capability without redeveloping it. The scope of a composite application is typically within the bounds of a single company, though it can span the world for that company.

As an example of a composite application, let's look at the new product introduction process for a manufacturer. The process typically starts as part of a demand planning process where there is an evaluation of market requirements and product life cycles. This activity will, in turn, drive R&D and product prototyping. If the prototype is successful and the decision is made to produce the product, that will drive product engineering, product demand planning and a host of supply-chain activities. At the same time, new marketing and sales campaigns must be readied and sales forecasts estimated.

As you can see, the process of introducing a new product crosses many different functional areas of the business, each with its own set of supporting systems. A composite application weaves these disparate systems together to create a seamless application to support the introduction of new products. Imagine the value a business would see if that process could be improved. Furthermore, using a composite application gives the business more flexibility to quickly change the process as needed. No wonder developers, keen on delivering business value, see composite applications as a golden opportunity to help their companies.

An orchestration is similar to a composite application, except its scope is between different enterprises. An orchestration is a configurable process composed of capabilities from two or more companies. These capabilities are also made available as Web services. Different parts of the process will run within each company's environment. The bridging of boundaries between companies adds some requirements that are not typical of composite applications. For example, in interactions between businesses, transactions may be very long-lived. What happens when it takes weeks to complete a process? There are other differences as well. For example, where do you draw the boundary about what an orchestration needs to know about a company's processes vs. what it does not need to know? Typically, orchestrations do not need to know a business's internal processes. It needs to understand the interaction processes. It also needs a clear definition of the semantics of the interactions and the touch points to the internal processes. As such, orchestrations are typically system- rather than user-centric.

Is there an example of an orchestration? Let me give you a good candidate. A recent Wall Street Journal article described the approach Circuit City is using to sell CDs on the Web. It wanted to expand its Web site to sell a variety of CDs, but did not want to bear the cost of stocking a large inventory. Rather than carry the inventory itself, the company went to an Internet ''category manager'' -- Alliance Entertainment. Now when a customer on the Circuit City Web site wants to buy a CD, they are routed to a Circuit City branded site that is run by Alliance Entertainment, which ships the CD from its inventory. If a customer wants to return a CD, they can take it to their local Circuit City store rather than ship it back. A flexible approach to automating these processes would help minimize costs and allow for rapid adaptation to changing market conditions.

Pipe dream or reality?
We are certainly in the early days of making all this happen. As such, there are plenty of potholes to hit on the road to implementation. Yet the demand is there and vendors are working to fill the gaps. So what do you need to develop your own composite applications and orchestrations? Start with what you have. Can you identify the legacy systems, components or other capabilities you wish to integrate? How will you know which ones to make available as Web services? The best candidates for a composite application typically cross business functions. Each business function will usually have its own supporting systems. Composite applications are most valuable when they integrate disparate systems. If the need falls solely within a single business function, it is usually not a good candidate for a composite application. Use an enterprise architecture to help you identify the relevant business functions and their service relationships.

Orchestrations, by default, integrate multiple systems. The issue for orchestrations is their amenability to automation. Some types of transactions are best done face-to-face. Others are more amenable to system-to-system communication. Currently, the best orchestration candidates will be those where you can clearly define the semantics of the interaction. Security is also an issue. Web service security is still evolving. SSL is available, but may be inadequate for the level of authentication needed. Proposed standards include XML Signature, which could be used in conjunction with XML Key Management Specification (XKMS) to ensure a communication is authentic and has not been tampered with. Other evolving trends include Security Assertion Markup Language (SAML) and numerous products from third parties. You can also use dedicated networks to increase security.

Once you've selected an appropriate candidate, how do you know which capabilities to make available as Web services? Again, enterprise architecture can help you identify which systems support the relevant business functions, what information flows are needed between the systems, and the relevant processes that need to be integrated. In dealing with existing systems, you'll find that work you've done in the area of EAI will pay off. The challenge in finding proper integration points is the same: Good interfaces for EAI are likely to be good for Web services. Use enterprise architecture to uncover the needed service and information flows. You may discover additional integration points for your legacy systems.

The technology needed for these applications centers around Web services. As you would expect, SOAP and WSDL will be essential technology components. A private UDDI is also useful, so the location of services can be changed as needed and the application will still find them. Another essential component is a process engine. Web service tool vendors are moving quickly into this area. One challenge in selecting a vendor is trying to pick one that supports industry standards. There are only proposals in this area, no real standards. Microsoft has XLANG. IBM has WSFL. A consortium proposed BPML, but it seems to be dying. The best bet right now is to look for future synergy between XLANG and WSFL. These languages are appropriate for composite applications, but may be problematic for orchestrations. You may want to look at support for ebXML as a way to support the semantics of inter-business interaction. Rather than try to piece the technology together yourself, a number of vendors have packages that cover most of what is needed to implement composite applications and orchestrations. These packages can be expensive, but they can cut down significantly on integration and development time.