Copyright 2005 Digital Enterprise Research Institute. All rights reserved.

www.deri.org

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?

• 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

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 providerDrawback: assumes the awareness of the service provider beforehand• Requester or provider obtain the security token from a third party token store serviceDrawback: 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 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

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