web services - idatddd05/lectures/slides/f08-web-services.pdf · uddi, wsdl, and soap in a web...

Ola Leifler, IDA, Linköpings universitet

TDDD05Component-Based Software

Web Services

Many slides by courtesy of Welf Löwe, Stig Berild, Uwe Aßmann, C. Kessler

Content:

* SOAP

* WSDL

* UDDI

* BPEL, BPMN

* Web services and Java

* Evaluation and Wrap-up

2 TDDD05 Component-Based SoftwareO. Leifler, IDA, Linköpings universitet.

Recommended Reading

Szyperski, Chapter 12.4 + 10.5.3

W.M.P. Van der Aalst. Don't go with the flow: Web services composition standards exposed.IEEE Intelligent Systems, Jan/Feb 2003. http://tmitwww.tm.tue.nl/research/patterns/download/ieeewebflow.pdf


Amazon.com

Accounts Coop.

CitybankUPS

Keyword: Service

Order processing

Payment

Billing

DeliveryCreditability check

Service-architecture

Service = deployed components + provider with infrastructure


Order processing

Amazon.com

Reuse of (some) Services

Billing

Accounts

Billing

Bank

Payment

Parcel service

Delivery

Storage

Packing

Checking

Creditability check

Web Aggregate Order acceptance


Web Services: basic concept

DataOperation/Process

Standards required!


Service-Oriented Architectures (SOA)

All software components are modeled as services to be consumed over the network

The focus of design is on the service’s interfaceApplications are integrated at the interface (contract) level,

not at the implementation level

Services will be published (or withdrawn) dynamicallyRegistry

Services will be searched and discoveredDiscovery facility

SOA are based on tradersCORBA with trader service is a SOA, albeit platform-specific

Web services implement SOA


Description Framework

Components ofWeb Services

ApproachesJudgment

Vision

Revolution

Exists

EvolutionJudgments


XML Data Exchange

Approach

XML Exists


Message Description

Data: XML-document

+ W3C Recommendation (standard) + Easy syntax for hierarchical, structured documents+ Widely spread, accepted

- No semantics - Not compact / low performance- Ongoing standardizations


XML Example

<treatment>

<patient insurer=“1577500” nr=‘7503100815’/>

<doctor city=“SB” nr=‘4321’/>

<service>

<mkey>1234-A</mkey>

<date>2001-01-30</date>

<diagnosis>No complications.

</diagnosis>

</service>

</treatment>


Example: Simple XML Schema types

<simpletype name=‘mkey’ base=‘string’>

<pattern value=‘[0-9]+(-[A-Z]+)?’/>

</simpletype>

<simpletype name=‘insurer’ base=‘integer’>

<precision value=‘7’/>

</simpletype>

<simpletype name=‘myDate’ base=‘date’>

<minInclusive value=‘2007-01-01’/>

<maxExclusive value=‘2007-04-01’/>

</simpletype>


Example: Complex XML Schema types

<complextype name=‘treatment’>

<element name=‘patient’ type=‘patient’/>

<choice>

<element ref=‘doctor’/>

<element ref=‘hospital’/>

</choice>

<element ref=‘service’

maxOccurs=‘unbounded’/>

</complextype>


Example: XML Schema Attributes

<complextype name=‘patient’ content=‘empty’>

<attribute ref =‘insurer’ use=‘required’/>

<attribute name=‘nr’ use=‘required’>

<simpletype base=‘integer’>

<precision value=‘10’/>

</simpletype>

</attribute>

<attribute name=‘since’ type=‘myDate’/>

</complextype>


Question

Why do people like XML?

It is wordySlowUgly....

Remark: Binary XML variants are under development...See e.g. IEEE Computer 38(4): 16-18, April 2005+ compression- portability- many competing standards (although W3C has adopted

EXI)


Envelope

SOAP, An XML-based Interaction Protocol

Header Body

Simple Object Access Protocol (SOAP)defines the message format


SOAP – An XML-Based RPC

Message contains target address and an envelope

with name space, encoding attributes and

Header (fixed format), contains

Authentication (Sender, Receiver),

Transactions,

Error handling information,

