1

INF5120 – Model-Based System Development

Lecture #10: SOA, Web services architecture XSD WSDL BPEL

ICT

architecture, XSD, WSDL, BPEL28 March 2011

Based on material developed in the ATHENA (IST-507849), COMBINE (IST-1999-20839), INTEROP (IST-508011), MODELWARE (IST-511731) and SHAPE (ICT-2007-216408) research projects.

INF5120 - Lecture plan - 2011

1: 24/1: Introduction to Model Based System Development (INF5120)

Part I: MDE – Model Driven Engineering 2: 31/1: MDE I: Metamodels, Domain specific languages and UML profiles 3: 7/2: MDE II: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta) 4: 14/2: MDE III: Model transformations - MOFScript, 6: 28/2: MDE IV: Method Engineering with SPEM / EPF/SEMATg g

Part II: SSI – Service Innovation and Engineering 5 :21/2: SIE I: Service Innovation and CSI, Enterprise Architecture and Service methodologies 7: 7/3: SIE II::Business Process Modeling with BPMN 2.0 8: 14/3: SIE III: User-oriented design – with Use cases and UI models 9: 21/3: SIE IV: Service modeling with SoaML, 10: 28/3: SIE V: SOA technologies - with WSDL, XML, BPEL and Patterns

Part IV – Model Driven Interoperability 11: 4/4: MDI I: Semantic technologies, Ontologies and Semantic annotations 12: 11/4: MDI II: Model Driven Service Interoperability EASTER 13 2/5 MDE III ADM and Migration to Clo d comp ting

ICT 2

13: 2/5: MDE III: ADM and Migration to Cloud computing

14: 9/5: Conclusion and Summary for INF5120 - Preparation of Exam

Exam: May 30th, 2011 (Monday), 0900-1300 (4 hours)

2

Outline

Service-oriented architecture (SOA)

MDD for SOA & SOA platformsMDD for SOA & SOA platforms

Web services architecture UDDI

SOAP

XSD

WSDL

BPEL

ICT

BPEL

References

Patterns

Service-oriented architecture (SOA)

ICT

3

Different kinds of architectures

Integration architecture

Architecture f k

Enterprisearchitecture

Business architecture

Conceptual architecture

framework

Logical architecture

Knowledge architecture

Realisation

Service-oriented

architecture

ICT

Information architecture

Realisation architecture

Functional architecture

ICT architecture

Web servicesarchitecture

EA – SOA – WSA

Enterprise architecture (EA) is the practice of applying a method for describing a current and/or future structure and behaviour for an organization's processes, information systems, personnel and organizational g p , y , p gsub-units, so that they align with the organization's core goals and strategic direction. Holistic view of the enterprise and all its important assets.

Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. [OASIS 2006] Architectural style for designing (technical) systems.

ICT

Web services architecture (WSA) intends to provide a common definition for understanding Web services. A Web services architecture involves many layered and interrelated technologies. [W3C 2004] A set of enabling Web technologies for implementing software systems.

4

Role of enterprise architecture

Mission

Vision

Goals

Strategy

Actions

Vision

as is to be

enterprise architecture

domain/aspect

culture

leadership

ICT

Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.

domain/aspectarchitectures people

Operations…

peopleprocesses ITproducts

Describing coherence

P hit t

Information architecture Product architecture

?

Process architecture

Application architecture Technical architecture

?

?

?

ICT

Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.

?

5

Basic service-oriented model

Service provider Provides software applications for specific needs as services.

Service requester A requester could be a human user/application program/another service accessing the service

ICT

A requester could be a human user/application program/another service accessing the service through a desktop or a wireless browser; it could be an application program.

Service broker: A service broker provides a searchable repository of service descriptions.

Examples of service brokers are UDDI (Universal Description, Discovery, and Integration).

OASIS Reference Model forService Oriented Architecture 1.0

OASIS http://www.oasis-open.org/home/index.php

Abstract framework Abstract framework. Understanding significant entities and relationships between them within a

service-oriented environment. Development of consistent standards or specifications supporting service-

oriented environment. Based on unifying concepts of SOA and may be used by

architects developing specific service-oriented architectures in training and explaining SOA.

Reference model not directly tied to any standards, technologies or th t i l t ti d t il

ICT

other concrete implementation details Provide a common semantics that can be used unambiguously across

and between different implementations. The reference model focuses on the field of software architecture.

6

What is an SOA

Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of diff t hi d idifferent ownership domains.

Visibility, interaction, and effect are key concepts for describing the SOA paradigm. Visibility refers to the capacity for those with needs and those with

capabilities to be able to see each other.

Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), interaction is the activity of using a

ICT

p ( ), y gcapability.

The purpose of using a capability is to realize one or more real worldeffects. At its core, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects).

Principal concepts

ICT

7

Principal concepts

Visibility: The capacity for those with needs and those with

Service description: The information needed in order to use, or consider using, a service.

