Service Oriented Architecture. 9. Web Services Darmstadt University of Applied Sciences, Department of Computer Science Dr. Markus Voß (Accso GmbH)

Transcription

1 SOA Service Oriented Architecture 9. Web Services Darmstadt University of Applied Sciences, Department of Computer Science Dr. Markus Voß (Accso GmbH)

2 Today s topic 1. Introduction 2. Business Architecture 3. Designing Domains 4. Designing Components 5. Designing Interfaces and Operations 6. Loose Coupling 7. Excursus: Business Information Systems 8. Integration 9. Web Services 10. Service Orchestration 11. Evolution of Application Landscapes 2

3 Agenda Overview Web Services SOAP WSDL UDDI REST 3

4 Technical Reference Architecture Web Services in the context of the enterprise architecture framework Business Geschäft Information System (IS) IT Technical Infrastructure (TI) Kontextuell Contextual (warum?) (why?) Konzeptionell Conceptual (what?) (was?) Logisch Logical (how?) (wie?) Physisch Physical (with (womit?) what?) Geschäftsstrategie Business Strategy Business Architecture Business Geschäftsarchitektur Architecture (Business (Geschäftsservices, Services, Business Geschäftsprozesse, Processes, Geschäftsobjekte, Business Objects, Organisation, Organisation) etc.) IT Strategy Domänen Ideal Application Domains und Technical Landscape and Domänen Technische Services (Anwendungs-) Services Application Services und Services Domänen Technische Services (Anwendungs-) und Services Logische Technische Services Logische Logical (Anwendungs-) Logical Anwendungs- Application und and AL-Komponenten AL-Components Services Logische Logische Integration Integrationsplattformen Logische Platforms und and ihre their Schnittstellen Interfaces Anwendungs- und AL-Komponenten Logische Integrationsplattformen und ihre Schnittstellen Anwendungs- und AL-Komponenten Physische Physische Physical Integrationsplattformen und ihre Schnittstellen Physical Anwendungs- Application undand AL-Komponenten AL-Components Physische Physische Integration Integrationsplattformen Physische Platforms und and ihre their Schnittstellen Interfaces Anwendungs- und AL-Komponenten Physische Integrationsplattformen und ihre Schnittstellen Anwendungs- und AL-Komponenten Integrationsplattformen und ihre Schnittstellen Integration AS IS TO BE Evolution IDEAL 4

5 Agenda Overview Web Services SOAP WSDL UDDI REST 5

6 Reference for lecture slides on WS, SOAP, WSDL, UDDI Slides courtesy of: Prof. Karl Aberer (School for Computer and Communication Science, Lausanne, CH) [MV]: With comments by the lecturer 6 Available:

7 Web Services two definitions [MV]: [..] services are [..] applications [..] which can be [..] requests [..] and processes??? - > termonology! "Web services are [ ] self- contained, self- describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. IBM web service tutorial Distributed computing model based on asynchronous messaging Support dynamic application integration over the Web Web Services connect computers and devices with each other using the Internet to exchange data and access services Application services can be distributed over the Internet [MV]: better! - > integration 7

8 The web service architecture : Components and how they interact 3. find (e.g. UDDI) "naming service" Service broker 2. publish (e.g. UDDI) Service requestor "client" 4. bind (e.g. SOAP) 1. define (e.g. WSDL) Service provider "server" 8

9 Web service stack: Set of standards for implementing web services [MV]: Abstraction Publication and Discovery: UDDI Service Description: WSDL Messaging: SOAP [MV]: Binding Transport: HTTP, SMTP, FTTP, 9 UDDI provides a mechanism for clients to find web services UDDI registry is similar to a CORBA trader or a DNS for business applications. WSDL defines services as collections of network endpoints or ports A port is defined by associating a network address with a binding (servers) a collection of ports define a service SOAP is a message layout specification that defines a uniform way of passing XML- encoded data and to bind to e.g. HTTP as the underlying communication protocol SOAP is basically a technology to allow for RPC over the Web" [MV]: Synchronous?

10 An example web service usage scenario (manual) web service lookup write client application execute client application 2. http get 3. WSDL file 4. SOAP request 5. SOAP response Web Service Repository (UDDI) publish web service Web Service Provider 1. register WSDL file (manually) 10

