Exposing SWS principles in SOAs to solve EAI scenarios

1. Exposing SWS principles in SOAs to solve EAI scenarios Armin Haller

2. Content • Current and resent past research focus • Idea and motivation for the talk • What was the motivation for the paper • What’s missing in current SOA? • What is the contribution? • Semantically enriched SOA • Traditional SOA in EAI scenarios • How semantically enabled SOA encounters limitations of traditional SOA integration solutions • How inter EAI is affected by the limitations of current SWS frameworks • Conclusion • Future research

3. Current and recent past research focus • Current and recent past research focus • m3pe Project • Flexible Interoperable Workflows using RDF • Aspects in Workflow Management • Survey of Workflow Management Products and Standards • Choreography in WSMX • Development of initial component • Publication Efforts • WSMX - A Semantic Service-Oriented Architecture • Exposing SWS principles in SOAs to solve EAI scenarios

4. Idea and motivation for the talk • Current and recent past research focus • m3pe Project • Flexible Interoperable Workflows using RDF • Aspects in Workflow Management • Survey of Workflow Management Products and Standards • Choreography in WSMX • Development of initial component • Publication Efforts • WSMX - A Semantic Service-Oriented Architecture • Exposing SWS principles in SOAs to solve EAI scenarios

5. What was the motivation for the paper • Initially submitted to the WSMO implementation workshop • rejected because of the business focus (no implementation) • Main contribution of original paper: • extend SOA with Semantics • show why dynamic discovery in inter-EAI is feasible • Planned submission for ISTA2005 – (WWW workshop) • new contribution more technically oriented: • extend SOA with Semantics • apply SOA in EAI scenarios • show benefits/limitations of Semantics in inter-EAI • show benefits/limitations of Semantics in intra-EAI