Service: The means by which the needs of a consumer are brought together with the capabilities of a provider.

with needs and those with capabilities to be able to interact with each other.

Execution context: The set of technical and business elements that form a path between those with needs and those with capabilities and that permit service providers and consumers to interact. Policy: A statement of

obligations, constraints or

ICT

Interaction: The activity involved in making using of a capability offered, usually across an ownership boundary, in order to achieve a particular desired real-world effect.

Real world effect: The actual result of using a service, rather than merely the capability offered by a service provider.

obligations, constraints or other conditions of use of an owned entity as defined by a participant.

Visibility

ICT

8

Visibility

For a service provider and consumer to interact with each other they have

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence. Service awareness requires that the service description and policy – or at least a suitable subset thereof – be available.

with each other they have to be able to ‘see’ each other. Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and

h bilit

Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. The extent of a service participant’s willingness

ICT

reachability. participant s willingness to engage in service interactions may be the subject of policies.

Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

Interacting with services

ICT

9

Interacting with services

The formal descriptions of terms and the relationships between them (e.g., an ontology)

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service.

provides a firm basis for selecting correct interpretations for elements of information exchanged.

Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service.

The information model of a service is a characterization of the information that may be exchanged with the service.

The action model of a service is the characterization of the actions that may be

ICT

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages. Key concepts that are important in understanding what it is involved in interacting with services revolve around the service description – which references a information model and a behavior model.

exchanged with the service.

The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service.

characterization of the actions that may be invoked against the service.

Real world effect

ICT

10

Real world effect

In this context, the shared state does not necessarily refer to specific state variables being , y p gsaved in physical storage but rather represents shared information about the affected entities. In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them.

ICT

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants.

Service description

ICT

11

Service descriptionThe service description represents the information needed in order to use a service.

A service description SHOULD include

The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world A service description SHOULD include

sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

effects as specified through the service functionality portion of the service description.

ICT

A service description SHOULD unambiguously express the function(s) of the service and the real world effects that result from it being invoked.

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

Execution context

ICT

12

Execution context

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction and thus forms a path

ICT

interaction, and thus forms a path between those with needs and those with capabilities.

MDD for SOA & SOA platforms

ICT

13

h f

or

SO

A

Architecture Specification

UML Profile for SOA(SoaML)re

nc

e O

nto

log

y

annotated with

EnterpriseModel

Enterprise Model

• BMM• BPMN• …

Model to ModelTransformation

Business Requirements

Analysis

annotated with

ng

ap

pro

ach Service-Oriented

Architecture Model

Web ServiceSpecification Model

Agent SpecificationModel

BPEL SpecificationModel

P2P SpecificationModel

Model Transformation

UML Profile for Web Services

UML Profile for Agents

UML Profile for BPEL

UML Profile for P2P

Model Transformation

(SoaML)

Re

fer

Model to Model Transformation

Model to TextTransformation

annotatedwith

annotated

ICT

Mo

del

lin

SemanticSpace

Web ServiceExecution Artefacts

AgentExecution Artefacts

BPELExecution Artefacts

P2PExecution Artefacts

Execution Infrastructure

RegistryRepository

Service W rappers (Enterprise A)

Evaluation & Negotiation of Available Functionality

Enhanced Service Interconnection Bus

Cross-org.

Intra-org.

Existing Enterprise Applications

PublicInfrastructure Services

Service W rappers

(Enterprise X)

Service W rappers

(Enterprise Y)

InternalInfrastructure Services

Process

Execution

Platform

(BPEL)

Goal- orientedAdaptive

ExecutionPlatform

(Agents)

Goal- orientedAdaptive

ExecutionPlatform

(Agents)

Active

Model

Platform

( AKMii)

Active

Model

Platform

( AKMii)

LegendMessage-

Oriented

Platform

( MQSeries)

Message-

Oriented

Platform

( MQSeries)

Server- side

Component

Platform

(.NET, J2EE)

Server- side

Component

Platform

(.NET, J2EE)

Composed

W ebServicePlatform

( W ebServices)

Business Process/Agent

Active (Business) Model

W eb/Server Component

Middleware Process/Agent

Middleware Component

Adaptive Distributed

Resource Mgt Platform

(P2P)

Deployment

OWLOntology

with

atio

ns CIM

“EA”Metamodel

SOAMetamodel

PIM

Symbols

Metamodel

Concept

Relationship

Correspondence

el t

ran

sfo

rma

ICT

Web ServicesMetamodel

Agent Metamodel(AgentMM)

P2PMetamodel

GridMetamodel

PS

Ms

Mo

de

14

ICT

SOA platform consolidation

Data and information integration ➪ Information Fabric EII: Enterprise information integration ETL: Extract transform and load ETL: Extract, transform and load

Application integration ➪ Integration Suite EAI: Enterprise application integration B2Bg: Business-to-business gateway ESB: Enterprise service bus