11 Web services implementation Web Service Provider (endpoint) Requestor (SOAP client) SOAP messages (http transport) HTTP server SOAP server application server Application Server (web service- enabled) provides implementation of services and exposes it through WSDL/SOAP implementation in Java as EJB, in C# (.NET) etc. SOAP server: implements the SOAP protocol HTTP server: standard Web server SOAP client: implements the SOAP protocol on the client site 11

12 Agenda Overview Web Services SOAP WSDL UDDI REST 12

13 SOAP (Simple Object Access Protocol) [MV]: Simple? Lightweight messaging framework based on XML Supports simple messaging and RPC SOAP consists of Envelope construct: defines the overall structure of messages Encoding rules: define the serialization of application data types SOAP RPC: defines representation of remote procedure calls and responses Binding framework: binding to protocols such as HTTP, SMTP Fault handling SOAP supports advanced message processing: forwarding intermediaries: route messages based on the semantics of message active intermediaries: do additional processing before forwarding messages, may modify message 13

14 SOAP Message SOAP messages consist of Envelope: top element of XML message (required) Header: general information on message such as security (optional) Body: data exchanged (required) Header elements are application- specific may be processed and changed by intermediaries or recipient Body elements are application- specific processed by recipient only envelope header body 14

15 Example: SOAP Message <?xml version='1.0'?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m= env:role= SOAP attributes SOAP attributes env:mustunderstand="true"> <m:dateandtime> t13:20: :00</m:dateandtime> </m:reservation> <n:passenger xmlns:n= env:role= env:mustunderstand="true"> <n:name>åke Jógvan Øyvind</n:name> </n:passenger> </env:header> <env:body> <p:itinerary xmlns:p=" <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate> </p:departuredate> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate> </p:departuredate> </p:return> </p:itinerary> </env:body> </env:envelope>/ Envelope Header Body 15

16 Conversational message exchanges in SOAP preferences customer alternatives travel company choice 16

17 SOAP RPC Example: Request message Encapsulate RPC into SOAP messages procedure name and arguments response (return value) processing instructions (transactional RPC!) 17 <?xml version='1.0'?> <env:envelope xmlns:env=" > <env:header> <t:transaction xmlns:t=" env:encodingstyle=" env:mustunderstand="true" >5</t:transaction> </env:header> <env:body> TID Transaction information method invocation <m:chargereservation env:encodingstyle=" xmlns:m=" <m:reservation xmlns:m=" <m:code>ft35zbq</m:code> </m:reservation> <o:creditcard xmlns:o=" <n:name xmlns:n=" Åke Jógvan Øyvind </n:name> <o:number> </o:number> <o:expiration> </o:expiration> </o:creditcard> </m:chargereservation> </env:body> </env:envelope> parameter 1 parameter 2

18 SOAP RPC Example: Response message Example cntd.: Response message <?xml version='1.0'?> <env:envelope xmlns:env=" > <env:header> <t:transaction xmlns:t= env:encodingstyle= env:mustunderstand="true">5</t:transaction> </env:header> <env:body> <m:chargereservationresponse env:encodingstyle= xmlns:m=" <m:code>ft35zbq</m:code> <m:viewat> </m:viewat> </m:chargereservationresponse> </env:body> </env:envelope> method result output parameters 18

19 Protocol Binding Bindings to different protocols possible: HTTP, SMTP Different HTTP bindings: HTTP POST, HTTP GET. Standard HTPP POST for request- response POST /Reservations?code=FT35ZBQ HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" > SOAP request message </env:envelope> HTTP/ OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" > SOAP response message </env:envelope> HTTP POST request HTTP response 19

20 Agenda Overview Web Services SOAP WSDL UDDI REST 20

21 WSDL Web Service Description Language Description of Web services in XML format abstract description of operations and their parameters (messages) binding to a concrete network protocol (e.g. SOAP) specification of endpoints for accessing the service Structure of a WSDL document Types: structure of messages (abstract) Operations (protocol) Operations Port: Binding and a network address Messages: used by operations PortType: operations supported by service Binding: concrete protocol Service: collection of related ports abstract [MV]: port type = interface concrete 21

22 Overview of Defining WSDL Services 1. Define in XML Schema the message types used when invoking the service: MT1, MT2 etc. 2. Define (named) messages by using these types, e.g. message m1 has type MT1 message m2 has type MT2 etc. 3. Define Services that consist of one or more operations; each operation is implemented by the exchange of messages service S offers operation O1; for executing O1 first send a request message m1, then a response message m2 is returned 4. Define a Binding B to a specific protocol, e.g. SOAP service S is implemented in SOAP; the SOAP messages are constructed from the abstract messages m1 and m2 by, e.g. inlining the message as body of SOAP messages 5. Service S is provided with binding B at the following URI's (called ports) 22