Routing information …

Body contains user data (free format)

Transport is transparent, uses predefined channels:

HTTP (with back channel, de facto standard)

SMTP (Simple Mail Transport Protocol)

TCP (with back channel)


Example: SOAP Header

POST /TreatmentAdmin HTTP/1.1HOST: www.hospital-admin.comContent-Type: text/xmlCharset=“utf-8”Content-Length: nnnnSOAPaction: http://localhost/TreatmentAdmin

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header><a:Authentication xmlns:a=”http://localhost/TreatmentAdmin … “> …</a:Authentication>

</SOAP-ENV:Header><SOAP-ENV:Body> … </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Message HeaderHTTP

SOAP Envelope body

Each SOAP messageis an XML documentwith Envelope as root

element


Example: SOAP Body

<SOAP-ENV:Body>

<m:AddTreatment xmlns:a=http://localhost/TreatmentAdmin>

<treatment> <patient insurer=“1577500” nr=‘7503100815’/> <doctor city=“SB” nr=‘4321’/>

<service> <mkey>1234-A</mkey> <date>2001-01-30</date> <diagnosis>No complications. </diagnosis> </service>

</treatment>

</SOAP-ENV:Body>

XML Data


SOAP Interaction Protocol

Network

Messaging

HTTP, FTP, IIOP, MQ...

SOAP

ApproachComponents ofWeb Services

XML Message DescriptionExists

Exists

Exists

+ W3C Recommendation (standard) + Implements RPC

- Untyped user data, types to encode in the message- Interpretation of SOAP messages required- High overhead / low performance- Ongoing standardizations



The Interface Concept of Web Services


Service Interface

Web ServiceOperation

Interface

XML input / output

Web Services Description Language (WSDL)defines a web service's interface * to describe a service for its clients * to describe a standard service for WS implementors


WSDL Interfaces

WSDL Ports

describe input and output messages

A WSDL Interface is a set of ports

Functions with types of parameter and results in XML Schema Event ports

Port types and their operations:

Event or message based:

Notification: data-out port.

One-way: data-in port.

Call-based

Request-Response: receive, then reply (callee port)

Solicit-Response: send, then receive (caller port)

Interface

Port

out-port

in-port


WDSL Specification Structure Types

In XML schema or another typing language

Messages The data that is communicated

Port types and Operations An interface of the service,

grouping sets of messages into operations,with input, output, fault parameters

Binding A mapping of the port to underlying

messaging layer, e.g., HTTP, SOAP, or MIME

Service

A set of related ports, with service name and location

<wsdl:definitions xmlns:wsdl = “http://w3.org/...”> <wsdl:documentation ... /> <wsdl:types> Schema imports </wsdl:types> <wsdl:message> Messages </wsdl:message> <wsdl:portType> Operations </wsdl:portType> <wsdl:binding> ProtocolsFormats </wsdl:binding> <wsdl:service> Service definition </wsdl:service></wsdl:definitions>


WSDL Interface, Message Types(XSD Types)

<wsdl:types><XMLSchema:schema … [target name space definitions]>

<XMLSchema:element name=“addTreatment”> <XMLSchema:complextype>

<XMLSchema:sequence><s:element minOccurs="1"

maxOccurs="1" name="parameter"nillable="true"

type="a:treatment"/></XMLSchema:sequence>

</XMLSchema:complextype></XMLSchema:element> <XMLSchema:element name=“addTreatmentResponse”>

<XMLSchema:complextype><XMLSchema:sequence>

<s:element minOccurs="1" maxOccurs="1" name=“result"

nillable="true" type="XMLSchema:bool"/>

</XMLSchema:sequence></XMLSchema:complextype>

</XMLSchema:element> <XMLSchema:complextype name=‘treatment’> … </XMLSchema:complextype>

</XMLSchema:schema><wsdl:types>


Example (cont.): WSDL Interface Definition

<wsdl:definitions [name space definitions]><wsdl:types> … </wsdl:types><wsdl:message name=“addTreatmentSOAPIn”>

