Download ppt - WSMO

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
Events
Variables
Event Handling
Scope
Correlations
Fault handling
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 <receive>.
• 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)
– http://www.alphaworks.ibm.com/tech/bpws4j
• ActiveBPEL (First Open Source BPEL engine)
– http://www.activebpel.org/
• Oracle BPEL Process manager
– http://www.oracle.com/technology/products/ias/bpel/index.ht
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.
Step 1
Goal
WSMX Matchmaker
Step 2
Possible
Matches
Match
requester
Collection of WS
Step 4
Step 3
Conditional
WS1
Conditional
WS2
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
Send result when finished
Event Main
Parent reference =
NULL
Create
Sub-event
Event Cond 1
Parent reference =
Event Main
Status = SLEEP
Status =
MEDIATION
Type
Type
Condition reference list
Create
Sub-event
Send result when finished
Condition reference list =
NULL
Event Cond 2
Parent reference =
Event Main
Status =
MEDIATION
Type
Condition reference list =
NULL
• 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