Web Services Components

1. Web Services Components

2. Objectives of Chapter 8 Web Service Components • Introduce the Web service framework • Introduce concepts of Web service components • Discuss compositions of Web service components • Discuss types of Web service components and their deployments • Discuss the interoperability of Web services components • Distinguish synchronous and asynchronous Web services invocations • Provide step by step tutorials on building, deploying, and using Web service components

3. Overview of the Web Services Framework • Web service is a new paradigm to deliver application services on Web and enables a programmable Web not just an interactive Web . • Web service is the third generation in the Web evolution after static HTML and interactive Web development such as PERL, ASP, JSP, and others. • Web services are typical black box reusable building block components in the distributed computing.

4. Overview of the Web Services Framework (cont.) • Web service works on a protocol stack consisting of SOAP/XML/HTTP/TCP/IP, which makes Web services so widely acceptable as long as clients of Web services have supports from these protocols. • Web service revolutionizes the distributed computing and signals a new era of lightweight distributed application development in the advantage of loosely coupled features of Web service components. • It is very easy to deploy, publish, discover, and invoke a Web service on Internet.

5. Overview of the Web Services Framework (cont.) • Web services is a self-descriptive on-line distributed component which exposes its services and functionality via its interface on-line and can be published, located, and invoked programmatically over Internet. A key point of the importance of Web services is its ability to support programmatic end point for any application to get services provided by any Web services on line.

6. Overview of the Web Services Framework (cont.) • One philosophy behind Web services is to shift distributed software development from programming to composition, from coding ground up to building new application from existing component either by purchasing or by reusing the existing components. • So the main goal of Web services is not only to provide services on Web but also to provide a mechanism to share its services as a building block to be part of other Web services or application programs via its programmatic Web service end points.

7. Overview of the Web Services Framework (cont.) The characteristics and features of the Web service technology are: • It increases the portability and interoperability of distributed computing • It increases the reusability and scalability of distributed components. • It reduces the complexity of component composition and deployment. • It reduces the cost and time-in-market for distributed component software developments. • It significantly enhances the B2B and Electronic Data Interchange (EDI). • It simplifies the distributed system administration. • It is very easy to wrap an existing proprietary application to be Web service compatible. • It operates on an open standard protocol stacks • It is a third generation Internet solution for distributed computing.

8. The XML Basics • eXtensible Markup Language (XML) is a super set of HTML. A user can define his /her own tags in XML. • Any XML documents must conform their metadata such as Document Type Definition (DTD) or Schema which specifies complex data types, elements and its attributes, and its sub-elements, etc. • A XML document can be used to represent and transfer structured data in the hierarchy of element tags. A XML documents with its schema or DTD can be recognized by any programs or software easily as long as XML API is supported. • A XML document is a universal format document type used for data exchange and data storage. XML is also widely used for deployment descriptors and configuration specifications.

9. The XML Basics (cont.) A simple XML document about student GPA record. <?xml version = “1.0”?> <students> <student id=1234> <name>John Smith</name> <gpa>3.5</gpa> </student> <student id=2345> <name>Scott Tiger</name> <gpa>4.0</gpa> </student> </students>

10. The XML Basics (cont.) • This XML document shows two student records. Each record consists of student name and his/her grade point average (gpa). The tag students is a top level root element which has a number of sub-elements called student. • Each student element consists of two sub-elements called name and gpa. The identifier id in student tag is an attribute of element student. • The tag “?” is a Processing Instruction (PI) to inform XML parser that this XML document must conform XML v. 1.0. • Every XML document must have its metadata just like a data record in a data table of any database must satisfy the definition of the table which is called schema in database.

11. The XML Basics (cont.) • There may be many different formats of XML schema such as internal DTD within XML file, a separate external DTD, or a schema. • Since the DTD itself does not use XML syntax and is not very flexible. Schema is getting more and more popular now and is replacing DTD because schema itself is in XML format. • A XML Schema Document (XSD) is a metadata of a XML document. XSD specifies the syntax, structure, and constraints in a corresponding XML including datatype or complex datatype of elements, attributes of elements.

12. The XML Basics (cont.) • The following Schema describes the structure of above students XML document. A complex type can be specified by a complexType tag as follows. <element name = “student” <complexType> <element name = “name” type = xsd: string”/> <element name = “gpa” type = “xsd: float /> </complexType> </element>

