Web Services Infrastructure and Organizations

1. Web Services Infrastructure and Organizations

2. Overview of Web Services Infrastructure and Models

3. Overview • The World Wide Web (WWW) • Using textual data and graphics • Web services help applications to interact directly with one another and execute instructions automatically

4. Introduction to Web Services • Consider an e-business transaction. • The transaction appears to be simple, but multiple applications are operating in the background • Web services are web-based applications that integrate and interconnect with other applications to transfer large amount of data economically and efficiently across the world.

5. What is Web Services? • Web services are web-based enterprise applications that use open, eXtensible Markup Language (XML) • Web services can access Internet applications, such as e-business and banking transaction systems • Multiple applications are sometimes incompatible because the applications are portable on different operating systems and are developed using different languages, databases, and middleware technologies

6. Web Services Infrastructure • XML provides a way to represent data that is language-neutral. The development of XML forms the foundation for the web services infrastructure. The infrastructure establishes a structure in which decentralized web services can be centrally defined, deployed, and manipulated. The infrastructure also enumerates a list of components that form the functional basis of the web services infrastructure.

7. Entities Used in Web Services Infrastructure • Web services infrastructure specify the role of three basic entities that participate in a web services transaction: • service providers, • service registries, • service requesters.

8. Entities Used in Web Services Infrastructure (continued) • Description enables a service requester to discover and use the service by specifying the following information: • Data types used by the service • Operations performed by the service • Binding information to establish a connection with the service • Location of the service on the network

9. Functional Components of Web Services Infrastructure • Functional components form the implementational basis of web services infrastructure. A series of functional components have been listed by the web services infrastructure. However, all of these components have not been deployed. Work is still on-going for components, such as message exchange, correlation, guaranteed message exchange, transactions and activities, process flow and contract description, and inspection.

10. Functional Components of Web Services Infrastructure (continued) • The following functional components are used in a web service transaction: • Message envelope • Binary attachments • Digital signature • Encryption • Service description • Discovery

11. Web Services Model (WS Model) • The WS model provides interoperability between different systems through standardization of communication protocols and data formats. As a result, business services can be distributed over the Internet and made accessible from different types of communication devices. • The WS model derives its operational and functional characteristics from the web services frameworks. This model is promoted by organizations such as IBM, Microsoft, and Sun Microsystems under the W3C initiative.

12. Uses of the WS Model • The WS model: • Helps organizations to easily engage with their customers, partners, and employees • Enables organizations to extend their existing services to new customers • Helps organizations to work more efficiently with their partners and suppliers • Helps reduce development time and cost of developing new projects

13. Specifications in the WS Model • To make the Internet a global common platform where organizations and individuals can communicate with each other and facilitate commercial transactions, web services require technologies built around various specifications. These specifications include Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL), and UDDI. • SOAP enables messaging, WSDL provides service description, and UDDI maintains the service registry or repository.

14. SOAP • SOAP was developed in 1999 as an extension of the XML-RPC specification. SOAP is a message layout specification that uses XML for exchanging information in a decentralized and distributed environment. SOAP is a platform- and language-independent protocol that allows applications to communicate with each other over the Internet. SOAP provides a simple messaging framework that is easy to develop and independent of any platform, operating system, and programming language. • SOAP enables transfer of XML documents over a variety of standard Internet protocols, including Simple Mail Transfer Protocol (SMTP), HTTP, and File Transfer Protocol (FTP), by specifying a standard packaging structure. It also specifies encoding and binding standards for transfer of non-XML RPC invocations in XML. SOAP provides a simple structure for document exchange in RPC. Diverse clients and servers can become interoperable because of a standard transport mechanism.

15. SOAP (continued) • To provide a basic, common XML messaging protocol for the web, the SOAP specification defines: • The start and end of an envelope that encloses the XML document to be transported • The method by which optional headers are represented for additional information • The method that serializes data-type encodings with specific support for RPC-style interactions • A binding to HTTP to ensure that it carries the document correctly to its destination and that the destination directs the message to an appropriate SOAP processor

16. WSDL • WSDL provides a standard for describing the interface of a web service using XML. WSDL was developed primarily by Microsoft and IBM. It was later submitted to the W3C. As the number of communication formats and protocols used on the Internet continues to increase, finding a standard way for two machines to communicate with each other has become essential. WSDL describes the function and location of a web service. The design of WSDL allows it to be used with both procedure- and document-oriented interactions, such as a client server request or the storage and retrieval of a file.

