1. Topic 6: Web Services Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine

2. Outline 6.1: Introduction 6.2: Web Service in context 6.3: Web Service Architecture 6.4: Web Service Definition Language 6.5: Universal Description, Discovery and Integration 6.6 Simple Object Access Protocol

3. 6.1 Introduction  What are Web Services? Today, we normally use Web browsers to talk to Web sites Browser names document via URL (lots of fun and games can happen here) Request and reply encoded in HTML, using HTTP to issue request to the site Web Services generalize this model so that computers can talk to computers. Web services are open standard (XML, SOAP, HTTP etc.) based Web applications that interact with other web applications for the purpose of exchanging data.

4. 6.1 Introduction  Web Service Definition: “A web service is any piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service.” “Web services are self-contained, modular, distributed, dynamic applications that can be described, published, located, or invoked over the network to create products, processes, and supply chains. These applications can be local, distributed, or web-based. Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.” “Web services are XML-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents.”

5. 6.1 Introduction  Web Service Definition: To summarize, a complete web service is, therefore, any service that: Is available over the Internet or private (intranet) networks. Uses a standardized XML messaging system. Is not tied to any one operating system or programming language. Is self-describing via a common XML grammar. Is discoverable via a simple find mechanism.

6. 6.2 Web Service in Context

8.  Is this a Web Service?

9. 6.2 Web Service in Context  Web-base Services: Services offered through a Web site. provide the user with a GUI.  Web Services: Services offered through Web-wide standardized protocols. Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface

10. 6.2 Web Service in Context  Extending the Web with Services:

11. 6.2 Web Service in Context

12.  Services and Components: What is a component? What is a service? Component Based Software Engineering (CBSE). Define system architectures in terms of the dependencies connecting a set of reusable components. Service Oriented Architectures (SOA). The architecture of a distributed system is defined in terms of the interactions among its component services.

13. 6.2 Web Service in Context  Components: Software components are reusable. To be used a component must: be packaged to be deployed as part of some larger application system. fit with the existing framework used to develop the system Components can be sold. Component developers charge on a per-deployment basis: whenever a new client downloads the component. There are many component frameworks available for building distributed systems (e.g., J2EE, DCOM,.NET). The problem is: they are not compatible

14. 6.2 Web Service in Context  Web Services are Components: Web Services are reusable too. To be used a Service must: be published on the Web (once). advertise its description and location to potential clients across the Web so that they can access it using standard protocols. Web service can be sold too. Service providers can charge on a per-call basis: each timean existing client interacts with a service by exchanging a new message. Like components, Web services can be reused, composed into larger systems and (of course) they can be found on the Web. Unlike components, Web services do not have to be downloaded and deployed in order to be used by clients. Instead, a client may discover and access their functionality by using standard protocols (WSDL, SOAP, UDDI) based on XML.

15. 6.2 Web Service in Context  Component Interoperability: Due to lack of interoperability, it is not always possible to build a distributed system using heterogeneous components

16. 6.2 Web Service in Context  Component Interoperability: If the components are published as Web services, they can interoperate across different component frameworks. (Interoperability through Wrapping).

17. 6.2 Web Service in Context

18.  Distributed Systems & Web Services: Web services provide standards for developing large scale distributed systems. One example: “the Grid” is adopting Web services as standard protocols to build a distributed infrastructure for utility based computing. Web services on the path of success while CORBA distributed objects failed (This is nothing technical, only a matter of widespread industry acceptance)

19. 6.2 Web Service in Context

20.  Middleware: Middleware is just a level of indirection between clients and other layers of the system. It introduces an additional layer of business logic encompassing all underlying systems. By doing this, a middleware system: simplifies the design of the clients by reducing the number of interfaces, provides transparent access to the underlying systems, acts as the platform for intersystem functionality and high level application logic, and takes care of locating resources, accessing them, and gathering results. But a middleware system is just a system like any other! It can also be 1 tier, 2 tier, 3 tier...

21. 6.2 Web Service in Context  Limitations of Middleware: Non-standard interfaces. Traditional middleware systems and tools suffer from lack of standardization: they are not compatible. Thus, it is very expensive to build integrated distributed systems across different middleware platforms. Lack of trust. With Services the internal “API” of a company is exposed to the Internet. How to trust the clients? Building integrated systems spawning across different trust domains can be difficult. Middleware systems are (logically) centralized. Thus, there is no place for them in B2B Integration scenarios as they should be distributed across all partners. Point to Point integration does not scale. Interactions across organizational boundaries may be slow and should be handled asynchronously.

22. 6.2 Web Service in Context  Limitations of Middleware:

23. 6.2 Web Service in Context  Limitations of Middleware:

24. 6.2 Web Service in Context  Limitations of Middleware:

25. 6.2 Web Service in Context  Web Services for integration:

26. 6.2 Web Service in Context  Web Services and Middleware: Web Services can be seen as the natural evolution of existing Middleware systems. Web Services standards enable the interoperability of existing Middleware platforms and tools Enterprise Application Integration made easier by using Web Services. Business to Business integration enabled by common interface standards.

27. 6.3 Service Oriented Architecture  SOA Technologies : Web Services involve three major roles Service Provider Service Registry Service Consumer Three major operations surround web services Publishing – making a service available Finding – locating web services Binding – using web services

28. 6.3 Web Service Architecture  Making a service available : In order for someone to use your service they have to know about it. To allow users to discover a service it is published to a registry (UDDI). To allow users to interact with a service you must publish a description of it’s interface (methods & arguments). This is done using WSDL.

29. 6.3 Web Service Architecture  Making a service available : Once you have published a description of your service you must have a host set up to serve it. A web server is often used to deliver services (although custom application – application communication is also possible). This is functionality which has to be added to the web server. In the case of the apache web server a ‘container’ application (Tomcat) can be used to make the application (servlet) available to apache (deploying).

30. 6.3 Web Service Architecture UDDI Registry WSDL Web Service SOAP Service Consumer Points to description Points to service Describes Service Finds Service Communicates with XML Messages

31. 6.3 Web Service Architecture  The Web Services Trinity: A Contract Definition Language Web Service Description Language (WSDL). Standardized Look-up Universal Description Discovery and Integration (UDDI) Interoperability standards Simple Object Access Protocol (SOAP). Publish/Find/Bind - Web Services are published and located via the UDDI, they are described using WSDL and are invoked using SOAP over HTTP Demo: http://www.soapclient.com/

32. 6.3 Web Service Architecture  Publish/Find/Bind Model: 1.The service provider publishes its service(s) to a service registry such as UDDI in the form of a WSDL document. 2.The service requestor finds services for consumption via service registries and this process is also called “service discovery.” 3.Once the service requestor has acquired the service information, it can attempt to bind to the service and use it.

33. 6.3 Web Service Architecture  Use of SOA : Internet Supplier Buyer E-Retailer Get Quote Reservation Purchase Order Publishing of business functions by means of API Web pages for humans (B2C) Web services for program to program (B2B) A programmable application component accessible via standard Web protocols Bank

34. 6.3 Web Service Architecture  More SOA Scenario: RPC Supplier J2EE Bank COM Logistic Company Internet SOAP Web Service Order Fulfillment Web Service Shipping Order Web Service Credit Card Check Shop Application Web Service E-Retailer

35. 6.3 Web Service Architecture  SOA Communication Infrastructure : Reproduced with the kind permission of John McGuire Cape Clear Software Web Service Broker Web Service Provider Publish Service Description Get Service Description Discover Service Use Service based on Service Description

36. 6.3 Web Service Architecture  Traditional RPC vs Web Services: Traditional RPC Within enterprise Tied to a set of programming languages Procedural Usually bound to a particular transport Tightly-coupled Firewall-unfriendly Efficient processing Web Services Between enterprises Program language independent Message-driven Easily bound to different transports Loosely-coupled Firewall-friendly Relatively not efficient processing

37. 6.3 Web Service Architecture  Web Applications vs Web Services: Web Application User-to-program interaction Static integration of components Monolithic service Ad hoc or proprietary protocol Web Services Program-to-program interaction Dynamic integration of components Service aggregation Interoperability

38. 6.3 Web Service Architecture  SOA Favourable Properties: Loosely-coupled: Web services can run independently of each other on entirely different implementation platforms and run- time environments. Encapsulated: The only visible part of a Web service is the public interface, e.g., WSDL and SOAP. Standard Protocols and Data Formats: The interfaces are based on a set of standards, e.g., XML, WSDL, SOAP, UDDI and etc. Invoked Over Intranet or Internet: Web services can be executed within or outside the firewall. Components: The composition of Web services can enable business-to-business transactions or connect the internal systems of separate companies, such as workflow. Workflow is a computer supported business process. Business Oriented: Web services are not end-user software!

39. 6.3 Web Service Architecture  Why SOA? - Summary: SOA allows us to share processes over the Internet independent of platform, tools, or technology Anyone, anywhere, any device, anytime It is a better integration solution for process sharing Applications become services Services are accessible Services enable integration B2B It will create new business models that we have yet to conceive Services can be assembled and reused Based on open standards: XML and SOAP “Plug and Play” applications