13. The XML Basics (cont.) • Let’s examine a complete XSD Schema sample. <?xml version=”1.0” encoding=”UTF-8”?> <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace=http://www.mybooks.org” xmlns=”http://www.mybooks.org”> <xsd:element name = “students”> <xsd:complexType> <xsd:sequence> <xsd:element ref=”student” minOccurs=”1” maxOccurs=”unbounded”/> </xsd:sequence/> </xsd:complexType/> </xsd:element>

14. The XML Basics (cont.) <xsd:elememt name=”student”> <xsd:complexType> <xsd:sequence> <xsd:element ref=”name”/> <xsd:element ref=“gpa”/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name=”name” type=”xsd:string”/> <xsd:element name=”gpa” type=”xsd:float”/> </xsd:schema>

15. The XML Basics (cont.) • The sequence tag in XSD Schema specifies the order and the occurrence of sub-elements in their parent element. In this example name and gpa elements are the sub-elements of the student element which in turn is an element of the students element. • Of course there may be many students in a students set. The XMLNS plays a same role as package in Java and namespace in C++ to prevent naming collisions. • An element name can be qualified with a namespace prefix with a colon symbol “:”. The idea of combining a namespace URI with a local name is to make any identifier name in XML universally unique.

16. The Simple Object Access Protocol (SOAP) Basics • SOAP is an XML based message exchange protocol specified by the W3C specification. • SOAP is also a lightweight protocol working in a distributed heterogeneous environment. Some people simply say that SOAP = HTTP + XML since SOAP message is an XML-document but it conforms to a specific XML Schema. • SOAP is used to specify the format of a request and response in the Web service computing to get and send message via HTTP port by HTTP POST method.

17. The Simple Object Access Protocol (SOAP) Basics (cont.) • Every SOAP message has a required envelope and a message body. A SOAP envelope identifies an XML document as a SOAP message. • A SOAP envelope element must have one sub-element which is the Body element. A Body element of a SOAP message can be data itself, a name of method be invoked, arguments of the method be invoked, a SOAP request message, or return results from a SOAP response message. • A SOAP envelope may also have a header sub element but it is optional. A header element just gives more metadata about the message.

18. The Simple Object Access Protocol (SOAP) Basics (cont.) • An example of a SOAP request message which asks a Web service to convert a temperature zero Celsius degree to Fahrenheit degree. The name of the invoked method is “toFahrenheit”. <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoa.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

19. The Simple Object Access Protocol (SOAP) Basics (cont.) <SOAP-ENV:Body> <toFahrenheit> <celsius xsi:type="xsd:string">0</celsius> </toFahrenheit> </SOAP-ENV:Body> </SOAP-ENV:Envelope> In the Body element of this SOAP request a XSD string type data “0” is passed in as an argument to the remote method (operation) toFahrenheit of this Web service.

20. The Simple Object Access Protocol (SOAP) Basics (cont.) The following SOAP message is a SOAP response message of the converted temperature of 32 Fahrenheit degree. <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Body> <toFahrenheitResponse SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <toFahrenheitResult xsi:type= "xsd:string">32</toFahrenheitResult> </toFahrenheitResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

21. The Web Service Architecture There are three important components in Web service architecture. The Web service requester (simplified client) on the left, the Web service provider on the right, and the Web service registry on the top.

22. The Web Service Architecture (cont.) • A Web service provider must publish/register its services with a Universal Description, Discovery, and Integration (UDDI) registry so that it can be accessed by any Web services requester globally. • It just looks like a phonebook where all businesses register their phones there for customers to lookup services. A customer must lookup the phonebook either on-line or by phonebook unless a customer knows the phone number before. • A Web service can also be reached without any assistance from UDDI if the Web service client knows the contact information such as Web service’s URL, name of method, argument signature of the method including types of return value.

23. The Web Service Architecture (cont.) • The Web service provider can register their Web services at these UDDI registries and Web service requester can lookup a specific Web service by its provider name (business name), category info, Web service name, or even by the keys of them if requester knows. • A Web service provider actually registers a WSDL (web Service Description Language) interface at UDDI registry which is a contract interface of the Web service to be used by its client. • Both UDDI query requests and UDDI query results are in the SOAP formats.

