lecture course service-oriented computing 4: web...

Fuyuki Ishikawa （石川冬樹）[email protected]

Lecture CourseService-Oriented Computing

4: Web Services: Foundations2012/05/09

1 Introduction

2 Basics: Distributed Objects

3 Basics: XML

4 Web Services: Foundations

5 Web Services: Composition

6 Web Services: Implementation

7 Related Topics (1): Reliability

SOC'12 @ Sokendai 2Fuyuki Ishikawa

Course Plan

8 Related Topics (2): Security

9 Related Topics (3): Engineering

10 Related Topics (4): Semantic Web

11 Cloud Computing (1): Overview

12 Cloud Computing (2): Experience

13 Discussion and Summary

14 Students’ Presentation


Course Plan

Web Service Foundations OverviewMessage Exchange

SOAPRESTJSON

WSDL(UDDI)

TOC

4Fuyuki IshikawaSOC'12 @ Sokendai

A Web service is a software applicationidentified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifactsand supports direct interactions with other software applications using XML based messages via internet-based protocols

[W3C, 2002]


(Review) Web Services?

Infrastructures for distributed objectsAims at interoperability among objects based on different environments (platforms and languages)Implemented by common network formats and translation mechanisms in ORB for each environment

Some criticisms when compared with the Web (which became widespread at that time)

Different mechanisms existed and were not connected, such as CORBA, DCOM and Java RMIFirewall configuration was difficult due to dynamic port mapping mechanisms


Previous Issues in Distributed Objects

Popularity of XML as platform-independent data formats on the Web

XML 1.0 (W3C Recommendation in 1998)XHTML 1.0 (W3C Recommendation in 2000)MathML 1.01(W3C Recommendation in 1999)…

Use of XML for messaging formats between distributed objects

XML-RPC (Userland and Microsoft, 1998)SOAP (a widespread standard ver. 1.1 in 2000)

Movement

7SOC'12 @ Sokendai Fuyuki Ishikawa

8

XML-RPC<methodCall><methodName>examples.getStateName

</methodName><params><param><value><i4>41</i4></value></param>

</params></methodCall>

<methodResponse><params><param><value><string>South Dakota</string></value>

</param></params>

</methodResponse>

SOC'12 @ Sokendai Fuyuki Ishikawa

What are necessary for interoperability(given the previous discussion on distributed objects)

Messaging exchange SOAP REST JSONContent for operation invocation (arguments)Message meta data (e.g., sender)

IDL (Interface Definition Language) WSDLOperation name, arguments/return types, …

Registry UDDI (?)Access to service information (access, provider, etc.)


Web Service Standards: Foundations

What are necessary for further quality assuranceWS-BPEL, WS-CDL, WS-Coordination, WS-Notification, WS-Addressing, WS-Policy, WS-Discovery, WS-Resource Framework, WS-Security, …

Part of them will be discussed in this courseTo review principles in web services and those in distributed computing(not necessarily mean the standards are popular in the world or absolutely useful for your activities)


Web Service Standards: Others (WS-*)


SOAPRESTJSON

WSDL(UDDI)

TOC


SOAPFormerly: Simple Object Access ProtocolCurrently (since ver. 1.2): abbreviation of nothing)A standard for messaging formats

Defines an "envelop" for XML messages: Header including meta information (routing, security, etc.) and Body including the message contentOften used for RPC-style interaction (request and response), though not limit its usage to RPCIndependent of underlying network protocols (HTTP, SMTP, etc.), though HTTP is used in most cases

SOAP: Overview

12SOC'12 @ Sokendai Fuyuki Ishikawa

HistoryXML-RPC (Userland and Microsoft, 1998)SOAP 0.9/1.0 in 1999 (submitted to IETF)

Supports only HTTPSOAP 1.1 in 2000 (W3C Note)

Involves IBM and Lotus, sumitted to W3CSOAP 1.2 in 2003 (W3C Recommendation)

Stopped to be an abbreviation for Simple Object Access Protocol, intending generalization(e.g., not “client/server” but “sender/receiver”)Includes many improvements

13

SOAP: Overview


SOAP: Involved Definitions

Envelop

Header

getStockInfocompanyName

...

Body

Routing info mustUnderstand="false"…

Security info mustUnderstand="true"…

14

Defines a place to put various information about message delivery controls(actual contents are defined in other protocols)

Message content for the final recipient

(actually in XML)


1. A general message to send a reservation request in a conversation style

2. An RPC request for reservation (the operation name is a child of the Body element)

3. RPC response1. The return value is explicitly specified2. The return value is not explicitly specified (void)

4. RPC response that notifies a fault1. Fault due to an argument error2. Fault due to an unknown header element that

must be understood

15

SOAP: Example (in Appendix)


Basic models defined in SOAPMessage structure: Envelope, Header, and BodyAttributes in header elements

mustUnderstand : if true: the receiver must handle the header element in the defined way, or otherwise throw a faultrole : intended target that handles the header element (none, next, ultimateReceiver, …)relay : if true, the header element must be relayed if it is not processed

Protocol bindings (e.g., to HTTP)

16

SOAP: Involved Definitions


SOAP is designed to be a general, foundational messaging protocol

Communication patterns (P2P, MANET, multicast, content-based routing, …)Control mechanisms(transaction, reliability, security, …)

Many web developers do not need or like such a “heavy” approach

General and flexible, but too redundant and heavy for the typical needs in web applications

(while enterprise developers tend to need)


SOAP: Opinions


SOAPRESTJSON

WSDL(UDDI)

TOC


“REST/RESTful services” sometimes refer to services not based on SOAP (or the RPC style)

Uses HTTP commands (get, post, etc.)Similar to web applications but use XML (not HTML) for inputs and outputs??