Applications and Processes ➪ Business Process Management Suite BPM: Business process management

ICT

p g B2Bi: Business-to-business integration

Enterprise workplace ➪ Interaction Platform

15

ICT

Integration suite services

ICT

Goal: Composite applications

Components: EAI, BPM, B2B, B2Bi

Extensions: Adapter, collaboration, analysis, reporting, development, monitoring, contracts, SOA standards, …

16

Business process management suite& interaction services

ICT

Goal: Continuous process improvement Components: BPM

human-centric: people-intensive processes Integration-centric: system-intensive processes

Information fabric services

ICT

Goal: Holistic view of data (information virtualisation)

Components: DBMS, EII + ETL + replication

Extensions: Distributed meta-data repository, distributed data access, integrated data management

17

Architecture of Web-based solutions

W b

ClientTierDynamic HTML

PagesApplication

Client

ClientMachine

WebTier

BusinessTier

EJB SessionBeans

JSP / JSFPages

JavaBeans(optional)

Java EEServer

BPELProcesses

Web Services Web ServicesWeb Services

ICT

PersistentEntities

Enterprise InformationSystem (EIS)

TierDatabase

DatabaseServer

Web services architecture

ICT

18

What is a Web service?

The term “Web services” is confusing.

There are many things that are referred to as “WebThere are many things that are referred to as Web services”.

Adding to the confusion is the term “services” which is interpreted differently by different people.

ICT

WebWeb serviceservice

What is a Web service?

WebWeb serviceservice

Web is short for World Wide Web.

Work performed or offered by a software system (possibly including human resources as well.)

ICT

Software services performed or offered on the Web, using open Internet standards and technologies.

19

Definition (W3C): Web service

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a pnetwork. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”

ICT

- W3C Web Services Glossary, http://www.w3.org/TR/ws-gloss/

Characteristics of a basic Web service

Two fundamental requirements: It sends and receives data formatted as XML documents using g

SOAP over HTTP.

It provides a WSDL service description.

Additionally, it is common for a Web service to: Be registered with a discovery agent through which it can be

located, typically UDDI.

ICT

20

Web services stack

ICT

Technologystack

Conceptualstack

Web services – a conceptual view

Business EntitiesWeb Service Interfaces

BPEL

___________

EGO-CentricWorkflow Process

WS-CHOR

____________________________________________________________

Interaction Sequencing

(Co)Constraints

Messaging Encoding

Web Service Interfaces

SOAPRaw XML ebXML

_________________________________________________

ProcessDescription

WSDL

_______________________________________________________

(Syntactic) Web Service Interface Description

ICT

Underlying Protocols

HTTP/WEB

VANsFTP

SMTP/EMAIL MQ-Series

EDI“Binary”

_____

Bindings and Endpoint Descriptions

XSD

____________________________________________________________

XML MessageSchemaDefinition

21

Web Services Architecture

BPEL

ICT

WS-* stack to-be

Simplified version of the to-be WS-* stack Families of related specs not expanded

Competing spec families not shown

“Historical” or abandoned specs not shown

XML

SOAP WSDL

BPEL

WS-Addressing

WS-ReliableMessagingWS-Coordination

WS-PolicyWS-Notification UDDI

ICT

XML BPEL

WS-CDLWS-Security

g g

WS-MetadataExchange

WS-ResourceWS-Transfer

WS-Federation

22

WS-* stack as-is

Complete version of the as-is WS-* stack The 3 widely-accepted specs today are the same as 5 years ago BPEL and WS Security is gaining momentum BPEL and WS-Security is gaining momentum Orchestration, discovery and brokering do not exist in today’s world

XML

SOAP WSDL

BPEL

WS-Addressing

WS-ReliableMessagingWS-Coordination

WS-PolicyWS-Notification UDDI

ICT

XML BPEL

WS-CDLWS-Security

g g

WS-MetadataExchange

WS-ResourceWS-Transfer

WS-Federation

Model-driven Web Services –Two alternatives

Model-to-modelPIM

(S ML d l )PSM

(WS UML P fil )

1 ATL

Model to model(SoaML models) (WS UML Profile)

Model-to-textModel-to-text

2

1MOFScript MOFScript

Transformation choices:• fixed• config file• user is prompted

ICT

Web Service (XML, Textual)

transformation

1. Transformation in two steps via UML profile

2. Transformation in one step

• user is prompted

23

Web service metamodels

Reliability<<Metamodel>>

Coordination<<Metamodel>>

Eventing<<Metamodel>>

+ WS-BaseNotification.+ WS-BrokeredNotification.

+ WS-Eventing.

Resource Access and Management

<<Metamodel>>

+ WS-Enumeration.+ WS-Resource.

+ WS ResourceLifetime

Registry<<Metamodel>>

+ UDDI.

Endpoint Description<<Metamodel>>

+ WS-MetadataExchange.+ WS-Policy.

+ WS-PolicyAttachement.