<part name=“parameters” element=“addTreatment”/> </wsdl:message> <wsdl:message name=“addTreatmentSOAPOut”> <part name=“parameters” element=“addTreatmentResponse”/> </wsdl:message> <wsdl:porttype name=“TreatmentAdminSOAP“> <wsdl:operation name=“addTreatment“> <wsdl:input message=“addTreatmentSoapIn“/> <wsdl:output message=“addTreatmentSoapOut“/> </wsdl:operation> </wsdl:porttype> <binding [binding to SOAP / HTTP Protocols] …> <wsdl:service name=”TreatmentAdminSOAP”> ... <wsdl:port binding=”...” name=”...”> <soap:address location=”http://localhost:8080/soap/servlet/rpcrouter”/> </wsdl:port></wsdl:definitions>

Actual interface


Binding

<wsdl:binding name=”livetoken” type=”Token”><soap:binding style=”document”

transport=”http://schemas.xmlsoap.org/soap/http”/> <operation name=”GetLastPrice”>

<soap:operation soapAction=”http://www.stocktrade.com/GetPrice”/>

<input> <soap:body use=”literal”> </input> <output> <soap:body use=”literal”> </output>

</operation><wsdl:binding>

Binding maps WSDL messages (as defined in portType) to a messaging layer:

• encoding (e.g. SOAP, RPC) and• protocol (e.g. HTTP, SMTP, FTP)

SOAP messageswill be bound to

HTTP


WSDL Advantages

WSDL abstracts from underlying

Protocol

Binding to HTTP, SOAP, MIME, IIOP, etc.

Component model Mappings to CORBA, EJB, DCOM, .NET

are available

Advantages:

Contrary to all component models seen so far, WSDL unifies call and event ports

And abstracts from the underlying component model, introducing the component model as a secret


WSDL Service Interface

Network

Messaging

Service Description

HTTP, FTP, IIOP,...

SOAP

WSDL


XML Message Description

Exists

Exists

Exists

Exists

Approach

+ W3C Standard (WSDL 2.0 May 2007, www.w3.org/TR/2007)+ Imitates Interface Definition Languages e.g. CORBA IDL+ Part of BPEL (see later)- No inheritance on WSDL- Not recursively composable


Web service catalogization and discovery

UDDI Server

Web ServiceProvider Client

“register myweb service for XY”

“Where is a webservice for XY?”


Offer and Find Web Services

Standardized registry, publishing, advertisement …

Extended name server, describing interface and properties

XML Descriptor White Page: Address Yellow Page: Semantics (based on standard taxonomy) Green Page: Technical specification of service

Logically central, physically distributed data base

A web service itself

Universal Description, Discovery and Integration (UDDI)


UDDI

WhitePage

Registered (and other) namesService DescriptionContact person (name, e-mails, …)Telephone/fax numberWeb site…

YellowPages

Service categoryType of industryType av products/servicesGeographic localization…

GreenPages

Offered service (WSDL interfaces)Documentation, descriptionPrinciples cooperation realization…

WSDL

WSDL


UDDI, WSDL, and SOAP in a Web Service Interaction

UDDIRegistry

Client

WSDLDocument

Web Service

1. Client queries registry to locate service

2. Registry refers client to WSDL document

3. Client accesses WSDL document

4. WSDL document provides metadata to interact with Web service

5. Client sends SOAP message request

6. Web service returns SOAP message response

1 43

6

5

2

2


UDDI, coming features

Current OASIS standard is UDDI v3.02 (2005, working group closed 2010)www.uddi.org


Offer and Find Services

Network

Messaging

Service Description

Service Publication

Service Discovery

HTTP, FTP, IIOP,...

SOAP

WSDL

UDDI

UDDI



Exists

Exists

Exists

Exists

??

??

Approach

- Required and approached. UDDI v.3 (2003) by OASIS UDDI TC

- made part of the Web Services Interoperability consortium (WS-I)

- Public registries for test existed until 2006.

- Microsoft has abandoned UDDI in favor of BizTalk.



Business Processes on the Web with BPEL

BPEL = WS-BPEL = BPEL4WS = Business Process Execution Language

for Web Services


Business Process

Business Process

How to define a business process on the web?There are many languages proposed today:

