swws - semantic web enabled web services · 3.3.2 message filter pattern 23 3.3.3 enricher 24 3.3.4...

Title: Interaction and Integration Patterns

Version: 1.3

Date: 31.03.2004 Pages: 37

Authors: Juan Miguel Gomez- IFI Holger Lausen – IFI Steve Battle – HPLB

Co-Author(s): Liam Caffrey – NUIG

Status: Confidentiality:

[ [ [ [

X

] ] ] ]

Draft To be reviewed Proposal Final / Released to CEC

[ [ [

X

] ] ]

Public INT Restricted

- for public use - for SWWS consortium (and Project Officer if requested) - for SWWS consortium and Project Officer only

Project ID: IST-2002-37134 Deliverable ID: D2.2 Workpackage No: WP2 Title: Interaction and Integration Patterns

Summary / Contents: In this report we will analyze and describe different Integration and Interaction Patterns and consequently apply them to a typical Business to Business Use Case to illustrate their applicability as complete set. We structure the patterns in three different segments. Fist, analyzing interaction patterns of a conversation focusing on one party (Input Output Patterns), second, completing this picture by also taking the second party of a conversation (and the possible combinations of Input Output Patterns) into account. Complementary to these patterns, thirdly we describe data mediation patterns that are necessary to translate the contents of heterogeneous messages.

By describing these patterns we provide a unified vocabulary to model business interactions. Furthermore these patterns can ensure that heterogeneous parties are able to successful conduct business, presuming each of them is exactly following predefined patterns.

SWWS - Semantic Web Enabled Web Services

Interaction and Integration Patterns

Deliverable ID: 2.2

Page: 2 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

SWWS Consortium This document is part of a research project funded by the IST Programme of the Commission of the European Communities as project number IST-2002-37134. The partners in this project are: Leopold-Franzens Universität Innsbruck (IFI, Austria)); National University of Ireland, Galway (NUI, Galway, Ireland); Forschungszentrum Informatik (FZI, Germany); Intelligent Software Components S.A. (iSOCO, Spain); OntoText Lab. - Sirma AI Ltd. (SAI, Bulgaria); Hewlett Packard (HP, UK), British Telecom (BT, UK)

Leopold-Franzens Universität Innsbruck (IFI)

Institut für Informatik Technikerstrasse 13 A-6020 Innsbruck Austria

Tel: +43 512 507 6489 Fax: +43 512 507 9872

Contact person: Holger Lausen E-mail: [email protected]

National University of Ireland, Galway (NUI)

National University of Ireland, University Road Galway, Ireland

Tel: +353 91 512603 Fax: +353 91 512541

Contact person: Juan Miguel Gomez E-mail: [email protected]

FZI – Forschungszentrum Informatik

Haid-und-Neu-Str. 10-14 76131 Karlsruhe, Germany

Tel: +49 721 9654816 Fax: +49 721 9654817 Contact person: Stephan Grimm E-mail: [email protected]

Intelligent Software Components S.A. (iSOCO)

Francisco Delgado 11, 2nd Flor 28108 Alcobendas, Madrid, Spain

Tel: +34 913 349797 Fax: +34 913 349799

Contact person: Richard Benjamins E-mail: [email protected]

OntoText Lab.- Sirma AI Ltd. (SAI)

OntoText Lab.

38A Chr. Botev Blvd. Sofia 1000, Bulgaria

Tel: +35 92 9768 303, Fax: +35 92 9768 311

Contact person: Atanas Kiryakov

E-mail: [email protected]

Hewlett Packard (HP)

HP European Laboratories Filton Road, Stoke Gifford BS34 8QZ Bristol, UK

Tel: +44 117 3128631 Fax: +44 117 3129285

Contact person: Janet Bruten E-mail: [email protected]

Associated Partner:

British Telecommunications plc. (BT)

Orion 5/12, Adastral Park Ipswich ip5 3RE, UK

Tel: +44 1473 609583 Fax: +44 1473 609832

Contact person: John Davies E-mail: [email protected]


Deliverable ID: 2.2

Page: 3 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Table of Contents 1 Introduction 5 2 Classification of Interaction and Integration Patterns 6

2.1 Input Output Patterns (IOP) 6 2.2 Message Exchange Patterns (MEP) 7 2.3 Data Mediation Patterns 8

3 Interaction and Integration Patterns 9 3.1 Input Output Patterns 9

3.1.1 In-Only Pattern 10 3.1.2 Robust In-Only Pattern 10 3.1.3 In-Out Pattern 11 3.1.4 In-Multi-Out Pattern 12 3.1.5 Out-Only Pattern 12 3.1.6 Robust Out-Only Pattern 13 3.1.7 Out-In Pattern 14 3.1.8 Out-Multi-In Pattern 14 3.1.9 Summary 15

3.2 Message Exchange Patterns 17 3.2.1 MEPs for the In-Only Pattern 18 3.2.2 MEPs for the Robust In-Only Pattern 18 3.2.3 MEPs for the In-Out Pattern 19 3.2.4 MEPs for the In-Multi-Out Pattern 19 3.2.5 Summary 20

3.3 Data Mediation Patterns 20 3.3.1 Normalizer 22 3.3.2 Message Filter Pattern 23 3.3.3 Enricher 24 3.3.4 Summary 24

4 A Simple B2B Example 26 4.1 Storyboard of the Example 27 4.2 Input Output Patterns of the Example 28

4.2.1 IOPs of Customer Node 28 4.2.2 IOPs of the Supplier Node 29 4.2.3 IOPs of the Warehous 30

4.3 Message Exchange Pattern of the Example 30 4.4 Data Mediation Patterns of the Example 31

5 Related Work 33 6 Conclusions 36 7 References 37


Deliverable ID: 2.2

Page: 4 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

List of Figures Figure 1: Conceptual Model for Data Mediation [López et al., 2003]....................... 20

Figure 2: Sketch of a Normalizer............................................................................. 22

Figure 3: Sketch of a Message Filter Pattern .......................................................... 23

Figure 4: Sketch of a Data Enricher ........................................................................ 24

Figure 5: Concrete Scenario Description (UML-like Collaboration diagram) ........... 26

Figure 6: Conversation illustrating interaction patterns for the B2B scenario .......... 27

Figure 7: conversation state-machine ..................................................................... 34

