4ICT12 Internet Applications: Web Services

Size: px

Start display at page:

Download "4ICT12 Internet Applications: Web Services"

Philip Harrison
5 years ago
Views:

1 4ICT12 Internet Applications: Web Services Web Service Overview, RPC and conversational styles, WSDL, ebxml

2 Goals and Contents Aims to convey: The motivations for and characteristics of web services The current state of standardised web service approaches The distinction between simple RPC-style web services and more complex, conversational web service The role of business modelling in developing complex web services Covers: Outline of service-orientated architectures and web services Comparison of simple and complex web services WSDL for simple web service definitions ebxml as a development framework for complex web services

3 The Growth in Interoperating Things [S.Yung, Sun]

Waves of the Internet Computers 10 8 Desktops Embed Computers 10 11 Phones TVs Cars Games Things - 10 14 Thermostats Switches Milk Cartons Clothes Clients Functions Protocols Organization Transfer

4 Waves of the Internet Computers 10 8 Desktops Embed Computers Phones TVs Cars Games Things Thermostats Switches Milk Cartons Clothes Clients Functions Protocols Organization Transfer Interact Access Compos e IP v4 IP Layer FTP SMTP Telnet X RPC/XDR HTTP Client/Server N-tier IIOP WAP RMI/IIOP SOAP LDAP UDDI Web Applications Identity Assimilate JINI Integrate IP v6 JXTA Web Services Polyarchical P2P

5 Scaling of Interoperability Problems Pair-wise interoperation doesn t scale n functional units requires n*(n-1) acts of interoperable design Functional units need single interoperation interface Need to be able to dynamically discover available interfaces of the type required Need to combine existing functions to make new functions Reduce dependence on new code Need to maximise commonality while enabling differentiation Non-functional aspects Answer: Service-Oriented architectures

6 What is a Service? A function performed by a provider on behalf of a consumer It transfers some inherent value from the provider to the consumer Service functionality only available through well-define interface Services can be contained within other services Containment may be opaque to consumer

7 Application Areas Business to Consumer ecommerce Simple, but innovative shrink wrapped services to large numbers of users Business to Business ecommerce Complex services tailored to changing business relationships Ubiquitous Computing Ad hoc peer-to-peer service interaction between mobile users and devices

8 Characteristics of eservices Consumer and Provider are not known to each other in advance of service interactions Between individuals and organisations (B2C) Between organisations (B2B) Between individuals (P2P) Common interaction mechanisms encourages value-chains and service compositions Remove time and location constraints from service requests Examples: SMS, Google, on-line flight booking, telephone banking

9 Basic eservice Interactions Discover Service Service Registry Publish Service Service Consumer Negotiate Service Invoke Service Service Provider

10 Types of eservices Simple, function-based Stateless, no side effects Non-transactional Context free Sessionless, no roles Synchronous Point-to-point Tightly coupled, limits developmental scalability Complex, conversational Impacts other steps Transactional Context sensitive conversions, ordering of steps Session based, personalized One to many messages Messaging based Document rather than parameter based Looser coupling between sides promotes developmental scalability

11 Web Services Internet-scale solution for Simple Services A stepping stone to complex services? eservice that exploit the ubiquity of WWW technology HTTP for universal communication with on-line resources SSL for securing that communication XML for universal exchange of data Simple Object Access Protocol (SOAP) for universal exchange of functional messages Unified way for exchanging XML messages: marshalling, data encoding, RPC and error conventions

12 Core Web Service Technologies Web Service Description Language (WSDL) Description for syntactic interoperability with web services WSDL 1.1 from Microsoft/IBM is a W3C note W3C working on WSDL 2.0 Universal Description, Discovery and Integration (UDDI) Registration, querying and sharing of web service descriptions Standardised by uddi.org

13 WSDL Document Structure A WSDL document defines a web service using these major elements: <porttype> The operations performed by the web service <message> The messages used by the web service <types> The data types used by the web service <binding> The communication protocols used by the web service 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> A WSDL document can also contain other elements <port> related a binding to a network address <service> grouping ports extension elements

