1.  Copyright 2005 Digital Enterprise Research Institute. All rights reserved. www.deri.org Exposing SWS principles in SOAs to solve EAI scenarios Armin Haller

2. 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. 3 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. 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. 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. 6 What’s missing in current SOA? 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. Figure 1: SOA (Source: http://www.seebeyond.com)

7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17 How intra EAI is affected by the limitations of current SWS frameworks Agreement on ontologizing certain business 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. 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. 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. 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