List of Tables Table 1: Overview of Input and Output patterns 15

Table 2: Message Exchange Pattern Matrix 17

List of Acronyms and Abbreviations Acronym/ abbreviation

Resolution

AKA Also Known As IOP Input Output Pattern MEP Message Exchange Pattern RFQ Request for Quotes SWWS Semantic Web Enabled Web Services UML Unified Modeling Language WSCL Web Services Conversation Language WSDL Web Service Description Language WSMO Web Service Modelling Ontology XML Extensible Markup Language XSLT eXtensible Stylesheet Language Transformation


Deliverable ID: 2.2

Page: 5 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

1 Introduction The complex task of integrating heterogeneous software components can be achieved by means of web services. They provide standard protocols for discovering, invoking, describing and composing services. Current web service technology has a very basic and non-automated interaction model. Composition of simple services in more complex ones represents a natural evolution of the technology. Mainly in e-Business scenarios, not only the definition of a more complex interaction model has gained importance, but also the need for integration. Nowadays, data and process integration has become a major issue in industry. This includes the handling of different data models and heterogeneous data sources as well as the comparison and alignment of different process specifications. Both integration and interaction models can be described by means of patterns.

In this report we will analyze and compare the main interaction and integration patterns. According to [Hohpe & Woolf, 2003] a pattern can be described as “a proven solution to a problem in a context". Another definition is given by the architect Christopher Alexander [Alexander, 1979]: the term pattern can be defined as follows: “Each pattern is a three-part rule, which express a relation between a certain context, a problem, and a solution. As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context and a certain spatial configuration which allows these forces to resolve themselves.”

Summarizing, a pattern is an abstract element which provides two main features:

• Reusability: Patterns are about communicating problems and solutions. They enable us to document a known recurring problem and its solution in a particular context. This solution can be reused to solve other problems.

• Shared terminology and understanding: Patterns build a common vocabulary and understanding of a given problem. Patterns help create a shared language for communicating insight and experience about these problems and their solutions; also by referring to a well defined pattern in the context of a given problem all participants share a common understanding.

This report is structured as follows. In section 2, we present a general introduction about integration and interaction patterns. Section 3 outlines the patterns and gives a precise and clear explanation. In subsequent section 4, patterns are used in the context of a typical business to business use case, leading finally to section 5, where future and related work is discussed.


Deliverable ID: 2.2

Page: 6 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

2 Classification of Interaction and Integration Patterns Web Service architecture describes a system of related technologies that exchange messages between senders and receivers. The architecture formalizes the exchange of messages into "patterns" such as one-way or request/response.

These basic patterns can be combined to more complex patterns that build up a whole conversation, for example a bid process can be modeled as a number of incoming messages (representing the single bids), followed by a single out message signaling one of the buyers the acceptance of a bid. Describing these patterns and the specific combinations of those will enable reusability and a common understanding between the parties involved. In that way patterns form a contract between provider and requester enabling their communication.

To describe those patterns we will use a simplified version of the scheme proposed in [Hohpe & Woolf, 2003]:

§ Name of the Pattern

§ Short Description / Sketch, one or two sentences possibly accompanied by a diagram to grasp the essence of the pattern

§ Description The actual description of the pattern.

§ Example A simplified example illustrating the pattern.

§ See Also / Also Know As References to patterns that solve similar problems and to patterns that help to refine the current pattern.

First, we focus on patterns describing one participant of the conversation called In- Out Patterns (IOP), in Section 2.1. Subsequently section 2.2 describes how these patterns can form a conversation, taking both participants – sender and receiver – into account. The Patterns in Section 2.3 extend these in the sense that they are concerned about the actual content transferred and how possible mismatches can be resolved.

2.1 Input Output Patterns (IOP) An Input Output Pattern IOP is a sequence of messages related to a single Web Service S, forth on we will use the term node to indicate a Web Service, following the terminology proposed in [Gudgin et al., 2003]. Each message is a combination of one or more of the following elements:

§ an "input" message that is received by S;

§ an "output" message that is sent by S;


Deliverable ID: 2.2

Page: 7 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

§ a fault handling mechanism as described below.

The IOP specifies the sequence and the number of messages including their direction as either a specific number or a variable.

The IOPs only models one Web Service explicitly. There are no explicit assumptions made for the corresponding Node (Receiver/Sender). It is just assumed that for any message that is sent by one node, there exists another node being able to consume it. This relation is more detailed captured by Message Exchange Patterns.

Each pattern will have a specific fault generation rule associated with it. The generation of a fault always terminates the message exchange. There are three types of fault rules:

Fault Replaces Message

Any message except the first one in a pattern may be replaced with a fault message, which must have identical cardinality and direction. The fault message must be delivered to the same target node as the message that it replaces.

Message Triggers Fault

Any message, including the first, may trigger a fault message in response. Each recipient may generate fault message and must generate no more than one fault for each triggering message. Each fault message has the reverse direction of its triggering message. The fault message must be delivered to the originator of the message which triggered the fault. If there is no path to this node, the fault must be discarded.

No Faults

No faults may be generated. This fault rule is introduced primarily for clarification, i.e. to describe the In- and Out-only patterns, that don’t allow Triggering faults and since only a single message is concerned the Fault Replaces Message rule is also not applicable.

2.2 Message Exchange Patterns (MEP) A message exchange pattern (MEP) describes both nodes involved in a conversation and introduce the notion of compatibility. This distinction follows also the discussion in [Both & Lewis, 2003], which in essence describe that IOPs make no explicit assumption about the second node of a conversation, whereas MEPs do.

Generally a Message Exchange Pattern can be described as a template for the exchange of messages between nodes [Haas & Brown, 2003]. More precisely a Message Exchange Pattern (MEP) is the combination of two IOPs such that sender and receiver of every message are exactly defined.


Deliverable ID: 2.2

Page: 8 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

An MEP may also specify if a particular message is sent with or without conversation of messages. A conversation is defined here as a specific exchange of messages.

In general the definition of a message exchange pattern:

• Describes the life cycle of a message exchange conforming to the pattern.

• Describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern.

• Describes the normal and abnormal termination of a message exchange conforming to the pattern.

• Describes the Input and Output Patterns of both nodes participating in an interaction.

Concrete Message exchange patterns will be described in Section 3.2.

