Web Services Techniques

Transcription

1 SOTA: Service-Oriented Tech & APP IAAS XAAS PAAS Web-Based SAAS APP-Based TAAS Web Services-Based 李银胜 SOFT 周二 2-4 节 Z2102

2 >> Content LECTURE1. About the Course LECTURE2. The Case & the Project LECTURE3. SOA Architecture & Concepts (*) LECTURE4. Technical Basis : XML with SOA (*) LECTURE5. Basic Techniques: Web Services (*) LECTURE6. Service-Oriented Application Techniques (*) LECTURE7. Service-Oriented Development (2+*) ~ Android Development Tutoring on Demand (>=3 times) * Class Presentation of Prj advances All Right Reserved

3 >>Agenda All Right Reserved Web Services Techs l SOA vs. Web Services l SOAP l WSDL l Web Services App Techs l Semantic Web l WS-BPEL

4 ü SOA & Web Services

5 Technologies/Protocol Stacks: Simple and Open SOAP (Simple Object Access Protocol) ü Invoke or execute through messages WSDL (Web Service Description Language) ü To describe the WS UDDI (Universal Description, Discovery and Integration) ü Publish and discover WS BPEL4WS (Business Process Execution Language for Web Services)/WSFL(Web Service Flow Language) ü Service composition, choreography, orchestration

6 Technologies/Protocol Stacks: : one illustration by IBM BPEL4WS Service Flow Static -> UDDI Service Discovery Direct -> UDDI WSDL Service Publication Service Description Security Management Quality Of Service SOAP XML-Based Messaging HTTP, FTP, SMTP, MQ, IIOP, etc. Network

7 Technologies/Protocol Stacks: SOAP/What SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between applications SOAP is a protocol for accessing a Web Service SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP is let applications exchange information over HTTP SOAP allows you to get around firewalls SOAP is a W3C standard

8 Technologies/Protocol Stacks: SOAP/Why Applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic. A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages. Microsoft and SOAP: SOAP is a key element of Microsoft's.NET architecture for future Internet application development

9 Technologies/Protocol Stacks: SOAP/What SOAP (1.2 by now) is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications. The standard for XML messaging for a number of reasons. ü First, SOAP is relatively simple, defining a thin layer that builds on top of existing network technologies such as HTTP that are already broadly implemented. ü Second, SOAP is flexible and extensible in that rather than trying to solve all of the various issues developers may face when constructing Web services, it provides an extensible, composable framework that allows solutions to be incrementally applied as needed. ü Thirdly, SOAP is based on XML.

10 XML Messaging Using SOAP All Right Reserved

11 Technologies/Protocol Stacks: SOAP/Specification SOAP (1.2 Part 1) defines an XML-based messaging framework: a processing model and an extensibility model. SOAP messages can be carried by a variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol SOAP (1.2 Part 2) defines three optional components: a set of encoding rules for expressing instances of applicationdefined data types, a convention for representing remote procedure calls (RPC) and responses, and a set of rules for using SOAP with HTTP/1.1

12 Technologies/Protocol Stacks: SOAP/Building Blocks A SOAP message is an ordinary XML document containing the following elements: ü A required Envelope element that identifies the XML document as a SOAP message ü An optional Header element that contains header information ü A required Body element that contains call and response information ü An optional Fault element that provides information about errors that occurred while processing the message

13 Technologies/Protocol Stacks: SOAP/ Syntax <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header>... </soap:header> <soap:body>... <soap:fault>... </soap:fault> </soap:body> </soap:envelope>

14 Technologies/Protocol Stacks: SOAP/ Syntax Rules ü A SOAP message MUST be encoded using XML ü A SOAP message MUST use the SOAP Envelope namespace ü A SOAP message MUST use the SOAP Encoding namespace ü A SOAP message must NOT contain a Schema reference ü A SOAP message must NOT contain XML Processing Instructions

