Lecture 19: Web Services

?

CMSC 23300/33300

Computer Networks

http://dsl.cs.uchicago.edu/Courses/CMSC33300

2

Today’s Web

Web designed for application to human interactions Served very well its purpose:

Information sharing: a distributed content library Enabled B2C e-commerce Non-automated B2B interactions

How did it happen? Built on very few standards: HTTP + HTML Shallow interaction model: very few assumptions made

about computing platforms Result: ubiquity

3

What’s next?

The Web is everywhere. There is a lot more we can do! E-marketplaces. Open, automated B2B e-commerce. Business process integration on the Web. Resource sharing, distributed computing.

Current approach is ad-hoc on top of existing standards. E.g., application-to-application interactions with HTML

forms. Goal: enable systematic application-to-application

interaction on the Web

4

Web Services

“Web services” is an effort to build a distributed computing platform for the Web

Yet another one!

5

Designing Web Services Goals

Enable universal interoperability Widespread adoption, ubiquity: fast! Enable (Internet scale) dynamic binding

Support a service oriented architecture (SOA) Efficiently support both open (Web) and more constrained

environments

Requirements Based on standards. Pervasive support is critical Minimal amount of required infrastructure is assumed

Only a minimal set of standards must be implemented Very low level of application integration is expected

But may be increased in a flexible way Focuses on messages and documents, not on APIs

6

Web Services Model

Web service applications are encapsulated, loosely coupled Web “components” that can bind dynamically to each other

7

Service Oriented Architecture & Web Services

SOAFlexible

Locate services on any server Relocate as necessary Prospective clients find services using

registriesScalable

Add & remove services as demand varies

Replaceable Update implementations without

disruption to users Fault-tolerant

On failure, clients query registry for alternate services

SOAFlexible

Locate services on any server Relocate as necessary Prospective clients find services using

registriesScalable

Add & remove services as demand varies

Replaceable Update implementations without

disruption to users Fault-tolerant

On failure, clients query registry for alternate services

Web Services Interoperable

Growing number of industry standards Strong industry support Reduce time-to-value

Harness robust development tools for Web services

Decrease learning & implementation time

Embrace and extend Leverage effort in developing and

driving consensus on standards Focus limited resources on

augmenting & adding standards as needed

Web Services Interoperable

Growing number of industry standards Strong industry support Reduce time-to-value

Harness robust development tools for Web services

Decrease learning & implementation time

Embrace and extend Leverage effort in developing and

driving consensus on standards Focus limited resources on

augmenting & adding standards as needed

8

Web Services Framework

Framework can be described in terms of

What goes “on the wire”: Formats and protocols

What describes what goes on the wire:Description languages

What allows us to find these descriptions:Discovery of services

9

XML Messaging: SOAP

SOAP 1.1 defined: An XML envelope for XML messaging,

Headers + body An HTTP binding for SOAP messaging

SOAP is “transport independent”. A convention for doing RPC An XML serialization format for structured data

SOAP Attachments adds How to carry and reference data attachments using in a

MIME envelope and a SOAP envelope

10

The SOAP Envelope

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

< SOAP-ENV:Body> ... </ SOAP-ENV:Body> ...</ SOAP-ENV: Envelope>

11

What Goes on the Wire

Internet-scale integration needs a lingua-franca

XML messaging protocol over HTTP: SOAP

Intra-enterprise integration needs to allow alternates:

CORBA, RMI Messaging In-memory method calls

SOAP SOAP

SecuritySecurity

AttachmentsAttachments

ReliabilityReliability

RoutingRouting

TransactionsTransactions

ContextContext

W3C

12

Descriptions: Metadata

Integration requires interoperable machine-understandable descriptions

Enables dynamic, delayed binding of components.

Language extensibility provides support for different levels of application integration. InterfaceInterface

Service QoS Service QoS

ServiceService

Public FlowsPublic Flows

Flows and Composition

Flows and Composition

AgreementsAgreements

WS

DL

WS

FL