2.3 Data Mediation Patterns Data mediation patterns are an extension to the above mentioned. In a heterogeneous environment like the web different entities use different data formats and have to solve the possible mismatches. The key to efficiently managing data is to establish a common understanding. This is the idea of semantics, bridging nomenclature and terminological inconsistencies to comprehend underlying business meaning in a unified manner. Semantics can be achieved by formally capturing the meaning of data. This is accomplished by relating physical data schemas to concepts.

Data mediation patterns are used in the context of interactions and integration for sharing and reusing this capture of semantics. Data mediation patterns allows to change the syntactic representation of different data formats, transformation one into the other during the execution of integration. They will be explained more in detail in Section 3.3.


Deliverable ID: 2.2

Page: 9 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

3 Interaction and Integration Patterns In this section we analyze first different realization of the Input Output Patterns (IOPs), i.e. the WSDL version 2.0 patterns [Chinnici et al., 2003]. Then, we explain how Message Exchange Patterns (MEP) can be build in terms of IOPs by means of a complementarities matrix.

Note that the WSDL specification itself calls the Input Output Pattern Message Exchange Pattern, however they do not make any assumption about the second node (except their existence). Consequently they do not distinguish between IOPs and MEPs within their current specification, however [Both & Lewis, 2003] reflects the approach we have taken here. In our opinion it is important to make this distinction and also to explicitly analyze MEPs, this also helps in evaluating the applicability of the IOPs.

With respect to [Chinnici et al., 2003] we omitted the Asynchronous-Out-In, since this can be modeled by two separate IOPs and in the following we concentrate at the basic patterns.

3.1 Input Output Patterns Once we have outlined the different kinds of patterns, we now study the concrete realization of IOP patterns in the current web services technologies, namely in the Web Services Description Language (WSDL) version 2.0. We consider WSDL patterns to be described in terms of the WSDL component model i.e. a conceptual model for WSDL as a set of components with properties [Chinnici et al., 2003].

WSDL describes a Web service in two fundamental stages: one abstract and one concrete. Within each stage, the description uses a number of constructs to promote reusability of the description and separate independent design concerns.

At an abstract level, WSDL describes a Web service in terms of the messages it sends and receives; messages are described independently of a specific wire format using a type system, typically XML Schema.

An operation associates a message exchange pattern with one or more messages. A message exchange pattern identifies the sequence and cardinality of messages sent and/or received as well as whom they are logically sent to and/or received from. An interface groups together operations without any commitment to transport or wire format.

At a concrete level, a binding specifies transport and wire format details for one or more interfaces. An endpoint associates a network address with a binding. And finally, a service groups together endpoints that implement a common interface.


Deliverable ID: 2.2

Page: 10 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

These patterns are assumed to be synchronous unless otherwise stated. An interaction is said to be synchronous when the participating agents must be available to receive and process the associated messages from the time the interaction is initiated until all messages are actually received or some failure condition is determined. The exact meaning of "available to receive the message" depends on the characteristics of the participating agents (including the transfer protocol it uses); it may, but does not necessarily, imply tight time synchronization, blocking a thread, etc.

An interaction is said to be asynchronous when the associated messages are chronologically and procedurally decoupled. For example, in a request-response interaction, the client agent can process the response at some indeterminate point in the future when its existence is discovered. Mechanisms to do this include polling, notification by receipt of another message, etc.

Given that we are only regarding one the interacting entities of the conversation, this WSDL patterns [Chinnici et al., 2003] match with the Input Output Patterns (IOP) described in Section 2.1. Those patterns are enumerated in the following. Then we summarize them in a comparison table driven by cardinality, fault message and direction of messages criteria.

3.1.1 In-Only Pattern

Name: In-Only

AKA: One way

Short Description: An endpoint or node receives a message

Description: This pattern consists of exactly one message as follows:

A message:

o with the direction 'in'

o received from some node N

This pattern uses the No Faults rule, which means no fault message will be generated.

Example: The receipt of any kind of Notification (e.g. a shipment notice of a retailer that an ordered product left its premises); or a Receipt of a Request for Quotation (that is not directly followed by an offer)

3.1.2 Robust In-Only Pattern


Deliverable ID: 2.2

Page: 11 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Name: Robust In-Only

AKA: One way

Short Description: An endpoint or node receives a message and handles any fault.


A message:



This pattern uses the rule Message Triggers Fault which means that any message may trigger a fault message in response. Each recipient may generate a fault message and must generate no more than one fault for each triggering message. Each fault message has the reverse direction of its triggering message. The fault message must be delivered to the originator of the message which triggered it. If there is no path to this node then the fault must be discarded.

Example: Same as for In-Only, but with difference that it handles faults, i.e. the sender of the message can assume that the message will be processed in case it is received or he will be indicated by a fault message otherwise.

3.1.3 In-Out Pattern

Name: In-Out

AKA: Request-Response

Short Description: An endpoint or node receives a message and then sends a message handling any fault.

Description: This pattern consists of exactly two messages, in order, as follows:

1. A message:



2. A message:

o with the direction 'out'


Deliverable ID: 2.2

Page: 12 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

o sent to node N

This pattern uses the rule Fault Replaces Message which means that the fault may replace the message with a fault message which must have an identical cardinality, direction and be delivered to the same target node as the message it replaces.

Example: The receipt of any kind of Notification (e.g. a shipment notice of a retailer that an ordered product left its premises); or a Receipt of a Request for Quotation (that is not directly followed by an offer)

3.1.4 In-Multi-Out Pattern

Name: In-Multi Out

AKA: Multicasting

Short Description: An endpoint or node receives a message and sends zero, one, or more messages out handling any fault.

Description: This pattern consists of one or more messages, in order, as follows:

1. A message



2. Zero, one or more messages


o sent to node N


Example: A event message received which triggers a notification message to multiple parties.

3.1.5 Out-Only Pattern


Deliverable ID: 2.2

Page: 13 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Name: Out-Only

AKA: One way

Short Description: An endpoint or node sends one message out.


1. A message:


o sent to some node N

This pattern does not generate any faults.

Example: The sending of any kind of Notification (e.g. a shipment notice of a retailer that an ordered product left its premises); or the broadcast of a Request for Quotation (where the reply is not modeled within this pattern)

3.1.6 Robust Out-Only Pattern

Name: Robust Out-Only

