The example presented here is a preplanned response to a natural disaster requiring supplies and medical aid. The first step is to identify vessels that have operating rooms and infirmaries with occupancy below a specified threshold. This is accomplished by invoking the partner link to the Command Support System with appropriate constraint parameters.

The next step is to identify personnel with appropriate job classifications for providing medical attention to evacuees by invoking the Personnel Management System partner link using the list of ships returned by the previous step.

The third step is available in the event that the afflicted region is struck with disease in the wake of the disaster. The identified medical personnel list is then used as input to the Joint Medical System to isolate any personnel who may not have the necessary vaccinations and would be at risk by providing care.

An absolute constant in any mission package is evaluating the effects of weather. Weather has a vast number of impacts which can be computed using the parameters available from our Meteorological and Oceanographic partner links. The first of these impacts that needs to be considered for this type of operation is conditions en route and at the location where the ship is to be anchored. These conditions include sea state, wave height, and harbor depth, among several others. Additional conditions that need attention upon arrival at the destination include precipitation, visibility, wind speed, and direction, because these directly impact the ability of helicopters to take off and land, as well as the ability of transport vessels to unload the ship's cargo and bring it ashore.

Once suitable support vessels and routes have been identified, the final anchoring location will need to be a confirmed safe zone based on proximity of known hazardous materials and predicted weather effects. Two more partner links will be used in this step, the Integrated Materials System, which provides information about industrial material storage locations like large chemical or fuel depots, and the Hazardous Plume Analysis System, which can perform simulations of the spread of those materials in the event of a release. The weather data collected from the previous step in conjunction with the known hazardous material stores are provided as inputs to the Hazardous Plume Analysis partner link. The Hazardous Plume Analysis service performs calculations and returns information that establishes safe zones.

The final step is to package the results and send them to our final partner link, an Open Geospatial Consortium (OGC) Web Feature Service (WFS)-compliant visualization tool that can geospatially present the suitable vessels, the medical personnel and facilities status, traversable routes to the afflicted region, and safe anchoring locations outside the range of hazardous material plumes. By utilizing these technologies as force multipliers, we're able to improve the accuracy of the information provided to decision makers by executing mission planning on the order of hours rather than days.

The flexibility and reusability of BPEL is clearly demonstrated through the orchestrations that have been composed that are integrating these same partner links but targeting different operational requirements such as maritime-domain awareness, which centers on safety of international trade shipping and the global war on terrorism.

BPEL + WSRF
The Web services architecture has been broadly accepted as a means of structuring interactions among distributed software systems. However, discussions regarding additional standardization are required to facilitate further interoperability among services, particularly those concerning stateful resources. One effort in addressing these issues is the Web Services Resource Framework (WSRF). The WSRF defines the relationship between Web services and stateful resources in what is referred to as an implied resource pattern. This implied resource pattern is a set of conventions based on existing Web service standards, and chief among them is WS-Addressing. The WSRF also presents an approach for life-cycle management of the resource as well as for defining a standardized Web service interface for accessing the resource and its associated properties.

As I read about WSRF, I looked at leveraging this concept within the context of BPEL. Orchestration performed with BPEL is incredibly powerful for standardizing the linking of partners with private service implementations. BPEL is also often used to encapsulate concrete executable processes, frequently integrating services that operate on the same data sets yet reference, consume, and publish the data in very different ways. Process engineers who use this concept are able to think in terms of nouns and verbs, composing orchestrations that simply direct services to act upon specified resources in a consistent manner rather than translating disparate input and output schemas.

Common in WSRF is the use of a factory pattern for creating WS-Resources. The WS-Resource factory is itself exposed as a WSDL-described Web service. Figure 4 outlines the BPEL composed to demonstrate simple WSRF integration. The first step is to instantiate a new WS-Resource by invoking the resource factory's createResource method. Instantiating a WS-Resource entails creating a new stateful resource with an identity, and associating the new stateful resource with a Web service as outlined in the implied resource pattern. The next step is to assign the values of an input variable and configure the WS-Addressing fields with unique identifier information returned from the resource factory service. The most significant is the ResourceKey, which was returned by the resource factory identifying the newly created WS-Resource. Subsequently the BPEL invokes an operation on a resource-aware Web service, specifying the WS-Resource identifier to be used. In our case the simple operation simply updates the resource's stateful value with one passed as an input parameter. Last, we demonstrate calling one of the WSRF's standard methods for retrieving WS-Resource properties to verify that the stateful resource had in fact been updated.

I performed my experimentation using the Oracle BPEL engine and the Globus Toolkit as my WSRF implementation. WSRF currently requires the WS-Addressing resource identifying information to be passed in the SOAP header. Therefore, on the WSRF service invocations in the BPEL listing we did make use of the extension inputHeaderVariable. These same headers are normally handled transparently by the Globus Toolkit implementation of WSRF, so I've also included code listings for the modifications I made to the generated WSDLs to make the SOAP header values explicit and visible to the BPEL engine. I believe significant value would be realized if these specifications evolve with consideration to improved synergy between stateful processes and service-addressable stateful resources.

This experimentation makes a case for information exploitation technologies, such as Web services and orchestration using BPEL, with an eye to the future and provisioning computing resources. Organizations electing to deploy more advanced automation solutions are able to increase the flexibility and efficiency of their information infrastructures that support their decision makers.

Conclusion
BPEL provides the standards-based, platform-neutral foundation to compose service interactions based on their message exchange behaviors while managing the myriad of complexities inherent with process-level systems integration. As such, government agencies and industries alike have leveraged this capability to assist in time-critical decision making. Web services, related standards, and architectural principles allow us to leverage concepts and technologies such as BPEL to develop effective and efficient decision-support environments.

Resources

• Business Process Execution Language (BPEL): www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
• Web Services Resource Framework (WSRF): www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf

BPEL
MyProcess.bpel - WSRF BPEL Example
MyFactoryService
MyFactory.wsdl - Globus generated WSDL
MyFactory_flattened.wsdl - Globus generated WSDL
MyFactory_bindings.wsdl - Globus generated WSDL
bpel_MyFactory_service.wsdl - Modified Globus generated WSDL
MyService
My.wsdl - Globus generated WSDL
bpel_My_flattened.wsdl - Modified Globus generated WSDL
bpel_My_bindings.wsdl - Modified Globus generated WSDL
bpel_My_service.wsdl - Modified Globus generated WSDL