Lightweight (adhoc) alternative?What were meanings of GET, POST, … in HTTP?What were good properties of HTTP?


REST/RESTful Services ???

"HTTP GET /addUser?name=ishikawa "

"SOAP-RPC/HTTP getUser(ishikawa)“instead of

REST: Representational State Transfer[Ph.D. Thesis in 2000, by Roy T. Fielding](one of the contributors to the HTTP specification and the apache software)Defines a set of architectural principles

Client-serverStatelessCacheableUniform interfaceLayered systemCode-on-demand (optional)

20

“Genuine” REST Architecture


REST principles and their advantagesClient-server: separation of user interface concerns and data storage concernsPortability of the user interfaceScalability (simplicity) of the server componentsStateless: inclusion of all the information required to understand a request in the request Visibility in requests (easier monitoring)Reliability and scalability at the server side, without necessity to manage states between requests

21

“Genuine” REST Architecture (1)


REST principles and their advantages (Cont’d)Cacheable: clear distinction between cacheable and non-cacheableEfficiency and scalability when cache can be used in the case the same response is given to the same requestUniform Interface: uniform interface between componentsSimplicity and visibility of interactions as well as separation between interface and implementations

22



REST principles and their advantages (Cont’d)Layered System: hierarchical structures to hide unnecessary details on some layer to the othersLess complexity of the whole system and less dependency between subsystemsCode-On-Demand: on-demand loading of required functionalities onto the client sideRuntime extensibility

23



Not RESTful or well-designed with HTTP

(can see cacheable or not? what does “GET” mean?)RESTful

Resource-based design (URLs are nouns, not verbs)CRUD (Create, Read, Update, Delete)HTTP Command (POST, GET, PUT, DELETE)

24

REST/RESTful Services


"HTTP GET /addUser?name=ishikawa "

“HTTP POST /users<?xml><user><name>ishikawa</name></user>”

“HTTP GET /users/ishikawa”

Many web companies recommend use of REST services, not SOAP

Google, Facebook, etc.Each service available on the web has each design

Respecting the REST architectureActually applying some of the principles


Use of REST/RESTful Services


SOAPRESTJSON

WSDL(UDDI)

TOC


JSON: JavaScript Object NotationData description (rather than message) for lightweight usages (RFC 4627)Subset of JavaScriptEasy usages

Passed to the eval function in JavaScript (Ajax)Supported in many other languagesHuman readable


JSON

{"name": “Fuyuki Ishikawa", "age": 32}

[“Japan", “France", “USA"]


SOAPRESTJSON

WSDL(UDDI)

TOC


WSDL: Web Services Description Language(W-S-D-L or sometimes like "wizdl")

A standard for description of service interface and binding

Plays the role of IDL (as in CORBA)Also provides binding information

29

WSDL: Overview


HistoryVer. 1.0 in 2000

Combination of SCL/SDL by Microsoft and NASSL by IBM (and so on)

Ver. 1.1 in 2001 (W3C Note)Ver. 2.0 in 2007 (W3C Recommendation)

Full support for SOAP and HTTPImport and inheritance of interface definition

30

WSDL: History


31

WSDL: Involved Definitions

types: definition of involved data types(using XML Schema)

interface: definition of an interface(a set of provided operations)

service: definition of endpoints(typically IP address and port number)

binding: definition of access protocols(e.g., SOAP/HTTP)

abstractconcrete

An abstract interface can be commonly used for different service providers or implementations

Multiple endpoints can be defined for one type of binding (e.g., duplicated service endpoints)


A set of the definitions for a hotel reservation serviceOther standards involved (with different namespaces): XML Schema, SOAP Envelop, SOAP binding, WSDL extensionNotes

A MEP (message exchange pattern) of an operation: next slideA style of an operation: encoding of the (SOAP) body element (e.g., RPC or document style)A safe operation: an operation without side effects

32

WSDL: Example in Appendix


Message exchange patterns define a possible sequence of messages in an operation invocation

Standard patterns: in-only, robust-in-only, in-out

(“robust” means every message may cause a fault message to the opposite direction)Additional standard patterns: in-optional-out, out-only, robust-out-only, out-in, out-optional-inAny custom pattern definitions


WSDL: MEP

Label: IN

Label: OUT

input

output

WSDL does not help understanding onRelationships of operations (or protocols)

e.g., the login operation must be first invoked before one or more addToCart operation(s), before the checkOut operation

Semantics of operationse.g., the register operation causes addition of the input data on the server side

(complementary specifications for each aspect will be discussed later)


WSDL: Limitations


SOAPRESTJSON

WSDL(UDDI)

TOC


Universal Description, Discovery and IntegrationA standard for registries

Data structures for general description of servicesWhite pages: address, contact, etc.Yellow pages: industrial categorizationsGreen pages: technical information

(e.g., refer to WSDL descriptions) API for registry operations (register, unregister, etc.)Synchronization mechanisms of multiple registries

36

UDDI: Overview


businessEntity: information about the party who publishes information about a servicebusinessService: descriptive information about a particular family of technical servicesbindingTemplate: technical information about a service entry point and implementation specstModel: descriptions of specifications for services or value sets, basis for technical fingerprints

37

UDDI: Involved Definitions


HistoryVer. 1.0 in 2000Operation of global UDDI registries started by IBM, Microsoft, Ariba (, NTT Communications, …)OASIS Standard Draft (UDDI ver. 3) in 2004

Operation of global UDDI registries were closed around 2007 …

Popular application servers include their own implementations for private registries

38

UDDI: History


May 16Web Service Composition(Orchestration and Choreography)

WS-BPELWS-CDL

39Fuyuki Ishikawa

Next

SOC'12 @ Sokendai

lecture course service-oriented computing 4: web...

Documents