Reliability

+ WS-ReliableMessaging.

Coordination

+ WS-Coordination.+ WS-Topics.

+ WS-ResourceLifetime.+ WS-ResourceProperty.

+ WS-Transfer.

Transport<<Metamodel>>

+ HTTP.

Messaging<<Metamodel>>

+ SOAP.+ WS-Addressing.

ICT

Service Interface Description

<<Metamodel>>

+ WSDL 1.1.+ WSDL 2.0.

XML<<Metamodel>>

+ XML Core / XSD.+ XML Encryption.+ XML Signature.

+ XPATH.

Security<<Metamodel>>

+ WS-Security.

Universal Description, Discovery and Integration (UDDI)

ICT

24

UDDI Registry 44..

SW companies, standards SW companies, standards bodies, and programmers bodies, and programmers populate the registry withpopulate the registry with

11..

Universal Description, Discovery and Integration

UDDI Business Registry

Marketplaces, search Marketplaces, search engines, and business apps engines, and business apps query the registry to query the registry to discover services at other discover services at other companiescompanies

p p g yp p g ydescriptions of different types descriptions of different types of servicesof services

22..

55..

ICT

3. UBR assigns a programmatically unique identifier to each service and business registration

Service TypeRegistrations

BusinessRegistrationsBusinesses Businesses

populate populate the registry withthe registry withdescriptions of descriptions of the services they the services they supportsupport

Business uses this Business uses this data to facilitate easier data to facilitate easier integration with each integration with each other over the Webother over the Web

Registry data

Businesses register public informationinformationabout themselves

Standards bodies, Programmers, Businesses register information about their Service Types

ICT

25

The global UDDI business registry

Application

Business Service

Application

Application

ICT

Registrator

UDDI – Four information types

<businessEntity>name, contacts,d i ti i d tifi t idescription, indentifiers, categories

<businessService> sService> (1..n)

namedescription, categories

<bindingTemplate>(1..n)t h i l i f ti

<tModel>namedescriptionURL pointers to specifications

ICT

technical information

26

Simple Object Access Protocol (SOAP)

ICT

Use of SOAP

application -service

serviceprovider

network protocol

SOAP

requester

network protocol

SOAP

respons(soap response message)

1 4 23

ICT

request(soap request message)

(soap response message)

27

SOAP envelope

ICT

Making a SOAP function call over HTTP

Header

HTTP Request

Body

XMLData

Header

HTTP Response

ICT

Body

XMLData

Header

28

The SOAP Envelope

<SOAP:Envelope>

<SOAP:Header></SOAP:Header> Optional

<SOAP:Body>

<m:FunctionName> <paramName1>paramValue1</paramName1>

<paramName2>paramValue2</paramName2>

</m:FunctionName>

</SOAP:Body>

ICT

</SOAP:Body>

</SOAP:Envelope>

XML Schema Definition (XSD)

ICT

29

XML Schema Definition (XSD)

Description An XML schema describes the structure of an XML document.

XSD is a comprehensive data modelling language for XML documents.

The one XML schema specification that has received the broadest industry support.

The XML schema definition language is also referred to as XML Schema Definition (XSD).

XML schema is an XML-based alternative to DTD It

ICT

XML schema is an XML based alternative to DTD. It replaces/superseedes DTD.

- W3C, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium (W3C), W3C Recommendation, 28 October 2004. http://www.w3.org/TR/xmlschema-0/

XSD: Purpose

Define the legal building blocks of an XML document: Defines elements that can appear in a document.pp

Defines attributes that can appear in a document.

Defines which elements are child elements.

Defines the order of child elements.

Defines the number of child elements.

Defines whether an element is empty or can include text.

Defines data types for elements and attributes.

ICT

Defines default and fixed values for elements and attributes.

30

XSD: Approaches for specification

Several different ways of specifying an XSD. XML text editor

XML schema design editor

UML profile for XSD

ICT

XSD: XML text editor

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name=“XMLRequest">

<xs:complexType>

…

</xs:complexType>

</xs:element>

</xs:schema>

ICT

Can also be built using simple text editors

XML editors gives contextual support, e.g. like auto-completion, suggestions for elements, etc., as well as validation of the XML document.

</xs:schema>

31

XSD: XML schema design editor (1/3)

ICT

Visual language for schema design

Supported by e.g. XMLSpy

XSD: XML schema design editor (2/3)

Terminal: This is the graphical representation of

Element types

g p pterminal elements. They usually contain text, numbers or another type of basic data.

Intermediate: The intermediate elements represents the structure of the document. The "+" symbol indicates us that the element can contain more elements.

Relationship types

Sequence: This schema represents that

ICT

Sequence: This schema represents that bankingInformation contains element accountNumber and bankData.

Choice: This schema represents that fileId contains fileUri or (exclusive or) fileName.

32

XSD: XML schema design editor (3/3)

Cardinality modifier