15 Technologies/Protocol Stacks: SOAP/ Elements: Header The SOAP Header Element: optional * Contains application specific information (authentication, payment, etc) about the message * If the Header element is present, it must be the first child element of the Envelope * All immediate child elements of the Header must be namespace-qualified. <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m= soap:mustunderstand="1"> 234 </m:trans> </soap:header>... </soap:envelope>

16 Technologies/Protocol Stacks: SOAP/ Elements: Header SOAP defines three attributes in the default namespace (" ü actor ü mustunderstand ü encodingstyle. The attributes defined in the SOAP Header defines how a recipient should process the SOAP message.

17 Technologies/Protocol Stacks: SOAP/ Elements: Header The actor Attribute A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path. The SOAP actor attribute may be used to address the Header element to a particular endpoint. Syntax: soap:actor="uri" <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:actor=" 234 </m:trans> </soap:header>... </soap:envelope>

18 Technologies/Protocol Stacks: SOAP/ Elements: Header The mustunderstand Attribute The SOAP mustunderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. If you add "mustunderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header. Syntax: soap:mustunderstand="0 1" <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:mustunderstand="1"> 234 </m:trans> </soap:header> </soap:envelope>

19 Technologies/Protocol Stacks: SOAP/ Elements: Body The required SOAP Body element contains the actual SOAP message Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines one element inside the Body element in the default namespace ( i.e., Fault element, to indicate error messages. <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:getprice xmlns:m=" <m:item>apples</m:item> </m:getprice> </soap:body> </soap:envelope>

20 Technologies/Protocol Stacks: SOAP/ Elements: Response Msg A SOAP response: <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:getpriceresponse xmlns:m=" <m:price>1.90</m:price> </m:getpriceresponse> </soap:body> </soap:envelope>

21 Technologies/Protocol Stacks: SOAP/ Elements: Fault ü Optional, to hold error and status information for a SOAP message. ü must appear as a child element of the Body element. can only appear once Sub elements: <faultcode> A code for identifying the fault <faultstring> A human readable explanation of the fault <faultactor> Information about who caused the fault to happen <detail> Holds application specific error information related to the Body element Fault Codes: must be used in the faultcode element when describing faults: VersionMismatch. Found an invalid namespace for the SOAP Envelope element MustUnderstand. An immediate child element of the Header element, with the mustunderstand attribute set to "1", was not understood Client. The message was incorrectly formed or contained incorrect information Server.There was a problem with the server so the message could not proceed

22 Technologies/Protocol Stacks: SOAP/ HTTP The HTTP Protocol ü HTTP communicates over TCP/IP. ü An HTTP client connects to an HTTP server using TCP. ü After establishing a connection, the client can send an HTTP request message to the server: POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200

23 Technologies/Protocol Stacks: SOAP/ HTTP ü The server then processes the request and sends an HTTP response back to the client. The response contains a status code that indicates the status of the request: 200 OK Content-Type: text/plain Content-Length: 200 ü the status code of 200 is the standard success code for HTTP. ü If the server could not decode the request, it could have returned something like this: 400 Bad Request Content-Length: 0

24 Technologies/Protocol Stacks: SOAP/ HTTP Binding SOAP HTTP Binding A SOAP method is an HTTP request/response that complies with the SOAP encoding rules. HTTP + XML = SOAP A SOAP request could be an HTTP POST or an HTTP GET request. The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-Length Content-Type The Content-Type header for a SOAP request and response defines the MIME type for the message and the character encoding (optional) used for the XML body of the request or response. Syntax Content-Type: MIMEType; charset=character-encoding Example POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf Content-Length The Content-Length header for a SOAP request and response specifies the number of bytes in the body of the request or response. Syntax Content-Length: bytes Example POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 250

25 Technologies/Protocol Stacks: SOAP/ HTTP Binding Example: ü a GetStockPrice request is sent to a server. ü The request has a StockName parameter, and a Price parameter will be returned in the response. ü The namespace for the function is defined in " address

26 Technologies/Protocol Stacks: SOAP/ HTTP Binding The SOAP request: POST /Stock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope>

27 Technologies/Protocol Stacks: SOAP/ HTTP Binding A SOAP response: HTTP/ OK Content-Type: application/soap; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope>

28 Technologies/Protocol Stacks: WSDL/What WSDL is: ü used to describe Web services ü used to locate Web services ü written in XML and an XML document ü describes how to access WS. ü It specifies the operations (or methods) the service exposes.

29 Technologies/Protocol Stacks: WSDL(Web Services Description Language )/General Vision ü WSDL is an example of implementation technology for service descriptions ü WSDL 1.2 is an XML document format for describing Web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented (RPC) messages. ü WSDL describes Web services starting with the messages that are exchanged between the service provider and requester. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. ü WSDL is sufficiently extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.

30 Technologies/Protocol Stacks: WSDL/What Major elements: ü Types, defines the data types used in messages ü Messages, defines the data elements of a communication ü Port Types, defines the exposed operations ü Bindings, defines the communication protocols ü Ports, specifies an address for a binding ü Services, aggregates a set of related ports.

31 Technologies/Protocol Stacks: WSDL/How ü As IDL (Interface Definition Language) ü Allows tools to generate client access code for a service Examples: IBM WebSphere Studio Application Developer, IBM Web Services Toolkit ü Standardized service interface descriptions ü Allows advertisement and dynamic discovery of services ü Enables dynamic binding to service ü Complements UDDI registry

32 Technologies/Protocol Stacks: WSDL/Structure The main structure of a WSDL document looks like this: <definitions> <types> definition of types... </types> <message> definition of a message... </message> <porttype> definition of a port... </porttype> <binding> definition of a binding... </binding> </definitions>

33 Technologies/Protocol Stacks: WSDL/Structure Abstract Definitions ü <types> data type definitions ü <message> operation parameters ü <porttype> operation definitions Concrete Definitions ü <binding> operation bindings ü <service> location/address for each binding Also: ü <import> used to reference other XML documents

34 Technologies/Protocol Stacks: WSDL/Structure <service> <port> <port> <port> <binding> [SOAP] <binding> [EJB] <porttype> <operation> <operation> <operation> <message> [Request] <message> [Response] <types> [data] <binding> [ ] Service(s) Supported Protocol(s) Java class method method method SOAP Request/ response

35 Technologies/Protocol Stacks: WSDL/Structure A WSDL document can also contain other elements, like extension elements and a service element that makes it possible to group together the definitions of several web services in one single WSDL document. <definitions> <types> definition of types... </types> <message> definition of a message... </message> <porttype> definition of a port... </porttype> <binding> definition of a binding... </binding> </definitions>

36 Technologies/Protocol Stacks: WSDL/Example <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype>

37 Technologies/Protocol Stacks: WSDL/Elements Ports ü The <porttype> element is the most important WSDL element. ü It defines a web service, the operations that can be performed, and the messages that are involved. ü The <porttype> element can be compared to a function library (or a module, or a class) in a traditional programming language.

38 Technologies/Protocol Stacks: WSDL/Elements Messages The <message> element defines the data elements of an operation. ü Each messages can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.

39 Technologies/Protocol Stacks: WSDL/Elements Types ü The <types> element defines the data type that are used by the web service. ü For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

40 Technologies/Protocol Stacks: WSDL/Elements Bindings The <binding> element defines the message format and protocol details for each port.

41 Technologies/Protocol Stacks: WSDL/Elements/Example <definitions name="stockquoteservice" targetnamespace=" xmlns:tns=" > <message name="symbolrequest"> <part name="symbol" type="xsd:string" /> </message> <message name="quoteresponse"> <part name="quote" type="xsd:float" /> </message> <porttype name="stockquoteservice"> <operation name="getquote"> <input message="tns:symbolrequest" /> <output message="tns:quoteresponse" /> </operation> </porttype>... public float getquote (String symbol) public float getquote (String symbol) public float getquote (String symbol)

42 Technologies/Protocol Stacks: WSDL/Elements/Example <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype>

43 Technologies/Protocol Stacks: WSDL/Elements/Example ü The porttype element defines "glossaryterms" as the name of a port, and "getterm" as the name of an operation. ü The "getterm" operation has an input message called "gettermrequest" and an output message called "gettermresponse". ü The message elements defines the parts of each message and the associated data types. ü Compared to traditional programming, glossaryterms is a function library, "getterm" is a function with "gettermrequest" as the input parameter and gettermresponse as the return parameter.

44 Technologies/Protocol Stacks: WSDL/Elements/Ports * describes the interfaces (legal operations) exposed by a web service. * defines the operations that can be performed, and the messages that are involved. * defines the connection point to a web service. It can be compared to a function library (or a module, or a class) in a traditional programming language. * each operation can be compared to a function in a traditional programming language. Operation Types ü One-way The operation can receive a message but will not return a response ü Request-response The operation can receive a request and will return a response ü Solicit-response The operation can send a request and will wait for a response ü Notification The operation can send a message but will not wait for a response *The request-response type is the most common operation type

45 Technologies/Protocol Stacks: WSDL/Elements/Ports One-Way Operation <message name="newtermvalues"> <part name="term" type="xs:string"/> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="setterm"> <input name="newterm" message="newtermvalues"/> </operation> </porttype > * the port "glossaryterms" defines a one-way operation called "setterm". *The "setterm" operation allows input, no output is defined for the operation

46 Technologies/Protocol Stacks: WSDL/Elements/Ports Request-Response Operation <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype>

47 Technologies/Protocol Stacks: WSDL/Elements/Message message defines the messages that are referenced in the input, output, and fault elements within an operation A message may have one or more parts Each part contains a reference to a data type element Reference to XML Schema element using a QName type Reference to XML Schema simpletype or complextype <definitions... > <message name="ncname"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions>

48 Technologies/Protocol Stacks: WSDL/Elements/ Binding to SOAP binding defines the message format and protocol details for a web service. <binding type="glossaryterms" name="b1"> <soap:binding style="document" transport=" /> <operation> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>

49 Technologies/Protocol Stacks: WSDL/Elements/ Binding to SOAP The binding element has two attributes: name and type attribute. ü The name attribute (you can use any name you want) defines the name of the binding, ü the type attribute points to the port for the binding, in this case the "glossaryterms" port The soap:binding element has two attributes: style and transport attribute. ü The style attribute can be "rpc" or "document". In this case we use document. ü The transport attribute defines the SOAP protocol to use. In above case we use HTTP. The operation element defines each operation that the port exposes. ü For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In above case we use "literal".

50 Technologies/Protocol Stacks: WSDL V 1.2 {messages} A set of named message definitions {interfaces} A set of named interface definitions {bindings} A set of named binding definitions {services} A set of named service definitions {type definitions} A set of named type definitions, each one isomorphic to a simple or complex type as defined by XML Schema {element declarations} A set of named element declarations, each one isomorphic to a global element declaration as defined by XML Schema

51 Technologies/Protocol Stacks: UDDI /What UDDI is: ü Universal Description Discovery and Integration ü a directory service where businesses can register and search for Web services. ü a directory for storing information about Web services ü a directory of web service interfaces described by WSDL ü communicates via SOAP ü a platform-independent framework for describing services, discovering businesses, and integrating business services using the Internet.

52 Technologies/Protocol Stacks: UDDI/Why ü Any industry or businesses of all sizes can benefit from UDDI ü Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services. ü Nor was there a method of how to integrate into each other's systems and processes.

53 Technologies/Protocol Stacks: UDDI/Why Problems the UDDI specification can help to solve: ü Making it possible to discover the right business from the millions currently online ü Defining how to enable commerce once the preferred business is discovered ü Reaching new customers and increasing access to current customers ü Expanding offerings and extending market reach ü Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy ü Describing services and business processes programmatically in a single, open, and secure environment

54 Technologies/Protocol Stacks: UDDI/How l If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. l Travel agencies could then search the UDDI directory to find the airline's reservation interface. l When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.

55 Technologies/Protocol Stacks: UDDI/Process

56 Technologies/Protocol Stacks: UDDI 3 Parts of UDDI: UDDI 数据模型 (XML Schema) 用于描述 Web 服务 UDDI API, 基于 SOAP 的 API, 用于查找和发布 Web 服务 UDDI cloud services, 提供 UDDI 规范的实现

57 Technologies/Protocol Stacks: UDDI 4 Elements of UDDI Data Model: UDDI 数据模型定义了四种核 心数据类型, 这些类型通过 XML 来描述 businessentity( 描述发布服务组织的信息 ) businessservice( 描述服务的业务功能 ) binding Template( 描述技术细节, 包括 API) tmodel( 其他各种属性, 如分类 数字签名等 )

58 Technologies/Protocol Stacks: UDDI/Motivation 白 页表 示有关企业的基本信息, 如企业名称 经营范围的描述 联系信息等等 它还包括该企业任何 一种标识符 黄 页信息通过 支持使 用多种具有分类功能的分类法系统产 生的类别划分, 使得使 用者能够在更 大的范围内查找在注册中 心注册的企业或服务 这样的类别划分不仅可以关联企业及其服务, 还可以关联 tmodel 绿 页是指与服务相关联的绑定信息, 并提供了指向这些服务所实现的技术规范的引 用和指向基于 文件的 URL 的不同发现机制的指针 白 页和 黄 页对通过程序发现和使 用服务 而 言作 用有限, 绿 页则使通过程序的 方式调 用服务的信息更加 方便

59 Technologies/Protocol Stacks: UDDI/Business Entity <businessentity businesskey="0076b468-eb27-42e5-ac cff462a3" operator="microsoft Corporation" authorizedname="martin Kohlleppel"> <name>microsoft Corporation</name> <description xml:lang="en"> </description> <contacts> <contact usetype="corporate Addresses and telephone"> <description xml:lang="en">corporate Mailing Addresses </description> <personname /> <phone usetype="corporate Headquarters">(425) </phone> <address sortcode="~" usetype="corporate Headquarters"> </address> </contact> </businessentity>

60 Technologies/Protocol Stacks: UDDI/businessService <businessservice servicekey="d e16-11d5-98bf c64" businesskey="ba744ed0-3aaf-11d5-80dc c64"> <name>xmethods Delayed Stock Quotes</name> <description xml:lang="en">20-minute delayed stock quotes</ description> </businessservice>

61 Technologies/Protocol Stacks: UDDI/bindingTemplate <bindingtemplates> <bindingtemplate servicekey="d e16-11d5-98bf c64" bindingkey="d594a970-3e16-11d5-98bf c64"> <description xml:lang="en"> SOAP binding for delayed stock quotes service </description> <accesspoint URLType="http"> </accesspoint> </bindingtemplate> </bindingtemplates>

62 Technologies/Protocol Stacks: UDDI/businessService <tmodel tmodelkey="uuid:0e727db0-3e14-11d5-98bf c64" operator="web.ibm.com/services/uddi" authorizedname=" qs1"> <name>xmethods Simple Stock Quote</name> <description xml:lang="en">simple stock quote interface</ description> <overviewdoc> <description xml:lang="en">wsdl link</description> <overviewurl> </overviewurl> </overviewdoc> </tmodel>

63 Questions ü 1. Provide as many features as SOAP has. ü 2. Discuss how to implement service security based on SOAP? ü 3. How many elements that SOAP has and are they required or optional? ü 4. What does Mustunderstand mean? ü 5. Is UDDI required for Web services discovery? ü 6. How many parts does the data model of UDDI have. And who are they? ü 7. Provide WSDL's basic elements. ü 8. Explain the function of WSDL's binding element? ü 9. What is WS-BPEL for? ü 10. Try to illustrate and explian as many as WS-BPEL's elements..

64 Take a break All Right Reserved