14 WSDL Document Strcuture WSDL 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, operations to functions or class methods WSDL 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. WSDL 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. WSDL Bindings The <binding> element defines the message format and protocol details for each port.

15 Operation Types The request-response type is the most common operation type, but WSDL defines four 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

16 Request-Response Example The porttype element defines cheapestflight" as the name of a port, and getcheapestflight" as the name of an operation. The operation has an input message providing origin and destination airport names and the required date of travel. The output message gives the flight number, time and cost <message name= getcheapestflightrequest"> <part name= origin" type="xsd:string"/> <part name= destination" type="xsd:string"/> <part name= date" type="xsd:date"/> </message> <message name= getcheapestflightresponse"> <part name= flight" type="xsd:string"/> <part name= time" type="xsd:time"/> <part name= cost type= xsd:float /> </message> <porttype name= cheapestflight"> <operation name="getcheapestflight"> <input message= getcheapestflightrequest"/> <output message= getcheapestflightresponse"/> </operation> </porttype>

17 One-Way Operation The porttype seatreservation" defines a one-way operation called researveseat". The reserveseat" operation allows reservation of messages using a rsvseatinfo" message providing the flight number, date and passenger name. However, no output is defined for the operation it s a free seating airline. <message name= rsvseatinfo"> <part name= flightid" type="xsd:string"/> <part name= date" type="xsd:date"/> <part name= passengername type= xsd:string /> </message> <porttype name= seatreservation"> <operation name= reserveseat"> <input name= rsvseat" message= rsvseatinfo"/> </operation> </porttype >

18 Binding to SOAP The binding element has two attributes 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 cheapestflight" port. The soap:binding element has two attributes The style attribute can be "rpc" or "document". In this case we use document. The transport attribute defines the SOAP protocol to use. In this 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 this case we use "literal". <binding type= cheapestflight" 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>

19 Platform Support WSDL well supported in Enterprise Application Integration platforms, e.g. J2EE WSDL-based interface generation for existing server functions Many implement Java API for XML-based RCP (JAX-RCP) Things to try: Axis: Apache/Tomcat plugin for WSDL - Sun s Java Web Service Development Pack - CapeClear: WSDL editing support - WSDL not the whole story WS-I Web service platform interoperability forum Need to support complex business interactions

Complex Web Services Internal Business Processes ------ ------ ------ Standards- based Collaboration ------ ------ ------ Internal Business Processes Business Information Business Process Business

20 Complex Web Services Internal Business Processes Standards- based Collaboration Internal Business Processes Business Information Business Process Business Process Business Information Messaging Protocol (Transport, Routing, Packaging, Security) Messaging Protocol (Transport, Routing, Packaging, Security) ERP/DB Communication Protocol Protocol Stack Messages Communication Protocol Protocol Stack ERP/Appl Application or Trading Partner A Application or Trading Partner B

21 Complex WS Approaches ebxml - Business Process level web services RosettaNet business level web service for IT industry Microsoft s Global XML Web Service Architecture (GXA) OASIS Web Services Security BPEL4WS Process flow, Microsoft, IBM, BEA WSCI Conversation Flow, BEA, Intalio, SAP, Sun W3C Web Service Group defacto standards body for interoperability mechanism

22 Complex Web Service Requirements Business to Business eservices are complex Exchanges, e-markets, supply chains, etc. need combinations of web services Auction, pricing, tax computation, customs, RFP, RFQ, order management, content management No two B2B interactions will use the same combination of services and service packages Custom combinations require a framework approach ebxml provides the framework and many pieces Business process analysis and service description process Common, reusable elements Domain and service categorisation

23 Complex Service with ebxml Provides a Standard Way to: Exchange business messages Conduct trading relationships Communicate data in common terms Define and register business processes Joint Venture of: UN/CEFACT: United Nations Center for Trade Facilitation and Electronic Business Developers of EDIFACT One of four organizations in the world that can set de jure standards OASIS: World s largest independent, non-profit organization dedicated to the standardization of XML applications More than 200 member companies