XML SchemaXML Schema

13

Web Services Description Language

Provides functional description of network services: IDL description Protocol and deployment details Platform independent description Extensible language.

A short history: WSDL v1.0, 9/2000 WSDL v1.1 submitted to W3C 3/2001 WSDL v2.0 candidate recommendation 3/2006 A de facto industry standard

14

WSDL Structure

portType Abstract definition of a

service (set of operations)

Multiple bindings per portType:

How to access it SOAP, JMS, direct call

Ports Where to access it

Service

Port(e.g. http://host/svc)

Binding(e.g. SOAP)

Abstract interface

portType

operation(s)

inMesage outMessage

Port

Binding

15

Using WSDL

As extended IDL: WSDL allows tools to generate compatible client and server stubs Tool support for top-down, bottom-up and “meet in the

middle” development Allows industries to define standardized service

interfaces Allows advertisement of service descriptions, enables

dynamic discovery and binding of compatible services Used in conjunction with UDDI registry

Provides a normalized description of heterogeneous applications

16

Client Proxy object

RMI-IIOP

JMS/MQ

SOAP/HTTP

Client invocation

Single stub can invoke services over different bindings Depends only on abstract interface.

Are independent of binding (but pluggable). Add new bindings without recompiling/redeploying stub

Allows optimisations based on the bindings of service

Will support extended services models if described in WSDL

17

Discovery: Finding Metadata

Static binding requires service “libraries”

Dynamic binding requires runtime discovery of meta-data

InspectionInspection

DirectoryDirectory

ADS,DISCO

UDDI

18

Service Discovery: UDDI

UDDI defines the operation of a service registry: Data structures for registering

Businesses Technical specifications: tModel is a keyed reference to a

technical specification. Service and service endpoints: referencing the supported

tModels SOAP Access API Rules for the operation of a global registry

“private” UDDI nodes are likely to appear, though.

19

UDDI Relationships Web Service

Web Service

SIC CODENAICS

DUNS NumbersThomas Registry ID

Rosetta-NetBASDA

Simple.Buy

Schemas,Interchange specification

businessEntitybusinessEntitybusinessEntity

businessServicebusinessService

bindingTemplatebindingTemplateInstanceDetailsInstanceDetails

categoryBagkeyedReferencekeyedReference

identifierBagkeyedReferencekeyedReference

tModels

20

Web Services Security Standardsare slowly evolving (Jan ‘04)

proposedproposedSOAP FoundationSOAP Foundation

WS-SecurityWS-Security

WS-PolicyWS-Policy WS-TrustWS-Trust WS-PrivacyWS-Privacy

WS-SecureWS-SecureConversationConversation WS-AuthorizationWS-Authorization

In progressIn progress

promisedpromised

WS-FederationWS-Federation

21

Web Services Security Standsare slowly evolving (today)

proposedproposedSOAP FoundationSOAP Foundation

WS-SecurityWS-Security

WS-PolicyWS-Policy

WS-TrustWS-Trust WS-PrivacyWS-PrivacyWS-SecureWS-SecureConversationConversation

WS-AuthorizationWS-Authorization

In progressIn progress

promisedpromised

WS-FederationWS-Federation

SAMLSAML

XACMLXACML

EvolvingEvolving

22

GT4’s Use of Security Standards

Supported, Supported, Fastest, but slow but insecure so default

23

GT-XACML Integration

eXtensible Access Control Markup Language OASIS standard, open source implementations

XACML: sophisticated policy language Globus Toolkit ships with XACML runtime

Included in every client and server built on GT Turned-on through configuration

… that can be called transparently from runtime and/or explicitly from application …

… and we use the XACML-”model” for our Authz Processing Framework

24

GT Authorization Framework

25

GT Authorization Framework

VOMS Shibboleth LDAP PERMIS…

GT4 ClientGT4 Server

PDP

AttributesAuthorization

Decision

PIP PIP PIP

26

Resource ManagementInfrastructure

Web Services(WSDL, SOAP, WS-Security, WS-ReliableMessaging, …)

WS-Resource Framework & WS-Notification*(Resource identity, lifetime, inspection, subscription, …)

Data Access & Management Services (DAIS, RFT, DRS)Compute Access & Management Services (GRAM), etc.

Applications of the framework(Compute, network, storage provisioning,

job reservation & submission, data management,application service QoS, …)

*WS-Transfer, WS-Enumeration, WS-Eventing, WS-Management define similar functions

27

“Stateless” vs. “Stateful” Services

Without state, how does client: Determine what happened (success/failure)? Find out how many files completed? Receive updates when interesting events arise? Terminate a request?

Few useful services are truly “stateless”, but Web Services interfaces alone do not provide built-in support for state

Client

FileTransferService

move (A to B)move

28

File Transfer Service (without WS Resource Framework)

Developer reinvents wheel for each new service Custom management and identification of state: transferID Custom operations to inspect state synchronously

(whatHappen) and asynchronously (tellMeWhen) Custom lifetime operation (cancel)

Client

FileTransferService

move (A to B) : transferIDmove

statewhatHappen

tellMeWhen

cancel

29

WSRF in a Nutshell

Service State representation

Resource Resource Property

State identification Endpoint Reference

State Interfaces GetRP, QueryRPs,

GetMultipleRPs, SetRP Lifetime Interfaces

SetTerminationTime ImmediateDestruction

Notification Interfaces Subscribe Notify

ServiceGroups

RPs

Resource

ServiceGetRP

GetMultRPs

SetRP

QueryRPs

Subscribe

SetTermTime

Destroy

EPREPR

EPR

Modeling & Managing State in Distributed Sysems, Proceedings IEEE, 93(3), 2005

30

FileTransferService (w/ WSRF)

Developer specifies custom method to createResource and leaves the rest to WSRF standards:

State exposed as Resource + Resource Properties and identified by Endpoint Reference (EPR)

State inspected by standard interfaces (GetRP, QueryRPs) Lifetime management by standard interfaces (Destroy)

ClientFileTransferService

createResource (A to B) : EPRcreateResource

RPs

Transfer getRP

queryRPs

destroy

31

Data Transfer Comparison

Control

Data

Control

Data

Control

Data

Control

Data

globus-url-copy RFT Service

RFT Client

SOAP Messages

Notifications(Optional)

32

GRAMservices

GT4 Java Container

GRAMservices

Delegation

RFT FileTransfer

Transferrequest

GridFTPRemote storage element(s)

Localscheduler

Userjob

Compute element

GridFTP

sudo

GRAMadapter

FTPcontrol

Local job control

Delegate

FTP data

Cli

ent Job

functions

Delegate

Service host(s) and compute element(s)

GT4 WS GRAM Architecture

SEGJob events

33

Business Process Execution Language

Data Service@ uchicago.edu

Workflow script:

Fetch data fromdata service in Chicago

Perform step 1using service at Duke

Perform step 2using service at OSU

Analytic service@ osu.edu

Analytic service@ duke.edu

Researcher

WorkflowResults

34

Business Process Execution Language

Data Service@ uchicago.edu<BPEL

WorkflowDoc>

BPELEngine

Analytic service@ osu.edu

Analytic service@ duke.eduResearcher

Or Client App<WorkflowResults>

<WorkflowInputs>

Each workflow is also a service Enacted by BPEL Engine Typically runs like a script (synchronous) Other powerful models are possible

link

link

link

link

35

Basic BPEL Workflow Model

ReceiveInputs

Assignargs

Sendresults

Assignresults

InvokeService

AnalyticService

36

BPEL Workflow Model – Parallelism (flows)

ReceiveInputs

Assignresults

Assignargs

InvokeService

Assignargs

InvokeService

Assignargs

InvokeService

Sendresults

Assignresults

Assignargs

InvokeService

Assignargs

InvokeService

Assignargs

InvokeService

Assignresults

Assignargs

InvokeService

Assignargs

InvokeService

Assignargs

InvokeService

37

Example from caBIG Cancer Institute Grid

Data Service

10x

inte

rpo

late

rem

oveB

G

den

oise

alig

n

norm

aliz

e

Duke

inte

rpo

late

rem

oveB

G

den

oise

alig

n

norm

aliz

e

OSU

plot

Argonne

iterate

iterate

5x

5x

5x

5x

5x

5x

10x

10x

38

Workflow Document

</FOO>

39

CQL Query Passed to Workflow

<ns1:query xmlns:abpel-deser1="http://rproteomics.cagrid.nci.nih.gov/RPData" xmlns:ns1="http://rproteomics.cagrid.nci.nih.gov/RPData"> <query xmlns:ns5="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="scanFeatures_query2.xml"> <ns5:Target xmlns:ns6="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="edu.duke.cabig.scanFeatures.ScanFeatures"> <ns6:Objects xmlns:ns7="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="edu.duke.cabig.scanFeatures.Attributes"> <ns7:Objects/> <ns7:Group/> <ns7:Property xmlns:ns9="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL“ name="project" predicate="equal" value="WorkflowDemo"/> <ns7:Property xmlns:ns8="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="processingStep" predicate="equal" value="load"/> </ns6:Objects> </ns5:Target> </query></ns1:query>

40

BPEL Workfow Document Excerpt<receive createInstance="yes" operation="startWorkFlow“ partnerLink="WorkFlowClientPartnerLinkType“ portType="ns2:startWorkFlowPortType“ variable="workFlowInputMessage" /> <assign>

<copy>  <from expression=""1"" /> <to variable="indexCounterDuke" />   </copy> <copy>  <from part="parameters" query="/ns1:WorkFlowInputType/query" variable="workFlowInputMessage" />   <to part="parameters" query="/ns1:query" variable="queryInputMessage" />   </copy></assign>

<invoke inputVariable="queryInputMessage" operation="query“ outputVariable="queryOutputMessage" partnerLink="RproteomicsDataLinkType" portType="ns1:RPDataPortType" /> <assign> <copy>  <from expression="count(bpws:getVariableData('queryOutputMessage', 'parameters', '/ns1:queryResponse')/response/ns4:CQLQueryResult) div 2" />   <to variable="countDuke" />   </copy></assign>

41

BPEL Document – Iterate over a service call

<while condition="bpws:getVariableData('indexCounterDuke') <= bpws:getVariableData('countDuke')"> <sequence>

<assign> ... </assign>  <invoke inputVariable= "denoise_waveletUDWTWByValueInputMessageDuke" operation="denoise_waveletUDWTWByValue" outputVariable= "denoise_waveletUDWTWByValueOutputMessageDuke" partnerLink="DukeRproteomicsPartnerLinkType“ portType="ns3:RProteomicsPortType" /> <assign> ... </assign>  </sequence>

</while>

42

Specifications Landscape: April 2006SYSTEMSMANAGEMENT

UTILITYCOMPUTING

GRIDCOMPUTING

Core Services

Web ServicesFoundation WS-Addressing

Privacy

WS-BaseNotification

CIM/JSIM

WSRF-RAP

WSDM

WS-Security

Naming

OGSA-EMSOGSA Self Mgmt

GFD-C.16

GGF-UR

Data Model

HTTP(S)/SOAP

Discovery

SAML/XACML

WSDL

WSRF-RL

Trust

WS-DAI

VO Management

Information

Distributed query processing

ASP

Data CentreUse Cases &Applications Collaboration Multi MediaPersistent Archive

Data Transport

WSRF-RP

X.509

StandardEvolvingGapHole

43

Web Services Summary

Web Services are logically simple Standard mechanisms for describing, discovering, and

accessing services Encourage loose coupling; service-oriented architecture

Web Services are complex in practice Due to the wide variety of interactions that can occur

Broad adoption is encouraging. For more information

Web Services Architecture: http://www.w3.org/TR/ws-arch/