WSFL, WSCL, WSCI, XLANG, WSEL, UML2, WSUI, WSXL, BPML, BPMN, …

IBM & Microsoft: BPEL, BPEL4WS, WS-BPELOASIS: WS BPEL www.oasis-open.org

WS-BPEL 2.0 Jan. 2007

(common task)


Ingredients...

BPEL is an architectural language for web services

Based on workflow languages

Orchestration of business processes

Invoke web services

Mixing control and data flow operators

BPEL is a composition language

Composing new web services from existing ones, using their ports

Relying on messages (events) and calls

BPEL builds on WSDL

For service interface descriptions

BPEL adds connections (partner link types)


Side Stepping: Which Operational Specifications Exist?

Data flow graphs

Data flows through operations

Activity diagrams: data flows through actions

Control-flow graphs

Nodes are control-flow operations that start other operations on a state

Mixed approaches

Program dependence graph; Static-single-assignment graphs, SSA

Cycles are marked by phi-nodes that contain control-flow guards

Statecharts: Events trigger state transitions

Petri nets, UML2 activity diagrams: tokens mark control and data-flow

Workflow languages: mix control and data-flow, similar to activity diagr.


Background: UML Activity Diagrams

Based on Petri Nets

Dual to State Machines

In UML 2.0


Workflow Languages

A workflow language specifies control and data flow over a set of operations

The operations need not be executed automatically, but can be performed by humans

The workflow allows concurrency, because it must model the business process of a company

Workflows are closely related to Colored Petri Nets and dual to statecharts

Examples:

ARIS system for SAP [IDS Scheer, Saarbrücken]

FlowMark [IBM]

Lotus Domino [IBM]

YAWL [van der Aalst, Eindhoven]: based on Colored Petri Nets

UML2 Activity Diagrams


Typical Operations in Workflow Languages

AND-split: all

XOR-split: 1 of n

OR-split: m of n

AND-join: all of n

XOR-join: 1 of n

OR-join: m of n

Example:

AND-split

Example:

AND-join

Token

Activity


Workflow Engines

Workflow engines are interpreters of workflows

They manage the concurrency in a workflow and synchronize all processes

Usually, they also support interactive applications

Undo

Transactions with rollback and commit

Compensation (in case of error)

They are, for web services and component systems, composition engines that execute a composition program


BPEL Made Simple

BPEL is an activity-diagram like language,

with concurrency and transactions

with different kind of join and split operators

with ports and connections

BPEL can be edited graphically, and has an XML abstract syntax

Creating a web service becomes a similar activity to editing an UML activity diagram


BPEL Specification Structure

Process definition

Header with namespace declarations

Variables: global variables of the process PartnerLink declarations: interface declaration

with whom is the process connected?

Partners: actual partners of the communication Correlation sets:

Which instance of a process is talking to which other instance?

Fault handler: What happens in the case of an exception? Compensation handler: compensation actions Event handler: what happens in case of a certain event? A (structured) main operation: e.g., sequence or flow


WSDL Definitions as a Basis

BPEL uses WSDL definitions to define types, message types, and port typesWSDL definitions can be without binding

Bindings can be added when the BPEL process is deployed– Statically / at deployment time / dynamically (lookup) /

dynamically (callback)That increases reuse of the process

This achieves component model transparency (independence of the underlying component model)

BPEL adds partner link types (connector types)which are typed connections

A Simple Pizza Order in BPEL

<process name=”OrderPizza” suppressJoinFailure=”yes”

xmlns=”http://schema.xmlsoap.org/ws/2003/03/business-process”pns=”http://www.pizza.org/schema”>

<partnerLinks>

<partnerLink name=”PizzaService” partnerLinkType=”pns:OrderChannel”myRole=”PizzaOrderer”>

</partnerLinks>



<variables>

<variable name=”input” messageType=”PizzaOrder”/>

<variable name=”output” messageType=”PizzaDelivery”/>

</variables>

<faultHandlers> ... </faultHandlers>

<sequence name=”body”>

<invoke name=”order” partnerLink=”PizzaService” portType=”PizzaOrderPort“operation=”body” variable=”output”>