23 Example: Overall Document Structure <?xml version="1.0"> <definitions name="stockquote > <types> <schema> definition of types in XML Schema </schema> </types> <message name="gettradepriceinput"> definition of a message... </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> definition of an operation </operation> </porttype> <binding name="stockquotesoapbinding"> definition of a binding </binding> <service name="stockquoteservice"> <port name="stockquoteport"> definition of a port </port> </service> </definitions> 23

24 24 Example: Definition of Types

25 Example: Definition of Messages and PortType Operation uses these messages 25

26 Example: Definition of Binding and Service (URI) abstract operation GetLastTradePrice of port type StockQuotePortType implemented by these SOAP messages Binding provided at this URI 26

27 PortTypes and different message patterns WSDL supports 4 message patterns that an endpoint (service provider) can support for an operation one- way: message is sent to service provider without expecting response request- response: request is sent to service provider expecting response solicit- response: provider sends a message and expects response notification: message is sent by service provider Message patterns are distinguished by the use of input/output elements one way: <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions> request/response: <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken" parameterorder="nmtokens"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation </wsdl:porttype > </wsdl:definitions> 27

28 Agenda Overview Web Services SOAP WSDL UDDI REST 28

29 UDDI Universal Description Discovery and Integration Standard for describing, publishing and finding web services Use XML- based description files for services Main components White pages: basic contact information about an organization Yellow pages: classification of organization based on industrial categorization Green pages: technical description of services offered by registered organizations Access to UDDI Registry Standard UDDI API (accessible via SOAP) Web browser Data Structures (XML) Business entity: general information + business services Business services: business level description + binding templates Binding templates: access point + tmodel (service types) tmodel: abstract definition of a web service 29

30 Registering a WSDL Service in UDDI 1. Register a business 2. Register the abstract service definition (tmodel) 3. Register the service implementation definition (BusinessService) 30

31 Summary Web Services are the predominant mechanism for distributed computing on the WWW They implement a service stack comparable to earlier distributed computing solutions such as CORBA, but are fully based on Web standards and therefore can take advantage of the Web infrastructure The current standards include SOAP for communication, WSDL for service specification, and UDDI for service discovery Higher level standards for service composition, semantic description of web services, etc. exist Standard documents arch

32 Agenda Overview Web Services SOAP WSDL UDDI REST 32

33 Reference for lecture slides on REST Slides courtesy of: Stefan Tilkov (innoq) [MV]: With comments by the lecturer 33 Available on SlideShare

34 Web Services Issues Web Services are Web in name only WS- * tends to ignore the web Abstractions leak, anyway Protocol independence is a bug, not a feature 34

35 Web Services A separate interface (façade) for each purpose As known from CORBA, DCOM, RMI/EJB Often used for SOA ( CORBA w/ angle brackets ) Application- specific protocol 35

36 Contribution to the Net s Value [MV]: Part of Roy Fielding s philosophy ofnetwork- based software architectures 2 URLs method POST 36

37 REST (RepresentationalState Transfer) Approach 37 A single generic (uniform) interface for everything Generic verbs mapped to resource semantics A standard application protocol e.g. HTTP [MV]: Then called RESTful HTTP [MV]: Somewhat CRUD- like [MV]: Business Objects (Net) = Everything

38 Contribution to the Net s Value Millions of URLs every customer every order 4-6 supported methods per resource GET, PUT, POST, DELETE, OPTIONS, HEAD Cacheable, addressable, linkable,... 38

39 Designing a RESTful Application Identify resources & design URIs Select formats (or create new ones) Identify method semantics Select response codes 39

40 REST andsoa [MV]: Technical/physical Architecture 40 [MV]: REST is an architectural paradigm. Following the REST approach in a SOA has architectural consequences on the technical/physical level.

41 [MV]: Some brief conclusions REST is much more than just an implementation alternative for services in a SOA With respect to the application landscape s (technical/physical) architecture we have to make some general decisions One homogenious mechanism (WS- * or RESTful HTTP or else) vs. defined heterogenity (e.g. REST for Business Data Components??) Using REST just to exchange plain XML without SOAP complexity is no alternative 41