AKA: One Way

Short Description: An endpoint or node sends one message out and handles any fault.


1. message:



This pattern uses the rule Message Triggers Fault which means that any message may trigger a fault message in response. Each recipient may generate a fault message and must generate no more than one fault for each triggering message. Each fault message has the reverse direction of its triggering message. The fault message must be delivered to the originator of the message which triggered it, If there is no path to this node then the fault must be discarded.

Example: The sending of any kind of Notification (e.g. a shipment notice of a retailer that an ordered product left its premises); or the


Deliverable ID: 2.2

Page: 14 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

broadcast of a Request for Quotation (where the reply is not modeled within this pattern).

3.1.7 Out-In Pattern

Name: Out-In

AKA: Solicit Response

Short Description: An endpoint or node sends one message out, receives one message in and handles any fault.

Description: This pattern consists of exactly two messages, in order, as follows:

1. A message:



2. A message:


o sent from node N


Example: An issue of a Purchase Order (PO) followed by a receipt of a Purchase Order Acknowledgement.

3.1.8 Out-Multi-In Pattern

Name: Out-Multi In

AKA: Multicasting

Short Description: An endpoint or node sends one message out, optionally receives zero, one or more message in and handles any fault.

Description: This pattern consists of one or more messages, in order, as follows:

1. A message:


Deliverable ID: 2.2

Page: 15 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL



2. Zero, 1 or more messages:


o sent from node N


Example: An issue of a Request for Tender followed by an optional receipt from interested parties.

3.1.9 Summary

Table 1 summarizes the above presented basic WSDL Message Patterns. There are eight patterns, each of them is characterized by messages in the direction ‘in’ or ‘out’ (with respect to the node using the pattern) along with their cardinality (zero, one or more) and the way faults are handled in the specific pattern. The matrix uses and “X” to indicate which of the above aspect applies to a pattern, The order in which the messages occur can be inferred by the name of the pattern, e.g. “In-Out” implies the incoming message before the outgoing one occurs.

applicable fault rule Cardinality of "In" messages

cardinality of "out" messages

no pattern name 0 1 >1 0 1 >1

No Faults Message Triggers Faults

Fault Replaces Message

1 In-Only X X 2 Robust In-Only X X 3 In Out X X X 4 In-Multi-Out X X X X X 5 Out-Only X X 6 Robust Out-Only X X 7 Out In X X X 8 Out-Multi-In X X X X X

To illustrate the intended interpretation of the table we briefly discuss the In-Multi-Out Pattern. Following the name the conversation starts with the direction “In”, the

Table 1: Overview of Input and Output patterns


Deliverable ID: 2.2

Page: 16 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

“X” indicates that it is a single message, the three “X” in the out column indicate that it is followed by zero one or more messages and the fault column defines that only the Fault Replaces Message rule is applicable to this pattern.

By now we presented enough to sufficiently describe a single node; however the presented patterns lack an exact description of the second node involved, which will be given in the following section.


Deliverable ID: 2.2

Page: 17 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

3.2 Message Exchange Patterns With Message Exchange Patterns (MEP) the analysis is starting to look at both sides of the interaction. If one node is described by an IOP and hence force has a particular behavior, we need to show a complementary behavior (IOP) of a second node in order to describe a whole conversation. Table 2 summarizes these possible combinations.

Node 2

In-Only Robust

In-Only In-Out In-

Multi-Out

Out-Only

Robust Out-Only

Out-In Out-Multi-In

In-Only X Y X1

Robust In-Only Y X Y1

In-Out X X1

In-Multi-Out X1 Y1 X1 X

Out-Only X Y X1

Robust Out-Only Y X Y1

Out-In X X1

No

de

1

Out-Multi-In X1 Y1 X1 X

Table 2: Message Exchange Pattern Matrix

Legend: X, the IOP combination is fully compatible.

Y, the IOP combination is compatible, however the fault triggers rule is only applied to one node and thus will be ignored in the MEP. 1, the combination is possible, however other combination are more suitable.

not applicable

omitted (since duplicated)

We can furthermore exclude those combinations where the direction of the initial message is identical, e.g. the first white cell which represents the combination of an In-Only and a Robust In-Only Pattern, which is obviously not compatible. The


Deliverable ID: 2.2

Page: 18 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

remaining intersections are framed with a thicker box, representing the possible matches.

The combination of patterns consisting of one and respectively two messages (i.e. the four empty boxes in Table 2) are not discussed here. The matrix depicts the combination of exactly two patterns, but in order to have a valid conversation in the described constellation at least three patterns would be required.

In the following we discuss four of the eight patterns, the MEPs for the other four can easily be inferred by inversing the directions of the conversation.

3.2.1 MEPs for the In-Only Pattern

The obvious optimal combination for an In-Only Pattern is the Out-Only Pattern, representing the exchange of a single message from Node 2 to Node 1. This combination is suitable for simple notifications; however no fault handling mechanism is applied.

The same holds for its combination with the Out-Multi-In pattern. In this scenario two nodes are able to exchange a message. The node described by the “Out-Multi-In” pattern will not receive any message and since only a single message is exchanged the Fault Replaces Message rule to handle errors is not applicable to the MEP as whole.

A Node described by an In-Only pattern can exchange a message with a node having a Robust In-Only pattern. The Fault Triggers Message rule states that a fault may be send and furthermore explicitly states that this message has to be discarded if there is no route back to the message originator. The latter applies in this case since the originator (In-Only) does not provide an endpoint to send a message back.

3.2.2 MEPs for the Robust In-Only Pattern

A Robust In-Only pattern is designed to fit to the Robust Out-Only pattern. The direction of the message at both nodes fit together and both comply to the same fault rule. This means that the node using the Robust Out-Only pattern has to provide an endpoint excepting a potential incoming fault message from the other node.

Following the argumentation in the 3rd paragraph of section 3.1.2 this pattern may also be combined with the Out-Only pattern, however as previously explained, the Fault Triggers Message rule is only applied at one node and thus will be ignored.

The third possible indicated combination in Table 2 is with the Out-Multi-In node. The fact that only one message will be exchanged is in line with the definition of the Out-Multi-In node, however both patterns use different fault rules: The Robust In-


Deliverable ID: 2.2