6. What’s missing in current SOA? Figure 1: SOA (Source: http://www.seebeyond.com) • SOA integration products are broadening their application domain  applied in EAI scenarios • What is SOA • a set of independently running services • communicating in a loosely coupled manner • via event-driven messages.

7. What’s missing in current SOA? • SOA came along long before Web Services • Web Services as paradigm in SOA claim to offer: • Interface has to be universally available (SOAP) • the interface has to be platform-independent (WSDL) • dynamic discovery and execution • Dynamic Discovery is not possible • Only String based search • And Taxonomy Browsing

8. What is the contribution? • Semantically enriched SOA • takes the W3C WSA as starting point • compliant to the Conceptual Semantic Web Service architecture of Preist • Uses WSMF/WSMO as underlying framework • Contribution of paper is not YASWSA, but to show how one such kind of architecture performs in the EAI domain

9. Semantically enriched SOA • redefine the three main concepts of the SOA: • Service provider can still use WSDL as a universally accepted interface language, but additionally they have to provide a WSMO compliant service description • Service description has to be stored in a repository, either a centralized one or a local distributed one • Service requestor can be any agent, expresses its requirements as a WSMO goal

10. Semantically enriched SOA • Adopted lifecycle model to understand the interactions within a SOA: • Matchmaking: determines whether the capability of a Web Service description can satisfy the given goal • Handling partial matches: No perfect match in reality. • Web Service might be usable for solving a goal when the valid set of outputs are restricted. etc. • Filtering results: ultimately choose one by applying filter mechanism • Contract agreement Phase: agents enter into negotiation with each other, to see if they can agree mutually acceptable terms of business • Contract Formation: Agreement is transformed into a legally binding contract • Service Delivery: The agents carry out the agreed transaction

11. Traditional SOA in EAI scenarios SOA EAI functionality  three distinctive layers: • Process Layer • Business Process Modeling • Enactment Support (BPM-Engine) • current SOA EAI: proprietary BPM languages, BPEL etc. Drawback: No common standard, reuse of models, dynamic binding not possible • Transformation Layer • routing and transformation of the respective messages • current SOA EAI: Transformation maps are used to convert the content and structure of XML schema (standard is XSLT) Drawback: one mapping between every XML schema • Transportation layer • provides the system- and platform-independent communication • common protocol layer and adapters • current SOA EAI: SOAP Protocol Binding Framework.

12. How semantically enabled SOA encounters limitations of traditional SOA integration solutions • Process layer: • Orchestration: • flexible de-coupling different workflows (Dynamic binding to avoid different combinations in design time • Scalable mechanisms to interweave different workflows • dynamic binding of activities in workflow types • Choreography: • behavior heterogeneity can be automatically addressed since business processes are formally modeled (process/behavior mediation) • Transformation Layer: • Transformation is still necessary, although formal description • Semantic transformation = mediation • Advantage that mapping rules are between ontologies and not schemas = ontologies are shared conceptualizations = reuse

13. How inter EAI is affected by the limitations of current SWS frameworks • Messages in B2B are sophisticated and several organizations tried to standardize common business documents like Purchase Order etc. • standards evolved to represent documents in DTDs or XML Schema (e.g. EDIINT, RosettaNet, OAGIS, cbXML etc.) • although SSOA apply ontology mediation, without standardised business ontologies  matching not possible Drawback: Standards have to be agreed on, proposals are made (Ontologizing EDI)

14. How inter EAI is affected by the limitations of current SWS frameworks • Filtering Result is sophisticated and can take different forms to result in an agreed service: • Partner selection • One or both parties have a choice about which partner to select • Either requester or provider choice of several partners to choose from • Service Selection • One party select and specify certain parameters of a service which weren’t specified during discovery  Requestor making their requirements more specific • Negotiation • In several B2B scenarios the price is subject to negotiation Drawback: not elaborated in frameworks so far. Ontologies have to be proposed for expressing SLA, business rules, business goals etc. in non-functional properties. Filtering algorithm for this selection process

15. How inter EAI is affected by the limitations of current SWS frameworks Negotiation stage is difficult • Contract agreement choreography  result in the agreement of a service contract • Proposals for negotiation protocols exist e.g. • Constraint relaxation – Parties exchange a set of constraints on a contract template. Agreement occurs when union of the two sets is satisfiable. Parties iteratively relax their set until match • Reverse Auction – Requestor sends out a call for quotes to fulfill a given service contract; providers respond with cheapest quote, and iteratively place lower offers until last bid is reached. Drawback: So far non of these proposals are included in the SWS frameworks.

16. How inter EAI is affected by the limitations of current SWS frameworks • Fundamental requirements around security and reliability • Web service security standards provide mechanism for end-to-end security • standards for reliability (WS-reliability) include information such as a message ID and sequence number to ensure reliability • WS-Security defines e.g. how to attach security tokens within SOAP messages • Security token either directly known/trusted by Service provider Drawback: assumes the awareness of the service provider beforehand • Requester or provider obtain the security token from a third party token store service Drawback: demands e.g. requester to obtain the security token before invocation • Information what constraints provider pose on Security and Reliability is included in the WS-Policy specification Drawback: SWS frameworks do not represent such policy assertions as logical conditions so far  Can not be considered in the Matchmaking/Filtering phase

17. How intra EAI is affected by the limitations of current SWS frameworks • Agreement on ontologizing certainbusiness documents can be achieved within an entity without Standards • at least same common ontologies • Filtering Result within sub units: • Partner selection • limited set of Partner sub units (known beforehand), selection criteria can be defined • Service Selection • Redundant services within companies not as common than in B2B • Selection preferences are mostly on abstract service description (level of match) • Negotiation • No price negotiation (price is at break even point between sub units for cost accounting)

18. How intra EAI is affected by the limitations of current SWS frameworks • Traditional Security mechanism can be applied • No need for end-to-end security • Use of VPN between sub units • reliability can be defined in intra-organizational policies

19. Conclusion • SWS framework enable dynamic discovery in SOA • (semi)-automated invocation in inter-EAI still future vision, following problems: • Ontologizing Business documents (Standards) • Ontologies for expressing SLA, business rules, business goals, Filtering algorithm for selection process • Negotiation protocols • no policy assertions as logical conditions (security, reliability etc.) • (semi)-automated invocation in intra-EAI is possible under certain assumptions

20. Future Research • m3pe Project • Survey of Workflow Management Products and Standards • Choreography in WSMX • Integrate Process mediation in the component • PhD Thesis, defining the Hypothesis Thanks for Listening