<receive name=”acknowledgement” partnerLink=”PizzaService” portType=”PizzaServicePort“operation=”body” variable=”input”>

</sequence>

</process>

Connector


Partner links

Process”OrderPizza”

PartnerLink”PizzaOrder”

PLType=”OrderChannel”myRole=”PizzaOrderer”

partnerLinkType ”OrderChannel”

Role ”PizzaOrderer”

Role ”PizzaService”

Process”DeliverPizza”

PartnerLink”PizzaOrder”

PLType=”OrderChannel”myRole=”PizzaService”

portType ”PizzaOrderPort”

portType ”PizzaServicePort”

Operation ”order”

Operation ”acknowledgement”

invoke

invoke

receive

receive

WSDL WSDL

BPEL BPEL

BPEL composes services in abstract services at the port type level, not at the port/instance level. To execute, we must bind each partnerLink along which a partner is invoked to a concrete endpoint.

sequence

Figure partly adapted from S. Weerawarana et al.: Web Services Platform Architecture, 2005.


Flow Operations are Workflow Graphs

The <flow> operation is structured as a workflow graph

The names of messages, ports, partner links help to span up the graph

<flow> executes its sequences in parallel

<links> denote dependences between tasks

<flow>

<links><link name=”A”> </link>

<link name=”B”> </link>

</links>

<sequence>..<invoke> <source name=”A”>..</sequence>

<sequence>....<target name =”B”>...........</sequence>

</flow>

A

B


Other BPEL Operations

Primitive activities

invoke... a WSDL-described operation

receive – wait for message

wait ... for some time

assign – copy data from one data container to another

reply... to external source

throw... an exception

Structured control-flow(can be nested)

sequence – serial composition

switch

while

flow – parallel composition

pick (XOR join) – nondet. choice

terminate

scope – group activities for common exception handler


BPEL Tools

Oracle BPEL Process Manager (formerly Collaxa designer) www.oracle.com

BPMN graphical frontend modeling language for BPEL Looks similar to UML2 Activity Diagram notation

(more symbols for transactions, specific events, …) Tools: Orchestra designer (open source, Eclipse plugin), IBM

WebSphere Studio, … www.omg.org/docs/formal/08-01-17.pdf

People work on the translation of Colored Petri Nets and UML activity diagrams from and to BPEL Colored Petri Nets have good formal features

and can be used for deadlock checking, etc. E.g., YAWL [van der Aalst]


BPMN

Business Process Modeling Notation [OMG 2006] www.bpmn.org

UML Activity diagram like modeling language for business processes

Based on Petri Nets

Nodes 1: Activities, Events, Gateways (branch/fork/join)

Nodes 2: Data objects (e.g. messages), Start state, End state, …

Edges: Sequence (control flow), Message flow, Association

Grouping/Scoping: Swimlanes, Group

Zoom-in/-out to subprocess view

Special support for transactions, undo, exception flow, …

De-facto standard for process modeling

Good tool support

Too few ”service interaction patterns” pre-defined needs extensions

Not entirely equivalent to BPEL


BPMN ExampleO

RD

ER

PIZ

ZA

PIZ

ZA

-SE

RV

ICE

PlacePizzaRequest

PlaceInvoiceRequest

+

+

SendInvoice

SendPizza

Order +

Receive Invoice

Receive Pizza

PIZ

ZA

BA

KE

RP

AY

ME

NT

OR

G.

+

Figure adapted from G. Decker: Choreografiemodellierung – Eine Übersicht, Informatik Spektrum 31(2), April 2008


Model Verification

Check for structural incompatibilitye.g., mismatch in message types

Check for behavioral incompatibilitye.g., deadlock risk

Deadlockexample: Transfer

money

Sendpizza

PIZ

ZA

BA

KE

RP

AY

ME

NT

OR

G

I do not send the pizza before the

money has arrived

I do not pay for the pizza before it has been sent

to the pizza orderer


Business Process

Network

Messaging

Service Description

Service Publication

Service Discovery

HTTP, FTP, IIOP,...

SOAP

WSDL

UDDI

UDDI



WorkflowWSCIBPEL BPMN