Page: 19 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Only node would potentially accept an error message, but the Out-Multi-In node with the Fault Replaces Message rule would only send a fault as the replacement of a message, since no regular message is expected to be send, no fault will be send and the MEP as whole will not be able to handle any faults.

3.2.3 MEPs for the In-Out Pattern

The In-Out pattern involves exactly two messages, which means the combination with the patterns involving only one message is not possible, as long as taking only the combination of exactly two IOPs into account.

The In-Out Pattern matches obviously with the Out-In Pattern. This is the currently widest used pattern combination, involving one incoming message and its answering message being transferred. In addition to that a fault message may be sent replacing the second message.

The combination with the Out-Multi-In Pattern follows exactly the same semantics. Again two messages get transmitted and both nodes agree on the Fault Replaces Message rule. The only difference is that the Out-Multi-In node allows more flexibility, i.e. the omission or the multiplication of the second message. When only the described transfer of two messages is desired, the pattern described in the second paragraph should be used.

3.2.4 MEPs for the In-Multi-Out Pattern

This pattern can potentially exchange messages with each of the four compatible candidates depicted in the thick box in Table 2. The most interesting case is its combination with the Out-Multiple-In pattern, which allows the exchange of a single initial message followed by zero one or more replies. Both nodes use the Fault Replaces Message rule and therefore share the same semantics not only for the cardinality of the messages but also with respect to the error handling.

Combining the In-Multi-Out pattern with Out-In pattern is also possible, the same fault rule are applied message directions and cardinalities are compatible, as discussed in the last paragraph of the previous section.

The Pattern can also be combined with the Out-Only pattern; however the message replace fault rule will be ignored in that case (for the reasons discussed previously). The same holds for the Robust Out-Only pattern where both fault rules, the message replaces and the message triggers rule will be ignored.


Deliverable ID: 2.2

Page: 20 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

3.2.5 Summary

We have discussed various ways of combining Input Output Patterns. The cardinality and direction of the messages determine if a message exchange is possible, we have identified 12 such combinations. However to use an Input Output Pattern in its desired sense also the fault rules must match in order to preserve the semantics these rules imply for each node, this applies to the eight combinations identified by an X in Table 2. Finally we have identified natural counterparts for each pattern (depicted by an X without a footnote).

In the next section we will discuss Data Mediation Patterns, which are not concerned about the sequencing of the message but their actual content.

3.3 Data Mediation Patterns As outlined in [López et al., 2003] data mediation is concerned about transforming the parameters in various communication primitives from conceptual models of either partners involved in a conversation. The underlying assumption is that both source and target data is described by an ontology schema. Furthermore it is assumed that mapping rules between both schemas exist, so that these can be applied to the instance data.

Source Ontology/Schema

Target Ontology/Schema

Semantic Correspondences

Source Instance Data

Target Instance Data

Mediation Service

Figure 1: Conceptual Model for Data Mediation [López et al., 2003]

Furthermore [López et al., 2003] discusses how to express these mappings and proposes to do this via queries, i.e. each element of one ontology is expressed as a query over another ontology. Then, it is possible to transform the data by applying


Deliverable ID: 2.2

Page: 21 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

these queries. In data information literature therefore two main approaches are identified: Global as View and Local as View. Both assume the existence of a global schema (the canonical model of all schemas that have to be mediated). The former expresses the global schema as a view on the local schemas (e.g. a particular source and target ontology), the latter expresses the local schemas in terms of the global schema.

The advantages and disadvantages of both approaches is well explored in the current literature, however in the context of web services and message exchanges there is an additional aspect to be mastered:

§ Mediation of single messages is different to the integration of databases, since messages usually only contain data representing a small subpart of the corresponding schema.

Thus it is not necessary to map the entire internal data structure, but the parts represented in the messages to be exchanged. As done before we assume that the interfaces are described in terms of WSDL, a set of operations with input, output and fault messages. These messages are described using XML schema data types.

Direct Mapping between 2 XML Schemas

A straight forward solution would be to directly map these messages, for example by means of XSLT. However this has the drawback that it does not scale with respect to the number of nodes that have to be linked up and secondly the XML schema does not reveal the inherited semantics of the messages, in contrast a ontology schema can express more, e.g. by inheritance or axioms.

Direct Mapping between 2 Ontology Schemas

As described in [Trastour et al., 2002] these can be lifted to an “ontological” level, so that additional constraints can be added to the message description. This has the advantage of making more of the semantics of each message explicit, rather then having them expressed in separate documentation (e.g. Excel sheets describing the content of optional Rosetta Net messages). But it leaves the problem that these schemas are directly representing the message format and does not use a shared schema that could improve the scalability with respect to the nodes to be linked up.

Expressing the Interface by Means of a Domain Ontology

This approach is similar to the local as view approach known from the field of data information. Here we assume one or more domain ontologies that can be referenced in order to express the interface. If both services use the same ontology the transformation of data can be done by exploring these mappings.


Deliverable ID: 2.2

Page: 22 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

From the point of scalability with respect to the number of different connections, clearly the last approach is the one which scales best. However the drawback is that an existing domain ontology is needed.

We have discussed various variants of transformation, however there is an additionally dimension that has to be taken into account: Does the content of a message remain the same, has it to be reduced or extended (respectively: Normalized, Filtered or Enriched)? This takes into account that we are talking about message transformation and not about the transformation of whole databases.

3.3.1 Normalizer

Problem

How can semantically identically but syntactically different message interfaces exchange messages.

Figure 2: Sketch of a Normalizer

Description

In many cases, conceptual identical messages are exchanged between web services with a different representation. Each one is usually built around a proprietary data model. Each Web Service (and application) may have a slightly different notion of the Customer entity, the attributes that define a Customer and which other entities a Customer is related to. As a result, the applications (and correspondingly the exposed interfaces) expect to receive messages that mimic of the application's internal data format.

In addition to the proprietary data models and data formats incorporated in the various applications there are also a number of standards that define specific structures, such as RosettaNet, ebXML, OAGIS and many other.

The Normalizer has to receive the incoming message and to recognize to which schema it belongs. Secondly it has to identify the target schema and third to execute the mapping rules defined between source and target.

Translator

Incomming Message Outgoing Message


Deliverable ID: 2.2

Page: 23 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Example

