Demonstrating wsmx least cost supply management
1 / 40

Demonstrating WSMX: Least Cost Supply Management - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Demonstrating WSMX: Least Cost Supply Management' - lea

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Demonstrating wsmx least cost supply management l.jpg

Demonstrating WSMX:Least Cost Supply Management

Table of contents l.jpg
Table of Contents

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Introduction l.jpg

  • Web services.

  • Semantic web.

  • Semantic Web services.

Slide4 l.jpg

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Motivation l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg
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 wholesalerinvokes WSMX engine sending him goal description and other needed information in form of a SOAP message.

Slide11 l.jpg

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Introduction12 l.jpg

  • 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 discovery mechanism l.jpg
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.

Implementation l.jpg

  • 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.

Slide17 l.jpg

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Ws bpel standard l.jpg
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 l.jpg
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 2 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
BPEL Engine Implementations

  • BPWS4J (Test engine from IBM Alphaworks)


  • ActiveBPEL (First Open Source BPEL engine)


  • Oracle BPEL Process manager


Slide26 l.jpg

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Bpel wsmx l.jpg

  • 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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 implementation32 l.jpg
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.

WSMX Matchmaker

Step 1

Step 2

Match requester


Possible Matches

Collection of WS

Step 4

Step 3



Conditional ws implementation33 l.jpg
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 implementation34 l.jpg
Conditional WS Implementation

  • Implementation started – not finished yet

Business process engine in wsmx l.jpg
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,

Slide36 l.jpg

  • Introduction

  • Use case: Ordering Broadband Internet

  • WSMX Overview

  • WS-BPELOverview

  • Extending WSMX

  • Conclusion and Future Work

Conclusion l.jpg

  • 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 l.jpg
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 l.jpg
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.