24 Business Level Web Services Business Process Context Core Components Business Process & Core Components Trading Partner A Registry Repository Trading Partner B Trading Partner Agreement Business Service TR&P Trading Partner Agreement Business Service TR&P Business Transaction (TRP)

25 Business Level Web Services ebxml complements Web services by providing a business level framework Trading Partner Profiles and Agreements Business Process Core Components Messaging Service Registry/Repository

26 Collaboration-Protocol Profile and Agreement Collaboration Protocol Profile (CPP) Specifies business processes and technical capabilities for a single partner Collaboration Protocol Agreement (CPA) Document represents intersection of two CPP's Mutually agreed upon by both partners Describes messaging service and business process

27 Business Process Specification Schema Describes collaboration between two partners Defines roles, relationships and responsibilities Defines choreography of business documents Business Process Business Process Collaboration Transaction Transaction... Collaboration... Business Process Customer Create Long Term Contract Forecast Component Requirements Send Planning Document Place Order Supplier Ship Materials Arrange Payment

28 Business Process Taxonomy Common Business Processes $$ $$ financing raw materials procurement transportation labor human labor $$ facilities, services & technology resources labor delivered raw materials manufactured goods delivered manufactured goods manufacturing labor procurement marketing & sales customer service product services

29 Core Components Common Reusable Elements code. type text. type identifier. type amount. type quantity. type measure. type party. details person. details organisation. details postal address. details communication number. details location. Details transport. means. details packaging. details product service. details currency exchange. details charge price. details percentage charge price. details unit charge price. details tax. details account servicer party. details account owner party. details contact party. details charge financial account payment card. expiration. date transport method. code currency. identification. code scale. value line. identifier transport stage. code exchange contract. reference. identifier

30 Messaging Service Uses SOAP 1.1 with Attachments Adds business level functionality Digital Signature Reliable Messaging Security Transport/Routing Envelope Message Envelope Document Envelope Document Business Process... Document Business Service Interface Transport/Routing Protocols

31 Registry/Repository Stores various types of documents such as CPP, CPA, BPSS models Defines ways to access the documents

32 Benefits of ebxml Lowers the cost/complexity of electronic business Facilitates global trade and puts SMEs and developing nations in the picture Expands electronic business to new and existing trading partners Converges current and emerging XML efforts Eliminates dependence by supporting any language, any payload, any transport

33 Relation to Simple Web Services Description WSDL ebxml CPP Spec and ebxml Business Process Spec Publication and Discovery UDDI ebxml Registry Spec Invocation SOAP over HTTP ebxml Messaging Spec integrating SOAP, HTTP Standardisation SOAP, WSDL, UDDI: Developed by a small group of vendor companies ebxml Developed in an open process by more than 4500 participants representing 2000 organizations in 150 countries on virtually every continent

34 Continuing ebxml Work Specifications available at Infrastructure work continuing at OASIS Messaging Collaborative Partner Interoperability, Implementation, Conformance Registry & Repository Content-related work continuing at UN/CEFACT Business Process Core Components

35 Summary Web Services can be characterised as simple, RPC-style or complex, conversational style WSDL is the standard technology for simple web services Well integrated with EAI platforms Strong candidate for basis of complex services Complex services require framework for capturing associated business-level semantics WSDL support only rudimentary semantic descriptions invocation focusses

36 References WSDL Intro: ebxml material: ftp://ftp.baselinemag.com/pub/baselinemag/pdf/printpub/volume0 1/06/p92.pdf Further Links: W3C Web Service Activity: ebxml:

(9A05803) WEB SERVICES (ELECTIVE - III)

1 UNIT III (9A05803) WEB SERVICES (ELECTIVE - III) Web services Architecture: web services architecture and its characteristics, core building blocks of web services, standards and technologies available