We have seen the types and relationship between elements, but not the times that an element can appears.

Zero or one: Tell us that the element is optional (can appear zero or one times).

One or more: Tell us that the element appears at least one time, but can appear all times we want.

ICT

one time, but can appear all times we want.

Zero or more: Tell us that the element appears zero or more times.

XSD: UML profile for XSD

ICT

UML representation of XML schema.

Useful in a UML-centric development method if the modelling environment supports generation/import of XSD documents.

33

XSD metamodel

ICT

XSD metamodel (simplified)

ICT

34

UML profile for XSD (1)Stereotype UML

construct Tagged value Description

<<any>> Class, Property

The stereotyped class or attribute will be relaced by an 'any' or 'anyAttribute' element. The tagged values are copied into the corresponding attributes of the generated l telement

namespace As defined in XML Schema specification processContents As defined in XML Schema specification

values="skip | lax | strict" default="strict"

<<attribute>> Property Assigned to UML attribute or association end. Indicates item is to be generated as an attribute within complexType and not as an element

default As defined in XML Schema specification fixed As defined in XML Schema specification form Overrides the attributeFormDefault for this

schema l " lifi d | lifi d"

ICT

values="qualified | unqualified" use As defined in XML Schema specification

values="prohibited | optional | required" default="optional"

<<choice>> Class Elements marked with this stereotype represent a Choice model group conatined within a complexType definition

<<complexType>> Class ComplexType definition generated in XML Schema

memberNames Overrides the package-level default for naming complexType definitions values="qualified | unqualified"

UML profile for XSD (2) mixed Determines whether this element may contain

mixed element and character content. values="true | false" default="false"

modelGroup Overrides the package-level default model groupgroup values="all | sequence | choice"

<<element>> Property Assigned to UML attribute or association end. Indicates item is to be generated as element within complexType and not as attribute

anonymousRole The class type will be directly embedded within the complexType definition. Omit attribute or role type wrapper values="true | false" default="false"

anonymousType The class type will be anonymous for XML documents generated by the schema

ICT

documents generated by the schema values="true | false" default="false"

form Overrides the elementFormDefault for this schema values="qualified | unqualified"

position If assigned, indicates position in the sequence model group

<<facet>> Property A facet is a single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent

35

UML profile for XSD (3)UML representation Text representation

ICT

Web Services Description Language (WSDL)

ICT

36

Web Services Description Language (WSDL)

Purpose Web services need to be defined in a consistent manner so that

they can be discovered by and interfaced with other services and applications.

The Web Services Description Language is a W3C specification providing the foremost language for the description of Web service definitions.

- W3C, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", World Wide Web Consortium (W3C), W3C Working Draft 3 August 2004 http://www w3 org/TR/2004/WD-

ICT

Working Draft, 3 August 2004. http://www.w3.org/TR/2004/WD-wsdl20-20040803/

WSDL: Description

XML-based language for describing functional properties of Web services.

A service consists of a collection of message exchange end points A service consists of a collection of message exchange end points. An end point contains an abstract description of a service interface

and implementation binding. The abstract description of a service contains:

(i) definitions of messages which are consumed and generated by the service

(ii) signatures of service operations.

The implementation binding provides a means to map abstract

ICT

p g p poperations to concrete service implementations. It essentially contains information about the location of a binding and the

communication protocol to use (e.g., SOAP over HTTP) for exchanging messages

37

WSDL: Conceptual view

Business EntitiesWeb Service Interfaces

Messaging Encoding

SOAP

EDI“Binary”

Raw XML ebXML

WSDL

____________________________________________________________

(Syntactic) Web Service Interface Description

ICT

Underlying Protocols

HTTP/WEB

VANsFTP

SMTP/EMAIL MQ-Series

yBindings and Endpoint Descriptions

WSDL: Conceptual model

WS Interface

WS Provider

WSClient

Ports

Operations

Porttype

Concrete Endpoint Address

Operations Invoked through Ports

ICT

Operations

Name,Abstract Message Parts SchemaMessage Exchange Pattern

Operation

Concrete Message EncodingConcrete Messaging Protocol

(Reusable) Binding

Concrete Endpoint Address

38

WSDL: Message exchange patterns

WS Provider

WSClient

Time

Request-Response

One-Way

ICT

Solicit-Response

Notification

WSDL 1.1 metamodel

WSDL DocumentWSDL Component

0..10..1

Import

Include

+ Location

A container for data type definitions

Port

+ Name Part

N

Service

+ Name

1..*1..*

Message 0 *0 *

p

+ NameSpace

+ Location

Element

+ Name

+ BaseType

+ MinOccurs

+ MaxOccurs

Definition

+ Name

+ TargetNameSpace0..*0..*

0..*0..*

0..*0..*

Schema

+ TargetNameSpaceTypes

0..10..1

A collection of related endpoints

A single endpoint defined as a combination of a binding and a network address