17. WSDL (continued) • WSDL standarizes: • Representation of the input and output parameters of an external invocation • Structure of the function • Nature of the invocation • The service's protocol binding • WSDL enables different clients to interact with a web service. • WSDL includes definitions of parameters and constraints for how communication between different components should occur at runtime.

18. UDDI • UDDI is a set of standards that provides a mechanism for deploying and locating web services. It helps organizations and individuals to dynamically look up and discover services provided by external business organizations. A UDDI registry has two types of clients: • Clients who want to deploy and publish service descriptions • Clients who want to obtain these service descriptions deployed and published by other clients

19. UDDI (continued) • UDDI resembles a city directory that contains the addresses and descriptions of the entries of the individuals and organizations. UDDI contains three levels of detail regarding the services. The first level or white pages provides information such as its address, a description, and contact information. The second level or yellow pages of the UDDI include a list of business services that contains a description of the services and a list of categories that describes these services. The green pages or the third level of UDDI consist of one or more binding templates that provide additional technical information about a web service.

20. Java EE 5 Web Services APIs • Many different APIs are available in Java EE 5 Web Services APIs. Each API serves a definite purpose to integrate Java server-based functionality into web services. Java EE 5 Web Services APIs include: • JAX-WS • JAXB • XWSS • SAAJ

21. Overview of W3C • The World Wide Web Consortium (W3C) is an international consortium formed in 1994 to create a set of standards for all organizations developing web technologies. W3C aims for complete interoperability of web software and hardware by publishing open, non-proprietary standards for web languages and protocols.

22. Goals of W3C • W3C has the following goals: • Web for all – Make the web accessible to all users despite their differences in culture, language, education, material resources, access devices, and physical limitations • Web on everything – Make the web easily accessible from any type of device • Knowledge base – Develop a web that acts as a vast database of human and machine processing information • Trust and confidence – Promote technologies that build a web environment where security, confidence, accountability, and confidentiality are ensured

23. Principles of Designing for the World Wide Web • W3C recommends the use of the following fundamental principles while designing web applications: • Interoperability – Developers should use language and protocol specifications that ensure interoperability of hardware and software on the web. • Evolution – The web must be able to accommodate future technologies. To make the web work with emerging technologies, developers should use the design principles of simplicity, modularity, and extensibility.

24. Principles of Designing for the World Wide Web (continued) • Decentralization – The web must be designed in such a way that the web architecture does not depend on any central registry. This allows the web to decrease traffic and errors, and scale to worldwide proportions. • Accessibility – The web must be designed so that people with disabilities are able to understand, navigate, and interact with it. They should also be able to contribute to the web. For example, the browser should be made accessible from a keyboard for the people who are blind. Also, there should be support for screen reader technology, which interprets screen content and directs it to either a speech synthesizer or a refreshable Braille device for the blind.

25. W3C Activities • W3C has work groups tasked with the following initiatives: • Making the web accessible to people with disabilities • Developing and extending XML • Defining mathematics and graphics standards • Developing new HTML and style standards • Developing standards for synchronized multimedia • Supporting web access from different devices • Standardizing and internationalizing web services • Developing rich web clients • Developing tools for XML key management

26. Web Services Enabling Technologies

27. SOAP Overview • The Simple Object Access Protocol (SOAP) is used by heterogeneous applications to exchange messages. In addition to simple eXtensible Markup Language (XML)-based messages, SOAP can also transport additional data or payload. This inter-application communication in a distributed environment takes place over transport protocols, such as the Simple Mail Transport Protocol (SMTP) and the Hypertext Transfer Protocol (HTTP).

28. SOAP • Remote Procedure Calls (RPCs) were used to communicate between distributed applications. • SOAP was developed to enable distributed applications to communicate over the Internet. • SOAP is an XML-based protocol. It is language- and platform-independent and, therefore, enables applications to exchange messages.

29. SOAP Message • A SOAP message is a well-formed XML document that contains the following primary elements: • Envelope • Header • Body <?xml version="1.0"?> <Envelope> <Header> ... ... </Header> <Body> ... ... <Fault> ... ... </Fault> </Body> </Envelope>

30. The Envelope Element • The Envelope element is mandatory and is the root element. • The Envelope element must always be associated with the http://www.w3.org/2001/12/soap-envelope namespaceURI. <?xml version="1.0"?> <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <Header> ... ... </Header> <Body> ... ... <Fault> ... ... </Fault> </Body> </Envelope>