An ordering system may have to interface to a variety of customer purchase order interface. Each purchase order may be semantically identical but syntactically difference. The Normalizer will handle the differences and present each incoming purchase order in a consistent manner to the ordering system.

3.3.2 Message Filter Pattern

Sketch

How do you simplify dealing with a large message, when you are interested only in a few data items?

Figure 3: Sketch of a Message Filter Pattern

Description

This pattern is about identifying relevant parts of a message and dropping the irrelevant parts. A common reason to use this pattern is security. As such that for example an internal payroll system interface offers a complete set of employee data, but if it has to communicate with for example a travel agency for the processing of an expense claim it should only send parts of the employees data. This pattern can read the description of both interacting entities and simply drop the non required information. Another problem in this context can occur when exchanging data in an object oriented way, for example a Web Service requests an employee object, which contains a property “boss”, with itself is again of type employee. When sending the complete information in the worst case a whole employee database might be send, a filter pattern can decide on the context and the target node how many information shall be passed.

Example

An Agent may have a set of User Information for generally registering at Web Services, but particular Web Services only request a subset of this information. A Filter Pattern can be used in order to always send the right subset of this data.

Filter



Deliverable ID: 2.2

Page: 24 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

3.3.3 Enricher

Sketch

How to gather additional information in case a message does not contain all relevant information?

Figure 4: Sketch of a Data Enricher

Description

The Data Enricher is the opposite pattern to the Filter Pattern. It applies if the send of a message has less information then the receiver does request. It uses information inside the incoming message (e.g. key fields) to retrieve data from an external source. After the Data Enricher retrieves the required data from the resource, it appends the data to the message. Whether the original information from the incoming message has to be carried over into the resulting message depends on the circumstances.

Example

On the hand, we analyze a system which deals with business expenses that exposes a web service interface for delivering all due expense claims. On the other hand we have the bank payment interface. It could occur that expense claims only contain the employee identifier, but not their bank account information. In that case an Enricher pattern can be used to augment the expense claim data with payment information by querying the central employee database system.

3.3.4 Summary

Enricher


Resources


Deliverable ID: 2.2

Page: 25 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

In this section, different types of data mediation patterns were analyzed and described. In section 4, we will use these patterns in the context of a B2B scenario. We will also show how data mediation patterns are vital to make more simple and reliable the design of interactions.


Deliverable ID: 2.2

Page: 26 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

4 A Simple B2B Example In the following we will present a small B2B scenario along with the integration problems and show how the previous discussed patterns can be used to model this scenario.

In a simple B2B scenario, a customer sends a request for quotes (RFQ) to a supplier. The supplier answers with the quote to the customer. If the result is satisfactory enough for its business logic, the customer proceeds to order the goods. The supplier then verifies with its warehouse if it is possible to provide the goods to the customer by checking the availability of the goods. Subsequently, the customer order is confirmed and the payment is made. Once the payment has finished, the supplier forwards the order to the warehouse and the customer gets all the shipment details.

Finally, the customer confirms the delivery of the shipment. Once, the warehouse informs about this acknowledgement of delivery to the supplier, the business process is concluded.

The scenario is depicted in figure 5 as a UML-like collaboration diagram [Booch et al., 1998].

Figure 5: Concrete Scenario Description (UML-like Collaboration diagram)


Deliverable ID: 2.2

Page: 27 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

4.1 Storyboard of the Example The scenario is again shown in figure 6 by means of a UML sequence diagram [Booch et al., 1998], putting the emphasis on the sequence of the message exchange.

Figure 6: Conversation illustrating interaction patterns for the B2B scenario

The sequence in plain text is as follows:

1. Customer sends a RFQ message to the supplier.

2. Supplier replies with a quote.

3. Customers sends a message for ordering goods to the supplier.


Deliverable ID: 2.2

Page: 28 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

4. Supplier sends a message to the warehouse to check if the goods are available and the shipment is possible.

5. Warehouse sends a message indicating the availability of the goods to the supplier.

6. Supplier sends a message to the customer confirming his order.

7. Customer sends a message to the supplier paying the order

8. Supplier sends a message to the warehouse ordering the shipment

9. Warehouse sends a message to the customer informing about the delivery of the goods

10. Customer sends a message to the supplier confirming the delivery has happened

11. The warehouse sends a message to the supplier confirming the delivery was successful

4.2 Input Output Patterns of the Example In this section, we present how the different steps of the sequence are represented by means of the IOP patterns described in the document. Since the scope of an IOP is a single node, we will discuss the patterns for each three nodes separately:

4.2.1 IOPs of Customer Node

The First interaction at the customer side is described by an Out-Multi-In Pattern. This means the customer sends one request for quotation and is able to handle multiple different replies (e.g. a supplier might want to sent different offers in separate messages).

To conduct the ordering of goods the customer chooses to model this interaction by a Robust Out-Only, followed by a Robust In-Only pattern. Alternatively this also could have been an Out-In Pattern, however since it might take some considerable time until a potential supplier confirms an order, two single patterns ensure that the interaction is not consuming too many resources (e.g. long waiting processes) and also avoid communication errors caused through timeouts.

The Payment is done via an operation applying the Robust Out-Only pattern. The robustness in this case ensures that the message is understood by the supplier, or otherwise a fault message send by the supplier will indicate a problem.


Deliverable ID: 2.2

Page: 29 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Furthermore the supplier has two operations related to the actual shipment. First a Robust In-Only operation, which accepts information about the actual shipment details (e.g. the time of delivery). Second an operation (Robust Out-Only), which informs about the fact that a shipment has been received. The pattern itself does not require specifying a receiver; however this can be inferred from the previous corresponding sendShipmentDetail message.

Summary IOPs of Customer Node

Pattern Related Messages Out-Multi-In requestQuote, returnQuote Robust Out-Only orderGoods Robust In-Only confirmOrder Robust Out-Only makePayment Robust In-Only sendShipmentDetail Robust Out-Only confirmShipment

4.2.2 IOPs of the Supplier Node

The supplier offers to give quotes via an operation annotated with an In-Out Pattern. This implies he will always send exactly one quote for each request for quotes.

He accepts incoming orders via a Robust In operation, which means he agrees on reporting errors resulting from the incoming message. To check the availability of a particular order he has an Out-In interface; sending a message requesting the shipment availability of some goods, in which turn he expects a message containing the desired information.

