![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Web Services Experience Language (WSXL) offers the developer the flexibility to reconfigure and adapt to a web service as its components change, as you saw in Part 1 of this series. However, building a human-facing application with WSXL is a complicated process. To simplify the task of application building, you should begin with a foundation of WSXL base components. Then, you can build applications upon this foundation using collections of WSXL components, one of which could also be an aggregation of applications. (For definitions of many of the terms used in this series, see the Glossary.) Among these components is the control component, which determines which collection should serve as the active frame in a browser window displaying the aggregated services.
To ensure that interaction flows among the collections of components and the aggregated applications work properly, human-facing web services rely on reusable component groups and flow control mechanisms such as state machines, Web Services Flow Language (WSFL), and Business Processes Execution Language (BPEL). While WSXL encompasses the first two mechanisms, BPEL, the emerging standard on business processes, is a supplement to the workflow standard that helps standardize the view of business processes that the business partners with different technologies and business requirements take.
WSXL plays an important role in applying reusable groups of components to build web services. Preexisting WSXL components can be reused with other WSXL components and organized as reusable groups in a collection. This reusability provides you with the ability to reconfigure a web service by changing the order of execution of its components' activities and tweaking it in other ways to improve the web service's performance -- all without writing extensive new code.
If an aggregated application functions as a WSXL component in a collection, it must implement the WSXL component interfaces. The WSXL base interfaces include the four categories shown in Table 1. The life cycle category is particularly important; it is used to check the completion status of an activity before the application or component moves to the next activity or repeats itself. I've supplied a brief explanation for each category in the table.
Table 1. WSXL base component interfaces
| Interface category | Explanation |
| Inquiry | Basic inquiry operation that allows a client to require the WSDL service description document |
| Life cycle | Provides clients with means to indirectly refer to particular instances in subsequent calls |
| Property management | Allows clients to modify properties at times other than initialization |
| Output | Markup for output service |
If the collection contains a component that dictates in the end user's view of a page, it is a page-level collection. If a page-level collection implements the component interfaces, it can be composed into a higher-level collection. This means that several page-level collections can be regarded as reusable groups under a collection.
To synchronize multiple active presentations, you may group presentation components with a control component. Alternatively, presentation components might be aggregated to select from among them rather than to synchronize their function. For example, the control component can be used to determine which presentation component in a group is the active frame. If you wish, you can specify another presentation component as the active frame that can be recognized by the control component.
Controlling flows among components in a way that reflects the rules of interaction flows and business processes is important in building applications. Let's take a look at the three types of control mechanism that WSXL relies on: state machines, Web Services Flow Language (WSFL), and Business Processes Execution Language (BPEL).
According to the WSXL specification, a state machine is an abstract visualization of interaction flows -- that is, of the order of interactions that would take place from one point to another. (The same point could also be repeated in the flow for a specified number of times.) An example of a simplified version is shown in Figure 1.
Figure 1. State machine
In Figure 1, the state machine starts at node 1. When it completes the tasks there, it moves to the next state of the application -- node 2 or node 3, depending on the logic of conditional branching. If the machine gets to node 2, the interaction at this node repeats itself until it fully meets a preset condition and then goes to the final node, node 5, to implement another interaction flow. If the machine chooses to take the alternate route to node 3, it must decide what the next state or path of the interaction flow will be: node 4 or node 6, depending on the logic of branching conditions. Whatever the resulting outcome will be, the machine eventually proceeds to node 6. Then, it goes through a loop cycle until it satisfies a certain condition and ultimately goes to node 5 -- the final node in the flow. On the other hand, the machine may want to directly target node 4 and then move to the final node and the final state of interaction flow.
A state machine has a major drawback: It is only useful for visualizing workflows at the macro level of application interactions. The state machine is not very well suited for describing business processes at the micro level; it is abstract. An application within a collection could hold hundreds of business processes (for example, from product ordering to product delivery). Each process has a different set of logical steps for conditional branching to another process, application, collection, or user experience. The flow between processes and applications is better handled with a WSFL flow engine and even best with BPEL, not with a state diagram.
WSXL relies on a WSFL flow engine to trigger events according to the rules of business processes that require web services to interact with one another. A collection could allow itself to publish its behavior (for example, in response to queries during development and at runtime), which would describe how activities flow from one to another as defined by the WSFL flow model.
In this model, an activity (component) represents an operation on a web service. Activities connected by data and control links comprise business processes. By connecting activities, these links define the order of execution of each component within the collection. Each activity specifies a set of processes that need to be executed before proceeding to the next activity or repeating the current activity according to the logic of conditional branching through conditional expressions on control links.
Controlling flows of components, applications, interactions, and executions allows the WSFL flow engine to orchestrate web services, particularly user experiences as specified by WSXL. Each WSXL component has a Web Services Description Language (WSDL) life cycle interface. While the activity component is executing, the control component comes into play to make sure that event handlers are properly used to complete the activity component's task. When the activity component has completed its run, the flow model then determines whether the application should repeat the activity or go to the next activity in the flow.
In addition to the flow model used to describe business processes, WSFL also applies to the global model to describe overall partner interactions. This global perspective on business processes is not addressed by WSXL, however. This is where BPEL comes in to fill in the gap.
Business Processes Execution Language
BPEL provides greater flexibility over WSXL in building applications. It permits businesses to specify business processes that both consume and provide web services from a standardized viewpoint. It is defined by two complementary specifications: Web Services Coordination (WS-Coordination) and Web Services Transaction (WS-Transaction). WS-Coordination connects web services by coordinating the activities of a business process in the appropriate order of execution. WS-Transaction provides a mechanism to monitor the failure or success of the coordinated activities, even during a long-running transaction (for example, waiting for someone to start a process activity).
It takes three steps to externalize a system as a web service; to illustrate them, I'll use as an example a travel agency's system for making reservations with airlines, hotels, and car rental agencies. BPEL documents are executable scripts that can be interpreted using a business process engine to implement the described process. The steps for externalizing a system are as follows:
- Define business processes and connections with business partners (for example, airlines, hotels, and car rental agencies).
- Provide a mechanism to coordinate all activities involved in the business process, such as receiving an itinerary from a customer, sending the itinerary to an airline, requesting the tickets from the airline, and receiving the tickets from the airline.
- Provide a mechanism to control transactions on a task-by-task basis for each activity. Tasks might include filling out an itinerary form to be sent as a message, and putting the message in an input container to be later retrieved by the airline.
WSXL specifies the components you need to build applications for human-facing web services on portals, remote or local. The benefits of using WSXL far outweigh any disadvantages introduced by the complexity of the WSXL component model. One of WSXL's primary benefits is that it offers flexibility to reconfigure and adapt a web service as its components change. Another benefit is that WSXL relies on reusable groups and WSFL to build applications.
BPEL is well suited to building an application that externalizes a web service for business partners with different technologies and business requirements. This reflects the recognition accorded the business users and partners as important participants in the development of interactive, human-facing applications based on the external rules of business processes.
In a future article in this series, I will discuss how you can transform these applications into web services on portals as specified by Web Services for Remote Portals (WSRP), a WSXL component. Until then, I hope this article has given you ideas on how to improve your own human-facing web services.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middeware technologies, enterprise-wide systems, database technologies, application development, network management, distributed systems, component-based technologies, and project management. You can contact her at jmyerson@bellatlantic.net.
Next steps from IBM
WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
- Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
- Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
- Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
- Buy: WebSphere Application Server - Express
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