40. 6.4 WSDL - Web Services Description Language  Introduction: In the format of XML document Describes a Web Service (three fundamental properties ): What it does Operations (methods) provided by the service How to communicate with it Data format and protocol details Where to find it Address (URL) details Invented by Ariba, IBM, Microsoft Version 1.1 to W3C, March 2001 The intent was to create something that worked Extensible - not something complete Creating a formal Web Services “data model” was not a priority W3C standardization (to version 2.0) in progress http://www.w3.org/2002/ws/ Example tool support: XMLspy Tutorial: http://www.w3schools.com/wsdl/default.asp

41. 6.4 WSDL - Web Services Description Language  WSDL Components: Types Based on XML Schema type system Message formats Parts represent method parameters Port Types Set of operations Parameter order Input and output messages Bindings Map a Port Type to a specific protocol, using a specific data encoding style Services Set of ports that implement port types Access point for each port

42. 6.4 WSDL - Web Services Description Language … Definition of data types Definition of messages Definition of port type Definition of the bindings Definition of the service

43. 6.5 Universal Description, Discovery and Integration (UDDI)  SOA Favourable Properties: Registry for Web services Has a Web Services API for publishing and discovering the existence of Web services A registry where you find a Web service and its description (WSDL) Search by business Search by service type A coalition of organizations working together to manage UDDI registries and to further develop the Web Services API for accessing those registries. Joint Initiative –uddi.org By Ariba Inc., IBM Corp. and Microsoft Corp. An open uddi community to support the development of uddi UDDI Business Registries: Microsoft, IBM, SAP, NTT-Com

44. 6.5 Universal Description, Discovery and Integration (UDDI)  UDDI Advantages: 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

45. 6.5 Universal Description, Discovery and Integration (UDDI)  A UDDI Registry : Who? Basic business information Name, contact information What? Get classification Standard Industry Codes, NA Industry Code Std Where? Service URI How? Describes a how a given interface functions

46. 6.5 Universal Description, Discovery and Integration (UDDI)  UDDI Data Structures: businessEntity: Basic business information Used by UDDI for “yellow” pages businessService: Services provided by that business Grouping of related businesses bindingTemplate: What the service looks like (tModel element) Where to access the service

47. 6.5 Universal Description, Discovery and Integration (UDDI)  UDDI Data Structures: tModel Technology model A tModel is a data structure representing a service type (a generic representation of a registered service) in the UDDI. Could contain just about anything Has service details Abstract industry specs Service specs Designed to be reusable Can contain pointer to WSDL document

48. 6.5 Universal Description, Discovery and Integration (UDDI)  Query Pattern: Browse: UDDI yellow page data has hierarchy Search via Web/standalon e client app

49. 6.5 Universal Description, Discovery and Integration (UDDI)  tModel Details:

50. 6.5 Universal Description, Discovery and Integration (UDDI)  tModel Details:

51. 6.6 Simple Object Access Protocol (SOAP)  SOAP: Standard object invocation protocol Peer-to-peer interaction in a distributed environment Built on HTTP and XML standards Unprecedented support platform and language independent Simple and extensible Allows you to get around firewalls Tutorial: http://www.w3schools.com/soap/default.asp SOAP 1.2 http://www.w3schools.com/soap/default.asp http://www.w3.org/2000/xp/Group/

52. 6.6 Simple Object Access Protocol (SOAP)  Why SOAP? It is important for application development to allow Internet communication between programs. Today's 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. HTTP is a common binding transport protocol for SOAP nowadays SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

53. 6.6 Simple Object Access Protocol (SOAP)  Soap Message Structure: Envelope - defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory Header (optional) Body - contains call and response information Fault element in body - provides information about errors that occurred while processing the message  Mechanism to send XML messages Consistent envelope - Header and body Consistent data encoding - Based on XML Schema type system Protocol binding framework  SOAP encoding rules defines a serialization mechanism that can be used to exchange instances of application-defined objects  Provides the interface to a Web Service Document style RPC style

54. 6.6 Simple Object Access Protocol (SOAP)  SOAP Skeleton in XML: <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">... …......

55. 6.6 Simple Object Access Protocol (SOAP)  SOAP Communications for SOA: Partner BearCom Internet Client Web Service Request For WSDL (if not having that or unsure) WSDL Listener SOAP Request (In) SOAP Response (Out) Proxy Stub Stub

56. 6.6 Simple Object Access Protocol (SOAP)  Positioning with Other Technologies: Compatible with/complimentary to: J2EE CORBA Web servers Application servers Legacy applications Rules engines SOAP provides a new interface to existing systems