An abstract, typed definition of the data being communicated

ICT

Operation

+ Name

+ Name

+ Type

+ Element

Binding

+ Name

1

1

1

1

Port Type

+ Name

11 11

Message

+ Name

1..*

0..1

1..*

+input

0..10..1

+output

0..10..1+fault 0..1

0..0..

0..*0..*0..*0..*

address

A concrete protocol and data format specification for a particular port type

An abstract set of operations supported by one or more endpoints

An abstract, description of an action supported by the service

39

Changes in WSDL 2.0

Removal of Operation overloading

PortType renamed to InterfacePortType renamed to Interface Interface inheritance

Port renamed Endpoint

Extended repertoire of Message Exchange Patterns.

ICT

WSDL 2.0 metamodel

Definitions Interface Fault

+ name : wsdls_NCName+ target namespace : wsdls_anyURI

11

Interface

+ name : wsdls_NCName+ target namespace : wsdls_anyURI0..*

+interfaces

0..*

0..*

+extended interfaces

0..*

0..*

+faults

0..*

+fault reference+bindings 0..1

+interface0..1

Interface Operation

+ name : wsdls_NCName+ target namespace : wsdls_anyURI+ message exchange pattern : wsdls_anyURI+ style [0..*] : wsdls_anyURI

f dl b l

1+fault reference1

0..*+operations 0..*

Binding Fault

1

fault reference

1

Binding Operation

1

+operation reference

1

1+interface

1Binding

+ name : wsdls_NCName+ target namespace : wsdls_anyURI+ type : wsdls_anyURI

0..*0..*

0..*

+faults

0..*

0..*

+operations

0..*

Property

+ name : wsdls_anyURI+ required : wsdls_boolean

0..*+properties

0..*

0..*+properties

0..* 0..*+properties

0..*0..*+properties0..*

0..*

+properties

0..*

0..*

+properties

0..*

0..*

+properties

0..*

0..*

+properties

0..*

0..*+properties

0..* 0..*+properties0..*

Feature

+ name : wsdls_anyURI+ required : wsdls_boolean

0..*+features

0..*

0..*

+features

0..*

0..*

+features

0..* 0..*+features

0..*

0..*

+features

0..*

0..*

+features

0..*

0..*

+features

0..*0..*

+features

0..*

0..*

+features

0..*

0 *+features

0 *

1

+binding

1

0..*+properties0..*

0 *+features

0 *

ICT

+ safety : wsdls_boolean

Message Reference

+ message label : wsdls_NCName+ direction : wsdls_token+ message content model : wsdls_token

0..*

+message references

0..*

Fault Reference

+ message label : wsdls_NCName+ direction : wsdls_token

0..*+fault references0..*

Binding Message Reference

+ message label : wsdls_NCName+ direction : wsdls_token

0..*+message references

0..*

Service

+ name : wsdls_NCName+ target namespace : wsdls_anyURI

0..*+services 0..*

0..0.. 0..0..0..0..

Endpoint

+ name : wsdls_NCName+ address : wsdls_anyURI1..*

+endpoints

1..*

0..*0..*

40

UML profile for WSDL (1)Stereotype UML

construct Tagged value Description

<<binding>> Class A concrete protocol and data format specification for a particular port type. A concrete protocol and data format specification for a particular port type. A <<binding>> class represents a binding component of the WSDL metamodelmetamodel.

binding Binding type default=”soap:binding”

style The style attribute indicates whether the operation is a remote procedure call (RPC) or a document-oriented operation. default=”rpc”

transport The transport attribute specifies the type of binding to be used. default=”http://schemas.xmlsoap.org/soap/http”

<<definition>> Class A <<definition>> class represents a definition component of the WSDL metamodel.

targetNameSpace TargetNameSpace is an URI (Uniform Resource Identifier) It is mandatory and identifies the namespace

ICT

Identifier). It is mandatory and identifies the namespace which it will belong all of the component names.

<<element>> Class An <<element>> class represents an element of the XML Schema.

baseType The base type maxOccurs The maximum number of occurrences minOccurs The minimum number of occurrences name The name of the element <<fault>> Association An <<fault>> association represents a relationship

between an operation and a message in the WSDL metamodel.

<<import>> Class An <<import>> class represents an import component of the WSDL metamodel.

UML profile for WSDL (2) location Location is an URI. It is optional and indicates the

location of some information for the namespace. namespace Namespace is an URI (Uniform Resource Identifier). It is

mandatory and indicates that the containing WSDL document can contain references to the WSDL definitions in that namespace.

<<input>> Association An <<input>> association represents a relationship between an operation and a message the WSDL metamodel.

<<message>> Class An abstract, typed definition of the data being communicated. A <<message>> class represents a message component of the WSDL metamodel.

<<operation>> Class An abstract, description of an action supported by the service. An <<operation>> class represents an operation component of the WSDL metamodel.

<<output>> Association An <<output>> association represents a relationship