An order confirmation is send out by a Robust Out-Only operation, meaning that he potentially expects a fault message in return. Vice versa for the payment, he expects an incoming message (Robust In-Only), potentially sending a triggered fault. The rationale for not choosing an Out-In pattern is again the potentially big delay between those messages.

The operations corresponding to orderShipment and and confirmShipment (Robust Out-Only respectively Robust In-Only finally enable the handling of the shipment on the supplier side.

Summary IOPs of Supplier Node

Pattern Related Messages In-Out requestQuote, returnQuote Robust In-Only orderGoods Out-In checkShipAvailable, confirmShipAvailable Robust Out-Only confirmOrder Robust In-Only makePayment Robust Out-Only orderShipment


Deliverable ID: 2.2

Page: 30 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Robust In-Only confirmShipment

4.2.3 IOPs of the Warehous

The warehouse offers to query the availability for shipment vie an Out-In Pattern, expecting an incoming message requesting the availability of certain goods and a return message stating their status.

It accepts orders via an In-Only message; this implies that it does not provide any fault handling mechanism (No Faults rule). This is particular interesting when later on analyzing the whole communication.

The warehouse has three further operations sendShipmentDetail (Out-Only), confirmShipment (In-Only) and confirmShipment (Out-Only). The line of argumentations follows the above given arguments.

Summary IOPs of Warehous Node

Pattern Related Messages In-Out checkShipAvailable, confirmShipAvailable In-Only orderShipment Out-Only sendShipmentDetail In-Only confirmShipment Out-Only confirmShipment

4.3 Message Exchange Pattern of the Example The first exchange of two messages (requestQuote and returnQuote) is as shown in Table 2 fully compatible. However in case the customer only communicates with the described supplier, the customer side should be better modelled with an Out-In pattern, to avoid ambiguity. However this flexibility might also be desired, since most likely the customer also communicates with other suppliers.

The order goods message is transmitted from the customer to the supplier using a Robust In-Only and a Robust Out-Only operation. By using the fault triggers rule both agree that a second (fault) message may be sent from the supplier to the customer, thus besides agreeing on the format of the order message both nodes also have to agree on the format of the possible error messages.

Messages four and five are transmitted using a combination of In-Out and Out-In patterns, which perfectly match, both nodes must agree on the format of the messages (or use a mediator cf. section 4.4). The pattern allows additionally an optional fault message, sent by the warehouse; however the interacting parties do not necessarily have to agree on those.


Deliverable ID: 2.2

Page: 31 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

The confirmOrder and makePayment message follow the same line of argumentation as the returnQuote Message.

The set of the remaining messages follows not fully compatible MEPs (indicated by a Y in Table 2). When combining a Robust Out-Only pattern with an In-Only pattern, effectively the robustness of the first pattern will be discarded. The IOPs don’t prohibit the combination, since they don’t make any assumptions about the other node. From the business perspective this means, that the supplier and customer always intend to have a robust communication, however in case a client does not support this robustness (e.g. the warehouse) it is still able to communicate. The corresponding MEPs (Y in Table 2) indicate this. But the node with the robustness must be aware that in case errors in the communication occur they have to be fixed outside of the scope of the described patterns.

4.4 Data Mediation Patterns of the Example As described above a set of messages is exchanged in this scenario. Besides the eleven messages depicted in Figure 6, additional fault messages may be defined and transmitted. In and ideal case all participants agree exactly on the format of a message, since this is unlikely especially in the case of growing number of participants, for each message exchange a data mediation pattern might be necessary to apply.

In the following we just give a brief outline on how this can be done. More exact instantiations of the patterns will be found in the case study documents of the SWWS project.

According to the use case the supplier receives an ordersGood message, this will contain besides the identifier also address information and other client specific information, however when the supplier sends the checkShipAvailable message to the warehouse this information are not relevant and for security reasons also not desired to be forwarded. Thus the supplier will facilitate a Filter Pattern, which only passes information through relevant for the warehouse to check the availability, such as good identifiers and quantities.

On the way back to the client the supplier has to enrich the confirmShipmentAvailable message with client specific information, such as the terms of delivery and the payment modalities. Here the used pattern is an Enricher as outlined in section 3.3.3.

The Normalizer may additionally be necessary to apply in order to resolve mismatches. This can be the renaming of fields (for example from good_id to good_no) or its values (for example converting a price in dollar to euros). Furthermore a Normalizer might be used to alter the structure of the message itself:


Deliverable ID: 2.2

Page: 32 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

An order received by the customer might be hierarchical classified with respect to a particular catalogue structure, but the warehouse expects a flat list of product descriptions.

We have seen that the proposed message patterns can entirely model the problems within this use case and by naming them accordingly they provide a unified vocabulary.


Deliverable ID: 2.2

Page: 33 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

5 Related Work In the context of SWWS, the need of modeling conversations as a set of interaction patterns is gaining momentum. A conversation can be described as “the set of acceptable message exchanges and the order in which they should occur” [Benatallah et al., 2003].

Some proposals like the Web Services Conversation Language [Banerji et al., 2002] deal with defining business payload in the public interface, typically using XML and XML schemas. Yet defining only which documents are expected by a web-service and which are returned in response, is not enough, it is also necessary to define the order in which these documents are exchanged. The notion of conversation in WSCL allows to specifying the order by diving them into interactions, transitions and, finally, conversations.

Also State machines [Booch et al., 1998] provide a simple and elegant way to convey the shape of a conversation. The example below describes a fictitious online store, based on the familiar model of a customer adding items to a virtual shopping cart. There are a number of things of interest about this model. The conversation doesn’t aim to be a complete model; it doesn’t describe the contents of the basket for one thing. The primary purpose of conversation modelling is to describe the sequencing of message exchange events. A stateful model of the basket would achieve little in rounding out the conversation. Many of the transitions denote the invocation of a basic web-service operation. However, this need not be universal; the order-shipped transition would typically be an email notification rather than an invocation.

The model is also intended to show the effect of operations in that we may label states with propositions [Huth & Ryan, 1999]. Following a ‘submit order’ it is true that the goods are ‘on order’. They remain that way until the order is either cancelled or shipped. Any number of propositions may be asserted in a state, and there is a closed-world assumption such that any proposition not asserted in a state is assumed to be false.


Deliverable ID: 2.2

Page: 34 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Figure 7: conversation state-machine

In this example, conversations describe the lifecycle of an interaction between two parties; the service provider and a service consumer. We see that the concept differs from that of a session; a conversation may span many sessions, or a session may span many conversations. The conversation above captures the idea that once an order has been submitted, it is no longer possible to add or remove items from the basket. The customer can wait for their item to be shipped, or they can cancel the order (this simplified scenario ignores the possibility of returns). If the customer wants to return to browsing, it says that they can only do this in the context of another conversation.

Finally, the notion of choreography and orchestration, as explained in the context of the Web Service Modelling Ontology (WSMO) [Roman et al., 2004] are the gist of the matter to model interactions between the different entities.


Deliverable ID: 2.2

Page: 35 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

Choreography [Roman et al., 2004] provides the necessary information for the user to communicate with the web service (i.e. it describes how the service works and how to access the service from the user's perspective). Choreography achieves this by instantiating a Message Exchange Pattern (MEP) for the given capability of a web service. A message exchange pattern specifies a sequence of conditional speech acts that either send or receive communication symbols (messages in our case). In between the communication ask, non-specified actions are defined. State-less MEPs model stimulus-response patterns (i.e. the behavioral point of view) and state-based MEPs model conversations (i.e. the modern cognitive science point of view).Choreography instantiates a generic communication pattern.

On the other hand, orchestration [Roman et al., 2004] describes how the service works from the provider's perspective i.e. how a service makes use of other web service or goals in order to achieve its capability. Orchestration can be either public or private i.e. its specification can be either publicly available or not. The decision of making the orchestration publicly available or not depends on the provider of the web service. An orchestration describes how the service works by instantiating a Problem Solving Pattern (PSP) for the given capability of a web service. A problem solving pattern specifies a sequence of conditional activities. Again, a description can be state-less or state-based. Orchestration also uses patterns by instantiating a generic cooperation pattern.


Deliverable ID: 2.2

Page: 36 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

6 Conclusions As outlined in Section 4 patterns make the modeling of a particular use case easier. Different set of patterns can be chosen to represent and model interactions depending on the features which are needed. By using these patterns, it is easy to identify reoccurring problems as well as using a unified vocabulary.

In addition the pattern used for the modeling of the conversation represents also a contract between the interacting parties, ensuring their communication in case both comply with the pattern.

Fundamentally, patterns provide a very useful approach when designing interactions for two main reasons:

• Reusability and modularization: the interactions can be identified as a set of coarse-grained exchanges and the granularity can be easily modeled by using more simple or complex patterns

• Understanding: the problem gets more understandable when using solutions which can be applied in similar contexts.


Deliverable ID: 2.2

Page: 37 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

7 References [Alexander, 1979] C. Alexander: The Timeless Way of Building, Oxford University Press, 1979.

[Banerji et al., 2002] A. Banerji, C. Bartolini, D. Beringer, V. Chopella, K. Govindarajan, A. Karp, H. Kuno, M. Lemon, G. Pogossiants, S. Sharma, S. Williams: Web Services Conversation Language (WSCL) 1.0, W3C Note, 2002, available at: http://www.w3.org/TR/2002/NOTE-wscl10-20020314/

[Benatallah et al., 2003] B. Benatallah, F. Casati, F. Toumani and R. Hamadi: Conceptual Modelling of Web Service Conversations, HP Technical Report HPL-2003-60, 2003.

[Booch et al., 1998] G. Booch, I. Jacobsen and J. Rumbaugh: The Unified Modeling Language Reference Manual, Addison Wesley, 1998.

[Both & Lewis, 2003] D. Booth and A. Lewis: Message Exchange Patterns Versus Input/Output Patterns,W3C Disscussion Document, 2003, available at: http://dev.w3.org/cvsweb/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm?rev=1.4

[Chinnici et al., 2003] R. Chinnici, M. Gudgin, J.J.Moreau, J. Schlimmer and S. Weerawarana: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft, 2003, available at: http://www.w3.org/TR/2003/WD-wsdl20-20031110/

[Fielding et al., 1999] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, The Internet Engineering Task Force, 1999, available at: http://www.ietf.org/rfc/rfc2616.txt.

[Fielding, 2000] R.T. Fielding: Respresentational State Transfer, Dissertation at University of California, Irvine, 2000, available at: http://www.ics.uci.edu/~fielding/pubs/dissertation/.

[Fielding & Roy, 2000] R.T. Fielding and R.N. Taylor: Principled Design of the Modern Web Architecture, 2000, available at: http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf.

[Gudgin et al., 2003] M. Gudgin, A. Lewis and J. Schlimmer: Web Services Description Language (WSDL) Version 2.0 Part 2: Message Patterns, W3C Working Draft 10 November 2003, available at: http://www.w3.org/TR/2003/WD-wsdl20-patterns-20031110/.


Deliverable ID: 2.2

Page: 38 of 38

Version: 1.3 Date: 31.03.2004

Status: FINAL

[Haas & Brown, 2003] H. Haas and A. Brown: Web Services Glossary, W3C Working Draft, 2003, available at http://www.w3.org/TR/2003/WD-ws-gloss-20030808/.

[Hohpe & Woolf, 2003] G. Hohpe and B. Woolf: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Pearson Education, 2003.

[Huth & Ryan, 1999] M. Huth and M. Ryan: Logic in Computer Science: Modelling and reasoning about systems, Cambridge University Press, Cambridge, 1999.

[Kuno & Lemon, 2001] H. Kuno and M. Lemon: A Lightweight Dynamic Conversation Controller for e-services, HP Technical Report HPL-2001-25R1, 2001.

[López et al., 2003] J.M. López, S. Williams and B. Motik: Report on Web Service Mediation Framework, SWWS IST-2002-37134 Deliverable, 2003.

[Roman et al., 2004] D. Roman, H. Lausen and U. Keller: Web Service Modeling Ontology - Standard (WSMO - Standard), WSMO Working Draft, 2004, available at: http://www.wsmo.org/2004/d2/v02/20040306/

[Trastour et al., 2002] D.Trastour, M.Ferdinand and C.Zirpins, Lifting XML Schema to OWL: Theory and Practice. 2002.

swws - semantic web enabled web services · 3.3.2 message filter pattern 23 3.3.3 enricher 24 3.3.4...

Documents