31. The encodingStyle Atrribute • The encodingStyle attribute specifies the rules that define how data is represented in a SOAP message. • where the SOAP specification suggests that the namespaceURI should be http://www.w3.org/2001/12/soap-encoding. This namespaceURI points to the XML schema that defines the encoding rules for a SOAP message. • <?xml version="1.0"?> • <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" encodingStyle="http://www.w3.org/2001/12/soap-encoding"> • <Header> • ... • ... • </Header> • <Body> • ... • ... • <Fault> • ... • ... • </Fault> • </Body> • </Envelope>

32. The Header Element • The Header element is optional and contains header information. • The Header element must be the first child element of the Envelope element. • The child elements of the Header element must be namespace-qualified. • In the code example, Trans is a child element of the Header element and http://www.school.com/transaction/ is the namespaceURI. <?xml version="1.0"?> <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <Header> <m:Trans xmlns:m="http://www.school.com/transaction/"> </m:Trans> </Header> <Body> ... <Fault> ... </Fault> </Body> </Envelope>

33. The actor Attribute • The actor attribute is used to direct a header block to a particular endpoint. • The actor attribute, if not specified, indicates that the message is intended for the final recipient. • The syntax for the actor attribute is actor="namespaceURI“ • In the code example, the actor attribute is used in the Header element. The path name http://www.school.com/stock/ is the namespaceURI that indicates the endpoint. <?xml version="1.0"?> <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <Header> <m:Trans xmlns:m="http://www.school.com/transaction/" soap:actor="http://www.school.com/stock/"> </m:Trans> </Header> <Body> ... <Fault> ... </Fault> </Body> </Envelope>

34. The mustUnderstand Attribute • The mustUnderstand attribute indicates whether the recipient must process the header block. • The recipient is indicated by the actor element. • The syntax for mustUnderstand is soap:mustUnderstand="0|1" • where 1 or true indicates that it is mandatory for the receiver to recognize and process the element. Elements not annotated with the mustUnderstand attribute, or those that contain a value of 0 or false, are optional and need not be processed. <?xml version="1.0"?> <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <Header> <m:Trans xmlns:m="http://www.school.com/transaction/" actor="http://www.school.com/stock/" soap:mustUnderstand="1"> </m:Trans> </Header> <Body> ... <Fault> ... </Fault> </Body> </Envelope>

35. The Body Element • The Body element is mandatory and contains the message payload. • A SOAP message can have only one Body element. • The Body element can contain an XML document fragment as its child element, which might be namespace-qualified. • The Body element can contain a Fault element. • The Body element must be an immediate child element of the Envelope element or follow the Header element, if the Header element is present. <?xml version="1.0"?> <Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <Header> <m:Trans xmlns:m="http://www.school.com/transaction/"> </m:Trans> </Header> <Body> <m:getBook xmlns:m="http://www.school.com/books"> <m:Item> Pride and Prejudice </m:Item> </m:getBook> </Body> </Envelope>

36. Transmitting Binary Data • A SOAP message can carry binary data. The binary data is packaged with the SOAP message. • The packaged data is sent as a single stream over transport protocols, such as HTTP, SMTP, or the File Transfer Protocol (FTP). • The SOAP Messages with Attachments (SwA) specification is an abstract model that provides the basis for packaging attachments with a SOAP message. • The SwA specification is designed as a compound document structure that consists of a primary SOAP message part and zero or more secondary attachment parts. • The SwA specification is primarily implemented through Multipurpose Internet Mail Extension (MIME) and Direct Internet Message Encapsulation (DIME).

37. Extensibility Feature in SOAP • SOAP is an extensible protocol because it can be layered with additional functionalities. • SOAP provides extensibility through: • Message handlers • Messaging styles • Encoding styles • Protocol bindings

38. Message Handlers in Web Services • SOAP message traverses between a sender and a receiver along the message path. • SOAP header blocks can be intercepted and processed by message handlers. • SOAP message handlers enable intermediate processing and help extend functionalities.

39. Message Handlers in Web Services (continued) • The SOAP message handlers are defined in the webservices.xml deployment descriptor file, which is stored at the web service endpoint. • A group of handlers form a handler chain. • The handler contains a method for a SOAP request and response. • The handlers intercept either the SOAP request or response message between the client and the server and process SOAP header blocks.

40. Encoding Styles in SOAP • SOAP messages are extensible because they support a variety of data types. • Simple data types, such as string, integer, and boolean, can be directly or literally represented. • Complex data types require an algorithm to determine how the data types are represented in an XML format. • SOAP supports Section 5 encoding or SOAP encoding and literal encoding styles.