ICT

between an operation and a message the WSDL metamodel.

<<part>> Class A <<part>> class represents a part component of the WSDL metamodel.

type Type is a base type XSD. It is optionally and must be defined when the part component uses a base type but not when the part component uses an element of the XML Schema.

<<partElement>> Association A <<partElement>> association represents a relationship between a part component of the WSDL metamodel and

41

UML profile for WSDL (3)

UML representation Text representation

ICT

Web Services Business Process Execution Language (WS-BPEL)

ICT

42

Web Services Business ProcessExecution Language (WS-BPEL)

Description WS-BPEL (or BPEL for short) is a language based on XML that allows for

t lli th fl f t f ll b ti W b icontrolling the process flow of a set of collaborating Web services.

It can be seen as a (business) extension to the Web services paradigm.

Partner interaction is based on the notion of peer-to-peer interaction between Web services.

BPEL introduces concepts to express the peer-to-peer conversational relationships between services.

Partner links specify the services that a business process interacts with and is introduced as a WSDL extension element.

ICT

- T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana, "Business Process Execution Language for Web Services Version 1.1", May 2003. ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

BPEL language

XML notation

Interaction with other Web services: <receive>. Wait for an incoming message. Typically at the process start

<invoke>. Call another Web service

<reply>. Send a response message from the entire BPEL service

Control flow <sequence>. Sequential control flow

<flow>. Parallel control flow

<switch>. Conditional branching

ICT

g

<while>. Loop

Data flow <variable>. Defines the data objects involved

<assign>. Copy a data object from one variable to another possibly w/ data transformation

43

Web service composition

BPEL is a Web service composition language.

It defines how to compose other Web services so toIt defines how to compose other Web services so to accomplish a more complex task.

A BPEL engine is capable of executing the composite service described by BPEL.

The outcome will be a composite BPEL-defined Web service which itself can be regarded as a Web service.

ICT

BPEL simplified viewA BPEL process is a composite Web service with a WSDL description.

ICT

44

BPEL roles in the Web services world

As a public specification of abstract services protocols business partners can supply precise information about semantics of a

service and its message propertiesservice and its message properties... ...without revealing internal (opaque) details of implementation

As an intermediate language for implementing business processes relatively portable extensible for platform-specific operations possible

As a programming language for Internet-scale distributed applications messaging concurrency

ICT

error handling ...

BPEL foundations

ICT

45

BPEL details Two Uses

Executable process descriptions Business protocol descriptions – Abstract

processes

Partner links Paired WSDL interfaces Correlation sets

Bind messages to process/activity instances. Endpoint references

Partner Grouping constraint on partner links to a single

business partner.

Process

Partner - Links

WSDL PortType

ICT

Process Activities Basic - assign, throw, terminate, wait, empty,

compensate Partner interaction - receive, reply, invoke Structured - sequence, switch, while, pick, flow,

scope

BPEL process and scope activities

P t Li k V i bl

Message variables shared by activities in <scope/>

Primary

Partner Links

Partners<process/> only

Fault Handlers

Compensation Handler

Event Handlers

Install special purpose activities in scope

Compensation of completed scopes

Variables

Correlation SetsCorrelation sets for associating messages with process/activity instances

ICT

a yActivity

completed scopes

46

BPEL example

ICT

PO : POMessage

receive

shippingInfo

shippingSchedule

flow

ICT

Invoice : InvMessage

reply

sequence sequence sequence

47

WSDL port type XML syntax

<portType name="purchaseOrderPT"><portType name="purchaseOrderPT"><operation name="sendPurchaseOrder">

<input message="pos:POMessage"/><output message="pos:InvMessage"/><fault name="cannotCompleteOrder"

message="pos:orderFaultType"/></operation>

</portType>

ICT

Partner link types

ICT

48

Purchase order WSDL

<message name="POMessage"><part name="customerInfo" type="sns:customerInfo"/><part name="purchaseOrder" type="sns:purchaseOrder"/>

</ ></message><message name="InvMessage">

<part name="IVC" type="sns:Invoice"/></message><message name="orderFaultType">

<part name="problemInfo" type="xsd:string"/></message><message name="shippingRequestMessage">

<part name="customerInfo" type="sns:customerInfo"/></message>

ICT

g<message name="shippingInfoMessage">

<part name="shippingInfo" type="sns:shippingInfo"/></message><message name="scheduleMessage">

<part name="schedule" type="sns:scheduleInfo"/></message>

BPEL Process<process name="purchaseOrderProcess"

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"><partnerLinks>

<partnerLink name="purchasing"partnerLinkType="lns:purchasingLT"myRole="purchaseService"/>

<partnerLink name="invoicing"partnerLinkType="lns:invoicingLT"myRole="invoiceRequester"partnerRole="invoiceService"/>

<partnerLink name="shipping"partnerLinkType="lns:shippingLT"myRole="shippingRequester"partnerRole="shippingService"/>