24. WSDL • A Web service WSDL interface is a XML file describing what functionality this Web service provides, where this Web service resides, and how to access Web service and invoke the remote method provided by this Web service. • WSDL shows an abstract view or interface definition that can be implemented by many concrete Web service implementations in different platforms, and different languages. • We can divide a WSDL Web service definition into two parts: Web service reusable interface specification and Web service implementation. There may be four elements in first part:

25. WSDL (cont.) • The types elements for complex data type and user defined type; message elements for message description which is used in portType element; portType element describing an abstract set of reusable exposed operations by one or many Web service endpoints(port); binding element for message format specification and concrete protocol binding specification such as SOAP, HTTP, MIME. • There are two major elements in WSDL implementation part: Port element which is a single Web service endpoint based on a binding defined in binding element and an URL access location; Service element which is a parent element of port element and a collection of related Web service endpoints or ports. WSDL XML document basically defines Web services as a collection of endpoints or ports.

26. WSDL (cont.) The structure of a WSDL looks like the following templates. <definitions …> <types … > <message …> <portType … > <binding … > <service … > <port … > </service> </definitions>

27. WSDL (cont.) • The following list is a WSDL definition part of Convert.wsdl which gives a clear description of a Web service definition. A WSDL definition element has a number of sub elements such as, message element, portType element, binding element, port element, and service element. <wsdl:definitions . . . <wsdl:message name="toFahrenheitResponse"> <wsdl:part name="return" type="SOAP-ENC:string"/> </wsdl:message> <wsdl:message name="toFahrenheitRequest"> <wsdl:part name="in0" type="SOAP-ENC:string"/> </wsdl:message> <wsdl:portType name="Convert">

28. WSDL (cont.) <wsdl:operation name="toFahrenheit" parameterOrder="in0"> <wsdl:input message="intf:toFahrenheitRequest"/> <wsdl:output message="intf:toFahrenheitResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="ConvertSoapBinding" type="intf:Convert"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="toFahrenheit"> <wsdlsoap:operation soapAction=""/>

29. WSDL (cont.) <wsdl:input> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:myDirectory" use="encoded"/> </wsdl:input> <wsdl:output> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:myDirectory" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding>

30. Service definition <wsdl:service name="ConvertService"> <wsdl:port binding="intf:ConvertSoapBinding" name="Convert"> <wsdlsoap:address location="http://localhost:8080/axis/services/Convert"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

31. The name of the Web service “ConvertService” is specified in a service element which is listed at the end of above WSDL file. • The port element of the service element specifies an URL address of the Web service and access point of this Web service for a unique binding. • The binding “ConvertSoapBinding” is defined in a binding element which is referenced in binding attribute of port sub-element of service element in WSDL definition element. There may be multiple ports in one Web service

32. WSDL (cont.) • There are two message elements at beginning of definition element. • One describes the argument type of Web service’s remote method and the other is the return type of the same method. • The part sub-element specifies the name and data type of the message exchanged.

33. WSDL (cont.) • The portType element describes an operation provided by the Web service. • A operation is a method which a client must know about the input parameters and return data type. • The two messages defined for Web service request and response are specified in the operation element. • The operation element describes that the name of the method in Web service is toFahrenheit. A portType is a collection of operations.

34. WSDL (cont.) • The binding elements inside definition element specify how a client and Web service should exchange message each other. • The binding sub-element of the binding element specifies SOAP as the protocol and input request and output response must be in a SOAP format. It also tells that this is a request/response two ways operation by the attribute style “rpc”. • The other style option may be “document”. There are four type operations in term of patterns of inputs and outputs: input only, output only, input/output, output/input. These will be discussed in detail in the Web service connection section.

35. UDDI • UDDI is a technical specification for building a distributed directory for business and Web services which enables business companies to publish and find Web services. • How to publish a Web service globally and how to discover a desired Web service to reuse it as part of new Web service or as part of client application is a challenge for Web service to be widely used. • If a client of a Web service knows in advance about the location of the Web service and the way to invoke the operations provided by the Web service there will not be a need of Web service registry.

36. UDDI (cont.) • UDDI acts like a naming service in the distributed computing, or phone directory for phone service, or Google search engine for Internet service. • UDDI consists of an XML schema that defines UDDI's four core data structures - business, service, binding and tModel programmatic interface and a set of APIs that provide publishing and inquiry operations on those structures.