Exists

Exists

Exists

Exists

??

??

Evolution

Approach


Trust and Security

Integrity: intact, unchanged Confidentiality: encryption policyAuthentication: proof of identity Authorization: access to execute certain servicesNon-Repudiation: warranty on failure Legal Rights: copyrights, reselling rights, ...Privacy: handling personal data ...


Trust and Security

Network

Messaging

Service Description

Service Publication

Service Discovery

Work Flow

Secu

rit y

HTTP, FTP, IIOP,...

SOAP

WSDL

UDDI

UDDI



Exists

Exists

Exists

Exists

??

??

Converging

Exists

WSCIBPEL BPMN

WS-Security

OASIS standard (2003, 2006) v1.1


Technical Conclusion

WS-Security

HTTP, FTP, IIOP,...

SOAP

WSDL

UDDI

UDDI

XML

WSCIBPEL BPMN

Defined with XML

Web Services minimum


Limitations of Classical Component Systems

Different basic communication of the systems, CORBA components cannot talk directly with COM

components etc.Adaptation on technical level necessary

Not full remote transparencyDependence on the component model


Web Services – Component Model Transparency

Language adaptation: XML Schema + WSDL Location transparency: SOAP (+ HTTP) Component model transparency (EJB, COM+, CCM, ...)

ServerC++

LocalClient

C

COM+CCM

SOAP (HTTP) Remote

SOAP (HTTP) Local

RemoteClientJava

EJB

WSDLWSDLWSDL



Web Services and Java


Java and Web Services

Java offers APIs and tools for manipulating XML files and for generating SOAP messages to interface with web services

JAXP, JAXB, JAXRPC, JAXM, JAXR, ...

Technical requirements:

Java JDK

Apache Axis (plug-in for Tomcat application server)

Framework for constructing SOAP processors for clients and servers

Generation of WSDL via a Java API (or automatic creation from class file)

Generation of Java stubs and skeletons from WSDL (or using POJO)

Tomcat application server tomcat.apache.org

Apache HTTP server httpd.apache.org


Java and Web Services

Necessary Java APIs: JAXP (XML processing), JAXB (XML binding), JAX-RPC (XML-based RPC), JAXM (XML messaging), JAXR (XML registries)



Evaluation of Web Services

as composition system


Component Model

Mechanisms for secrets and transparency: very good

Location, language, component model transparency

Communication protocol transparency

Generic BPEL Web Services (without bound WSDL ports)


Composition Technique

Mechanisms for connection

Protocol transparency allows for flexible connections

WSDL binding is flexible

Mechanisms for aspect separation

Mechanisms for Meta-modeling

Used

Scalability: Better

Changes of protocol possible

Changes of distribution easy

Changes of workflow easy


Composition Language

BPEL workflows are a nice composition language

Not yet full exchangeability of connector types

But graphic support for workflow specifications

Metacomposition is possible...

The generation of a BPEL script is easy, because it is XML based

BPMN modeling language as frontend to BPEL

Environments such as Oracle/Collaxa BPEL server will generate workflow from other specifications

Generic workflow architectures will be possible


Web Services as Composition Systems

Component Model Composition Technique

Composition Language

Contents: Completely hidden

Binding points: WSDL ports

Adaptation: well supported

Automatic transactions, recovery

Several types of connectors

BPEL is a workflow language for orchestrating web services

Implicit connectors for architecture


Classical Component Systems

Architecture Systems

Aspect Systems View Systems

Darwin SkeletonsCoSy Web Services BPEL

Aspect/J Invasive CompositionStatic Metaprogramming

Standard Components

Architecture as Aspect

Aspect Separation CompositionOperators Composition

Language

Object-Oriented Systems C++ JavaObjects asRun-Time Components

Modular Systems Modula Ada-85Modules as Compile-Time Components

SOP

SoftwareComposition Systems

.NET CORBABeans EJB COM

Wrap-upThe Ladder of Component and Composition Systems

Web services (excl. BPEL) Global Interoperability

web services - idatddd05/lectures/slides/f08-web-services.pdf · uddi, wsdl, and soap in a web...

Documents