 | Level: Introductory Judith Myerson (jmyerson@bellatlantic.net), Systems architect and engineer
01 Oct 2002 In the first article in this series, Judith examined business users' collective viewpoints on how Web pages and remote portals should be presented, and briefly discussed the goals of the Web Services for Interactive Applications (WSIA) Technical Committee. In this article, she focuses on how the WSIA specifications are used to build human-facing applications. You'll learn about different methods you can use to control logical flows within large applications built out of many Web services components -- all with the goal of making your users' experiences as smooth as possible.
Introduction
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.
Reusable groups
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.
|
Glossary
Activity: A component representing an operation on a Web service. The flow model evaluates completion status for the activity to determine whether to repeat the activity, to proceed to the next activity in the flow, or end the flow.
Application: A component or collection of data, presentation, and control components that performs some useful task. An example would be a group of coordinated Web services that provides a user experience across the Internet.
Collection: A set of data, presentation, and control components that operate as a single function; analogous to a page in a standard Web context. If a page-level collection implements the component interface, that collection can be composed into another collection.
Component: A data, presentation, or control module that is designed to be reused in developing interactive Web service applications or be composed into a component model, either with or without modification.
Flow: A mechanism that describes a business process in terms of activities connected to one another by two types of links: data and control. The flow defines the order of activity execution, including conditional branching among the activities.
User experience: An experience that a user derives directly from a browser, indirectly through a portal, from the embedded part of a third-party interactive Web application, or any other distribution channel types. New user experience applications are created by combining applications and adapting them to new uses, such as a browser within a portal.
|
|
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.
Flow control
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).
State machines
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.
Web Services Flow
Language
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.
Conclusion
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.
About the author | | | 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.
|
Rate this page
| |