37. UDDI (cont.) • A Web service requester searches the service registry and finds the desired service description. Through the information the requester finds in the registry, the requester connects to the Web service provider and invokes the service. • UDDI is a group of specifications that lets Web service providers publish information about their Web services and lets Web service requesters search that information to find a Web service and run it.

38. UDDI (cont.) • A Web service listing is created using WSDL and then sent to a UDDI registry which is mapped to a UDDI XML format document. • A listing is comprised of three elements. At the highest level there are White Pages, which contain basic information about the business including business name, descriptions, contact info (name, address, phone, fax, Web site, … ), business identifier that a business may be known by. • Next are Yellow Pages, which organize services by industry codes, service type/business categories in product/services or geographical location taxonomy.

39. UDDI (cont.) • Finally there are Green Pages, which specify how to bind to a service provider. It includes the technical information (such as interfaces and URL locations) about how to find and execute a Web service. • An application requesting a service will use WSDL to programmatically interact with the Green Pages section of that service's listing. • Putting in short, UDDI is organized in a three level nested structure model with business information, service information, and biding information

40. UDDI (cont.)

41. The Component Model of Web Service • Interface and implementation of Web service component • Web service is a typical software component available on-line. There is also a Web service interface just like other components but Web service interface is specified in a WSDL XML format file instead of an IDL file in CORBA. We can have a single wsdl interface specification including all necessary information for a Web service client to access it.

42. The Component Model of Web Service (cont.) myService.wsdl: <definitions …> <types … > <message …> <portType … > <binding … > <service … > <port … > </service> </definitions>

43. The Component Model of Web Service (cont.) • The first four elements constitute a reusable Web service interface definition. The type element describes the XSD type and user defined types which may be used in message element. • The message element describes the request and response message specifications used in a portType element. The portType element specifies a collection of operations (methods) exposed by Web service. PortType plays a very similar role of classin Java. • The binding element binds and maps operations defined in portType element to a transport protocol. The service element plays a role of implementation of above Web service definition by specifying the binding defined and physical endpoint address of the Web service where it resides.

44. The Component Model of Web Service (cont.) • We can also have two or multiple WSDL specifications working together that one WSDL can import definitions from other WSDL. For example we can separate myService.wsdl into two WSDL specifications, service implementation WSDL myServiceImpl.wsdl and service interface WSDL myServiceIntf.wsdl. • The service interface gives a reusable definition of a Web service and corresponds to a tModel in UDDI. The service implementation is an implementation of the service. • A WSDL XML specification can be generated from an implementation java source file or even from a java interface source file by Web service development tools. For example java2wsdl utility command line can be used to generated or by making an internet URL request a [web service name].jws?wsdl to get and save it in a file.

45. The Component Model of Web Service (cont.) Service interface document myServiceIntf.wsdl: <definition …> <types … > <message …> <portType … > <binding … > </definition> Service implementation document myServiceImpl.wsdl: <definition …> <import namespace= … location=”…/myServiceIntf.wsdl> <service … > <port … > </service> </definition>

46. The Component Model of Web Service (cont.) • In myServeImpl.wsdl the import element has a location attribute which references to the service interface document , and a namespace attribute which matches the targetNamespace in the service interface document. • The service element specifies the actual location (URL) of Web service on the server, and port element is the endpoint of Web service specifying the address for particular binding.

47. The Component Model of Web Service (cont.) • A WSDL specification can be generated from an existing Web service implementation such as a java source file or generated from a java interface file. • The popular third generation Web service - Apache eXtensible Interaction System (AXIS)

48. The Component Model of Web Service (cont.) • Top-Down design • The design and development starts up with a Java interface file or WSDL XML file to generate Web service skeleton and stub first without existing Web service implementation. • Next, develop implementation of Web service on server site and deploy the Web service on Web service server. Finally, develop Web service client based on the Web service stub generated in first step to access the Web service deployed. • If we start off a Web service design with a new WSDL, which is called “green field” design, a Java interface will be generated from the WSDL and rest of development procedure will be same .

49. The Component Model of Web Service (cont.) • Bottom-Up design • The design and development of the Web service starts off with an existing Web service such as a Java source file first. Next, generate and deploy Web service with different deployment options. • Finally, develop the Web service client to get service from the deployed Web service.

50. The Component Model of Web Service (cont.)