Upload
ngotram
View
221
Download
3
Embed Size (px)
Citation preview
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
SOC'12 @ Sokendai 3Fuyuki Ishikawa
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]
SOC'12 @ Sokendai 5Fuyuki Ishikawa
(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
SOC'12 @ Sokendai 6Fuyuki Ishikawa
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.)
SOC'12 @ Sokendai 9Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 10Fuyuki Ishikawa
Web Service Standards: Others (WS-*)
Web Service Foundations OverviewMessage Exchange
SOAPRESTJSON
WSDL(UDDI)
TOC
11Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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)
SOC'12 @ Sokendai Fuyuki Ishikawa
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)
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 17Fuyuki Ishikawa
SOAP: Opinions
Web Service Foundations OverviewMessage Exchange
SOAPRESTJSON
WSDL(UDDI)
TOC
18Fuyuki IshikawaSOC'12 @ Sokendai
“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?
SOC'12 @ Sokendai 19Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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)
SOC'12 @ Sokendai Fuyuki Ishikawa
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
“Genuine” REST Architecture (2)
SOC'12 @ Sokendai Fuyuki Ishikawa
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
“Genuine” REST Architecture (3)
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
"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
SOC'12 @ Sokendai 25Fuyuki Ishikawa
Use of REST/RESTful Services
Web Service Foundations OverviewMessage Exchange
SOAPRESTJSON
WSDL(UDDI)
TOC
26Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 27Fuyuki Ishikawa
JSON
{"name": “Fuyuki Ishikawa", "age": 32}
[“Japan", “France", “USA"]
Web Service Foundations OverviewMessage Exchange
SOAPRESTJSON
WSDL(UDDI)
TOC
28Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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)
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai 33Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 34Fuyuki Ishikawa
WSDL: Limitations
Web Service Foundations OverviewMessage Exchange
SOAPRESTJSON
WSDL(UDDI)
TOC
35Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
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
SOC'12 @ Sokendai Fuyuki Ishikawa
May 16Web Service Composition(Orchestration and Choreography)
WS-BPELWS-CDL
39Fuyuki Ishikawa
Next
SOC'12 @ Sokendai