41. Type Systems Used by SOAP Encoding: Struct structAllStudent { string sRegNum; string sFirstName; string sLastName; intnAge; }; AllStudent student = {"A108”, "Rob", "Jenkins", 14}; <student xsi:type="x:AllStudent"> <sRegNumxsi:type="xsd:string"> A108 </sRegNum> <sFirstNamexsi:type="xsd:string"> Rob </sFirstName> <sLastNamexsi:type="xsd:string"> Jenkins </sLastName> <nAgexsi:type="xsd:integer"> 14 </nAge> </student>

42. Simple and Compound Types: Array • An array is a compound type. • An array uses ordinal positions to refer to its parts. • The array type is indicated by the xsi:type attribute. • The namespace associated with an array type is http://schemas.xmlsoap.org/soap/encoding. • <numbers xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:integer[5]"> • <item>1</item> • <item>2</item> • <item>3</item> • <item>4</item> • <item>5</item> • </numbers>

43. SOAP Over SMTP, HTTP, and FTP • SMTP can carry a SOAP message that is packaged in a MIME structure. • HTTP is another protocol that is used for transporting SOAP messages. • FTP provides secure messaging because access to FTP servers are authenticated.

44. WSDL Overview • Hosting a web service alone will not help you realize its full potential. You need to describe your web service. The Web Service Definition Language (WSDL) uses XML schema, to organize such information in the form of a WSDL document. You can further use a WSDL document to create a web service client and server.

45. WSDL • Web services need to be described in a standard format. • WSDL provides the language for describing web services. • The latest version of WSDL is available at http://www.w3.org/TR/wsdl. • WSDL defines various components, such as operations, data types, and protocols that can be reused to describe web services in a WSDL document. • A WSDL document specifies the location of a web service and the operations the web service exposes. • A WSDL document represents the external interface of a web service.

46. WSDL Document Structure • A WSDL document uses elements to describe the web services. The root element of a WSDL document is definitions. • The syntax for the definitions element is: • <definitions name=”definitionName” targetNamespace="NamespaceURI"> • where definitionName is the name of the WSDL document and NamespaceURI is the value for the targetNamespace attribute. The targetNamespace attribute specifies the namespace for the names declared within the definitions element. The default namespace is http://www.w3.org/2006/01/wsdl. • In the code example, SchoolLibrary is the name of the WSDL document and http://www.school.com/Library.wsdl is the namespace. <definitions name=”SchoolLibrary” targetNamespace="http://www.school.com/Library.wsdl"> <xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <message> ... </message> <interface> ... </interface> <service> ... </service> <binding> ... </binding> </definitions>

47. Abstract Interface Definition The abstract interface definition provides a generic description of the web services interface. The definition is derived from the following elements: • An interface element interacts with a web service, which is a collection of web services operations. • An operation element represents a web service function that needs to interact with multiple input and output messages. • A message element represents a unit of data that is exchanged in an operation and is represented by the part child element. • A type element specifies the data types used in a message.

48. Abstract Interface Definition: message Element • A unit of data exchanged during an operation is called a message. • A message can be specified by using the message element. • A message can contain one or more input or output parameters, which are defined in the part child element. <definitions name=”SchoolLibrary” targetNamespace="http://www.school.com/Library.wsdl"> <xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <message name="getBookRequest"> <part name="Title" type="xsd:string"/> </message> <message name="getBookResponse"> <part name="return" type="xsd:string"/> </message>

49. Abstract Interface Definition: operation Element • An operation is an interaction between a web service consumer and provider. • An operation is described in an operation element and consists of a set of input and output messages. • The input and output messages are specified using the input and output child elements of the operation element. • where OperationName is the name of the operation and inputMsg and outputMsg are values for the message attribute. • In the code example, getBook is the name of the operation. The values getBookRequest and getBookResponse are names defined in the message element.

50. Abstract Interface Definition: interface Element • The interface element defines the communication pattern for a message. • The communication pattern is made up of a collection of logically related operations that are defined in the operation element. • The syntax for the interface element is: • <interface name=”InterfaceName”> • where InterfaceName is the name of the port or interface. • In the code example, LibInterface is the name of the interface. • <definitions name=”SchoolLibrary” • targetNamespace="http://www.school.com/Library.wsdl"> <xmlns:xsd="http://www.w3.org/2001/XMLSchema"> • <interface name=”LibInterface”> • ... • </interface> • </definitions>