Demonstrating WSMX: Least Cost Supply Management

Table of Contents Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

Introduction Web services. Semantic web. Semantic Web services.

Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

Motivation For demonstrating the potential of WSMX we selected a use case from the telecommunications sector. Internet Service providers are extending their business with wholesaling of mobile and fixed line telephone services and unbundled data lines. Easy and flexible dynamic integration of suppliers that offer these services is needed.

Description An ADSL line is a broadband Internet connection on top of a regular telephone line. Several suppliers of unbundled ADSL lines are available depending on region where the customer is located. Wholesalers need a flexible and dynamic integration of these suppliers in their back-end systems.

Objectives ADSL line suppliers have different end point interfaces. Message mediation between wholesalers and ADSL supplier is needed. Line suppliers differ in capability to provide an ADSL line for given phone number (it depends on region). Least cost supplier which can provide ADSL line for given phone number must be dynamic found and bounded into a ordering process flow.

Process Flow Steps Static wholesaler ordering ADSL line process is realized as a WS-BPEL complex process controlled by an BPEL execution engine. Web services for check of a bank card, availability of internet domain, billing etc. are invoked directly by the BPEL execution engine. ADSL suppliers have to register their services within the WSMX service repository where the capabilities and mapping rules should be stored. To find proper ADSL provider, BPEL process of wholesaler invokes WSMX engine sending him goal description and other needed information in form of a SOAP message.

Use Case Process Flow Diagram

Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

Introduction Execution environment for Semantic Web Services. A reference implementation for WSMO. Service oriented and event-based architecture. Decouples service providers and requesters. Dynamic discovery based on Goal-Capability matching. Mediation. –Data. –Process. –Protocol.

WSMX Architecture

WSMX Discovery Mechanism Based on matching of logical goals with WS capabilities. Goals and capabilities have postconditions and effects. Capabilities additionally have preconditions and assumptions.

Current WSMX Architecture

Implementation Event based service oriented architecture. Current status: –Code base established – available at SourceForge. –Data mediation component implemented. –Other component interfaces defined and partially implemented. Main technologies used: –Apache Tomcat and Apache Axis. –Database – mySQL. –Eclipse IDE and Ant as build tool.

Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

WS-BPEL Standard Process modelling language based on Web services. Widely used for automation of business processes. BPEL was originally developed by BEA, IBM, and Microsoft. Version 1.1 also includes input from SAP and Siebel.5. The OASIS TC “web services business execution language” now continues the standardization of BPEL.

WS-BPEL Overview WS-BPEL defines business processes consisting of stateful long-running interactions in which each interaction has a beginning, a defined behavior and an end, modeled by a flow. Flow is composed by a sequence of activities. The behavior context for each activity is provided by a scope. A scope can provide fault handlers, event handlers, compensation handlers and a set of data variables and correlation sets.

WS-BPEL Process Flow Scope 1

WS-BPEL Process Flow Scope 2 Events, for event driven flow execution. Variables, in WSDL schema defined messages for internal or external purposes. Correlations, definitions of message parts which identify particularly process instance (session ID). Fault handling, defines what happen if an exception has been thrown. Event handling, defines what happen if an event occurs.

WS-BPEL Activities 1 Receive - do a blocking wait for a matching message to arrive. Reply - send a message in reply to a message which was sent by a. Invoke - invoke a one-way or request-response operation on a port type offered by a partner. Assign - update values in variables. Throw - generates a fault inside the business process. Wait - wait till a certain time has passed. Empty - insert a “no-op” instruction into a business process.

WS-BPEL Activities 2 Sequence - define a collection of activities to be performed sequentially. Switch - select a branch of activities from a set of choices. While - repeat an activity till a certain condition of success has been met. Pick - block and wait for a suitable message to arrive. Flow - specify one or more activities to be performed concurrently. Scope - define a nested activity with its own associated variables, fault handlers and compensation handlers. Compensate - invoke compensation in an inner scope i.e. from a fault handler or a compensation handler.

Disadvantages of WS-BPEL Static process composition. Process participants (partner‘s web services) must be defined and bound to the process flow at design time. BPEL standard is not about Semantic Web services: –Partner discovery and bounding at run time not possible. –Message mediation not possible.

BPEL Engine Implementations BPWS4J (Test engine from IBM Alphaworks) – ActiveBPEL (First Open Source BPEL engine) – Oracle BPEL Process manager – ml

Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

BPEL & WSMX Integration of WS-BPEL and WSMX. Static defined process flow provided by BPEL. Known services are invoked statically as described in the BPEL process flow. Dynamic services will be discovered and invoked through invocation of WSMX engine by BPEL process flow.

Dynamic Service Invocation BPEL static process invokes WSMX using its web service interface. Input message sent from BPEL has a goal and input parameters. WSMX finds suitable services based on an Input goal and handles with message mediation between BPEL message format and message format of a chosen web service.

Extending WSMX To implement our use case is needed an extension of current WSMX service discovery mechanism. In our use case a capabilities of a web services can not be described static, they can differ (ADSL line providers supports some telephone numbers, set of supported ones differs and can not be coded directly as a service capabilities).

Current shortcomings in WSMX Assumption that providers are able to completely describe their Web Services in WSMX Capabilities Repositories at design time (static description) – providers need a mechanism to defer specification of their capabilities during runtime, Limited operational behavior – WSMX does not support complex goals consisting of several subgoals. Further step: WSMX understanding some process modeling language.

Conditional WS Implementation Providers cannot store a range of number they can provide a ASDL line for in WS Capability since it is changing very frequently, Before ASDL line is purchased, its availability has to be checked for requested landline number, Assumption: There is list of Conditional WS, which must be executed before selected Web Service can be executed itself – in future this should be specified within logic expressions or in process modeling language.

Conditional WS Implementation Based on matching of logical goals with WS capabilities. Goals and capabilities have postconditions and effects. Capabilities additionally have preconditions and assumptions. WSMX adds concept of conditional web service to capability. Conditional WS1 Conditional WS2 WSMX Matchmaker Possible Matches Goal Collection of WS Step 2 Step 3 Step 1 Step 4 Match requester

Conditional WS Implementation Each of the Conditions creates a new Event in the system, all new Events return typed Values, which can be processed by initializing component, If all return results from intermediate Web Services indicate successful result, then WS conditions are fulfilled and execution of given WS can be performed, New component called Correlation Manager maintains the relationships between main event and conditional events; Correlation Manager puts main event into sleep and once all the conditional events are in state consumed, it wakes the main event up.

Conditional WS Implementation Implementation started – not finished yet

Business Process Engine in WSMX Process execution engine is able to understand the given specification of the ordering process and manages the runtime execution of this process, No decision has yet been made on a formalism for specifying complex goals. Solutions that are considered include YAWL or WS-BPEL, Two approaches to Complex Goal: Conditional WS within logic expressions or Conditional WS specified in modeling language,

Introduction Use case: Ordering Broadband Internet WSMX Overview WS-BPEL Overview Extending WSMX Conclusion and Future Work

Conclusion We have shown how to integrate the WS-BPEL with WSMX to provide supporting for dynamic real integration use case. The general assumption of WSMX that providers should completely describe the functionality of their services at design time is unreasonable.

Known Problems Security. Transaction Management. Performances. Using of WS-BPEL can be seen as temporary solution, the WSMX should have service composition capabilities.

Future Work Realization of the presented use case. Extending of WSMX functionality: –Extend the logical language to include a built-in function that evaluates during run time to a web service call. –Include the process modelling component in WSMX that is able to execute complex goals.

The End