Web Services and Workflow

If businesses want to benefit from the power of the Internet, web sites have to evolve. It is often no longer beneficial for them to only provide static information. It is necessary for these web sites to find ways that allow them to interact with other websites, operating systems, and applications. With Web Services it is finally possible to create functions that can easily be accessed over the Internet by both internal and external parties. In other words, with Web Services it is possible to integrate different value chains from different organizations with ease.

Web Services Protocol Stack

Web Services didn't just exist suddenly. They aren't a new revolution; rather they have to be seen as an evolution based on existing Internet protocols. They are the logical next step.

What, then, are the existing protocols that Web Services rely on? We can answer this by looking at the different layers upon which Web Services have been built.

First there was HTTP (HyperText Transfer Protocol); with this communication protocol it is possible to send information from one point on the Internet to another point. The information that is sent over the wire can be structured by using XML (eXtensible Markup Language). The XML protocol defines the format and the semantics of the information. XML is a basic foundation for the later layers. SOAP (Simple Object Access Protocol) is a protocol that defines how to invoke function calls from objects that live in different environments. By using SOAP it is possible to overcome problems that are raised when trying to integrate different operating systems, object models, and programming languages. With SOAP it became possible for the first time to easily integrate different kinds of business processes.

HTTP, XML, and SOAP can be seen as the core layers for Web Services. These layers define how Web Services have to interact with each other. These three protocols have been accepted by the W3C (World Wide Web Consortium, http://www.w3.org/) as standards.

The next layers have yet to be officially accepted by the W3C; they are, however, supported by big companies like IBM, Sun, and Microsoft.

The protocol WSDL (Web Services Description Language) describes how to communicate with a Web Service. In the WSDL definition, different types of communication (bindings) are allowed. It's one thing to have developed a Web Service, but it's another to earn money with it as well. In order to do this, we need a central market place where we can publish our Web Service, so other parties can find it and use it. This is where UDDI (Universal Description, Discovery and Integration) comes in.

Different organizations are now working on the last layer, which has to deal with workflow between Web Services. At the moment there are two parties, Microsoft and IBM, who have both defined their own kind of XML protocol that supports workflow. We will look into these protocols in more detail in a moment.

The following figure charts the relative position of these protocols in a Web Service stack, and plots their emergence over time.

Web Services Programming Model

One of the main goals of Web Services is to enable software developers to seamlessly integrate applications and services with each other, regardless of the operating system an application runs on, regardless of the object model an application depends on, and regardless of which programming language the application has been written in. Software developers can only do this if they are provided with a Web Services Programming Model.

The following image represents this programming model.

The Web Services Programming Model consists of three core components: service brokers, service providers and service requesters. A service broker acts as an intermediary between the service provider and the service requester, so they are able to find each other. A service provider simply deploys Web Services. A service requester tries to find Web Services by using the service broker; if it finds a Web Service it wants to use, it tries to set up a contract with the service provider in order to consume the Web Service, and thus do business.

The interesting thing about this programming model is the fact that the Web Service that is being sold can itself make use of several other Web Services. Each of these Web Services will be based on the same programming model, so we have recursive use of the model. This, however, will be transparent to the end consumer of the Web Service.

The Case for Workflow

In this section I will discuss a case that explains the workflow between different Web Services that are provided by several external parties. After the case description I will look at some of the main problems that appear when dealing with the integration of Web Services provided by different parties.

Case study - Pizza Company

To better understand the flow between different Web Services and the problems that might surface when dealing with integration I would like to discuss an imaginary Futuristic Pizza Company.

In the Futuristic Pizza Company there are two kinds of employees: pizza delivery boys and pizza bakers. When a delivery boy starts his shift, he logs on to the pizza server. He does this by using the Authenticate service (see figure 3); after having his credentials checked, the delivery boy is assigned a bike by the Profile service. The Profile service defines which bike (Bike Web Service) meets the physical requirements of the delivery boy. Then the delivery boy has to wait for the first order...

After a hard day of work I want to eat pizza. With my WAP enabled mobile phone I dial the Futuristic Pizza Company, and after identifying (Authenticate service) myself, my profile (Profile Web Service) determines which kinds of pizzas I like. The Pizza Catalog service offers me four kinds of pizzas; after selecting my favorite pizza (Four Seasons) I have to agree with the costs, and my credit card number (which is included in my profile) is validated by the Credit Card Validation Web Service. If everything is okay, my account is debited and the pizza company's account is credited. Meanwhile, the pizza baker is alerted to my order, because after my selection the pizza appears in his browser, which is integrated with his cooking gear.

After this transaction the GPS Web Service is called in order to get my location from my phone. These co-ordinates are then passed onto a Map Web Service, which processes the co-ordinates and sends a map with the exact route to the pizza delivery boy on his PDA. The boy then only needs to deliver the pizza. In the mean time I receive an SMS text message on my mobile phone that tells me that my pizza will be delivered within 20 minutes. Simple.

The Problem of Integration

It would be too expensive for a pizza company to develop all these kinds of Web Services by itself. If it develops any, it will probably only be the pizza catalog and the bike Web Service, since these are more specific to their operation. Instead, it would use other Web Services that are available on the Internet.

The owner of the Futuristic Pizza Company would need to integrate these external Web Services with her own business process. During this integration, she has to deal with several kinds of problems:

 

• Multiple Partner Processes - When integrating with partners you have to take into account the processing time of each Web Service. If a certain Web Service takes too much time processing a request, you might be better of by finding another partner with a better (faster) Web Service.
• Transaction Handling - Let's take a look at the Credit card validation Web Service in our example. After validating my credit card number the balance of two accounts have to be changed. From one account ten dollars for the pizza must be debited, and the other account must be credited with ten dollars. If something goes wrong during this process, for example my account won't be debited for ten dollars, this process needs to be rolled back and neither account changed, otherwise money can be created (or lost) on the fly.
• Exception Handling - If an error occurs during a business process, an end user needs to be notified, so the business process needs to know how to handle exceptions.
• Handling Incompatibilties - At this moment there are about 35 vendors shipping toolkits that make it easy to change an existing application into a Web Service. However all these toolkits use their own implementation of the WSDL specification. This means that you have to deal with incompatibilities when dealing with the integration of Web Services.
• Dependency - When integrating with Web Services from external parties, you become dependent. Because of the nature of Web Services you don't have any control over Web Services that are developed by external parties. So if a server from an external party goes down, for example, this will certainly affect the outcome of your application. When dealing with external Web Services there is always an element of trust involved.
• Flexibility - The business around us is changing rapidly, so applications that are constructed by using Web Services need to be flexible. You need the capability to switch to an alternative Web Service that offers the same functionality should any problems occur with your first choice.

The main goal of Web Services is to enable software developers to easily integrate different kinds of applications and services with each other, without having to worry about the underlying protocols, interfaces, environmental conditions, etc. There needs to be a way to relieve software developers of having to think about the issues mentioned above.

Workflow Specifications

As we have seen above, software developers need a protocol that is capable of capturing the workflow of a business process. The protocol needs to create an XML representation of the underlying business process, so middleware applications can understand this protocol and thus takes care of the issues mentioned earlier one. There are currently two specifications for this process: XLANG and WSFL. These will be discussed in the next two sections.

XLANG

XLANG (Web Services for Business Process Design) was originally developed by Microsoft for BizTalk Server 2000. In BizTalk someone can draw a workflow, using the BizTalk Orchestration tools, which will then get translated (after saving) into an XLANG schema.

The main features of the XLANG specification are as follows:

 

• Sequential and parallel control flow constructs
• Long running transactions with compensation
• Custom correlation of messages
• Flexible handling of internal and external exceptions
• Modular Behavior Description
• Dynamic service referral
• Multi-role contracts

It is, unfortunately, beyond the scope of this article to dive into all these aspects of the XLANG specification. If you want to learn more, you can find further information at the following URL:

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

In summary, although Sun's vision for Web Services has been confused until now, there are signs that they are developing it. Java has most of the requirements already in place for creating Web Services and there is an extensive knowledge and skill base of Java programmers. The remaining pieces are beginning to emerge, namely the relevant APIs are near completion, and the toolkits for applications development have been promised in the near future.

The support for Web Services within BizTalk Server 2000 has been initially rather poor. You can't just drag and drop a Web Service into Orchestration Designer; some work has to be done by the software developer. Because of the fact that Microsoft .NET depends heavily on Web Services one might expect that the next version of BizTalk will include support for Web Services as well. This might influence the XLANG specifications.

Secondly the XLANG specification depends heavily on the WSDL specification, which itself still has some issues that haven't been tackled yet. As soon as these problems have been dealt with, it is reasonable to expect that the XLANG specifications might undergo some changes.

WSFL

WSFL (Web Services Flow Language) has been developed by IBM. The WSFL specification considers two types of Web Service compositions:

• Flow models - the flow model describes how to achieve a particular business goal.
• Global models - the global model describes how Web Services have to interact with each other.

More information about this specification can be found at the following URL:

http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

The WSFL protocol also heavily depends on WSDL. If changes happen to WSDL, these might have some impact on WSFL as well.

Conclusion

With Web Services it becomes possible to overcome the physical boundaries of existing organizations. By using Web Services we are no longer constrained by operating systems, object models, and programming models. The Gartner Group is predicting in their report "How Web Services Mean Business" that "through 2H02, 75 percent of enterprises with greater than $100 million in revenue will interface periodically with Web Services."

With Web Services we will be able to seamlessly integrate with value chains from different companies, and thus be able to create new business processes and business models.

In the article we have seen that all kinds of issues may surface when dealing with integration. The mentioned specifications XLANG and WSFL are beginning to solve these kinds of problems for software developers, so they can focus on building the actual end result offered by a Web Service. These two specifications have recently seen the light and further changes might be expected if the underlying protocol WSDL undergoes some improvements.

Perhaps the most important thing here is that by moving from sharing information to sharing processes, the Internet is finally fulfilling its promise.