<partnerLink name="scheduling"

ICT

<partnerLink name schedulingpartnerLinkType="lns:schedulingLT"partnerRole="schedulingService"/>

</partnerLinks>

49

BPEL process<sequence><receive partnerLink="purchasing"

portType="lns:purchaseOrderPT"operation="sendPurchaseOrder"variable="PO"/>/

<flow><links>

<link name="ship-to-invoice"/><link name="ship-to-scheduling"/>

</links><sequence>

<assign><copy>

<from variable="PO" part="customerInfo"/><to variable="shippingRequest" part="customerInfo"/>

</copy></ i >

ICT

</assign>...

BPEL process

<invoke partnerLink="shipping"portType="lns:shippingPT"operation="requestShipping"inputVariable="shippingRequest"inputVariable shippingRequestoutputVariable="shippingInfo">

<source linkName="ship-to-invoice"/></invoke>

<receive partnerLink="shipping"portType="lns:shippingCallbackPT"operation="sendSchedule"variable="shippingSchedule">

<source linkName="ship-to-scheduling"/></receive>

ICT

...

50

UML profile for BPEL (1)Stereotype UML

construct Description

<<assign>> Action An assign activity maps to a BPEL assign activity with each entry action mapping to a copy element. The right-hand side of each assign statement provides the details of a from element and the left-hand side provides then details of the to element.

<<catch>> Action When an invoked operation throws an exception or a throw<<catch>> Action When an invoked operation throws an exception, or a throw activity explicitly throws an exception, normal execution within the containing scope is terminated.An exception can be caught within the containing scope so that error recovery behavior can be performed. This is modelled as an <<catch>> activity.

<<compensate>> Action Compensation can be triggered by a compensate activity. We follow the BPEL semantics for compensation and when it can be triggered. In particular, a compensate activity is only permitted in the following places: In a catch activity of the scope that immediately encloses the

scope for which compensation is to be performed. In the compensation handler of the scope that immediately

encloses the scope for which compensation is to be performed

ICT

performed.<<compensationHandler>> Action Compensation handler activities can be defined to reverse the

work performed by a scope, if necessary. Compensation handler activities are not executed when control reaches the parent activity. If the parent activity completes successfully then the compensation handler is installed.

<<correlation>> Class, Property A correlation set is defined by a class stereotyped by <<correlation>> containing attributes with names and types matching those of properties defined within its namespace. A process specifies that it uses a correlation set through an attribute with the type of the correlation set. The stereotype <<correlation>> can also be applied (redundantly) to the attribute to distinguish it from other attributes.

UML profile for BPEL (2)the attribute to distinguish it from other attributes.

<<data>> Class A message type has a number of parts, each of which is of a specified data type. Data types are represented by classes stereotyped as <<data>>.

<<external>> Package External packages contain elements that are defined in another model or elements that are defined directly as platform-specific artifacts (such as Web services or BPEL documents). External packages are not mapped to platform-specific artifacts. Elements that are reused can be modeled explicitly and placed in a package stereotyped with <<external>>.

<<invoke>> Action An invocation of an operation on a partner is represented as an activity with stereotype <<invoke>> with an entry action indicating the operation to be invoked and the attribute containing the input message. For two-way messages, assignment notation is used to indicate the attribute that is updated with the reply message.

<<loop>> Action A looping node is shown as an activity with the stereotype

ICT

<<loop>> Action A looping node is shown as an activity with the stereotype <<loop>>, which contains a decision node and an activity to be repeated, with a control link from the decision node to the activity. The guard on the control link provides the Boolean expression which determines whether the activity is executed each time round the loop.

<<messageContent>> Class A message type has a number of parts, each of which is of a specified data type. Message types are represented by classes stereotyped as <<messageContent>>

<<pick>> Action, It is often useful to group a set of receive activities and

51

UML profile for BPEL (3)

ICT

SensorWeb

Web based access and modeling of Sensors

Relate to Oblig2 and sensor models ?

See www.opengis.org

ICT

52

References

ICT

References

[ATHENA] ATHENA, "ATHENA Home Page", ATHENA IP. http://www.athena-ip.org/ [DnD] DnD, "Faggruppen for applikasjonsintegrasjon – metoder og arkitektur", Den

norske dataforening (DnD). http://www.dnd.no/ [El t t l 2005] B El t R K R lf F Lill h d D K l [Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen,

"Integrated Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134.

[INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/

[NESSI] NESSI, "Networked European Software & Services Iniative (NESSI)". http://www.nessi-europe.eu/Nessi/

[OASIS 2006] OASIS, "Reference Model for Service Oriented Architecture 1.0", OASIS, OASIS Standard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-

df

ICT

rm.pdf [W3C 2004] W3C, "Web Services Architecture", World Wide Web Consortium (W3C),

W3C Working Group Note, 11 February 2004. http://www.w3.org/TR/ws-arch/