Sabri Kızanlık Ural Emekçi WEB SERVICES Sabri Kızanlık Ural Emekçi

Agenda Web Service definition Extensible Markup Language Simple Object Access Protocol WSDL UDDI Service Oriented Architecture

Web Service definition An open standard for accessing component-based applications Core Web services standards include XML, WSDL, SOAP and UDDI Advanced Web services provide support for security, transactions, reliability, business processes, and management Web services evolved from previous technologies that served the same purpose such as RPC, ORPC (DCOM, CORBA and JAVA RMI). Web Services were intended to solve three main problems: Interoperability Firewall traversal Complexity

Service Standards XML – eXtensible Markup Language – A uniform data representation and exchange mechanism. SOAP – Simple Object Access Protocol – A standard way for communication. UDDI – Universal Description, Discovery and Integration specification – A mechanism to register and locate WS based application. WSDL – Web Services Description Language – A standard meta language to described the services offered. XML – eXtensible Markup Language – A uniform data representation and exchange mechanism. SOAP – Simple Object Access Protocol – A standard way for communication. UDDI – Universal Description, Discovery and Integration specification – A mechanism to register and locate WS based application. WSDL – Web Services Description Language – A standard meta language to described the services offered.

Web Services Specifications Communicates via open protocols (HTTP, SMTP, etc.) Processes XML messages framed using SOAP Describes its messages using XML Schema Provides an endpoint description using WSDL Can be discovered using UDDI

An Example Two endpoints: Client & Seller The Client finds the Seller by searching UDDI directory. The Service of Seller is designed using WSDL. The Client gets the service by using SOAP. The Client takes a SOAP reply defined in WSDL. A buyer (which might be a simple client) is ordering goods from a seller service. The buyer finds the seller service by searching the UDDI directory. The seller service is a Web Service whose interface is defined using Web Services Description Language (WSDL). The buyer is invoking the order method on the seller service using Simple Object Access Protocol (SOAP) and the WSDL definition for the seller service. The buyer knows what to expect in the SOAP reply message because this is defined in the WSDL definition for the seller service.

Model The service registry role owns a directory of all of the services available. The service registry represents a new, potentially very lucrative business model. The Registry owner could charge a fee for the use of their directory. Service Providers lists (or advertise) the Service offering in the registry. Service Requesters on the other hand query the service registry about the services available. Once service registry provides the binding information to the requester, it is no longer involved in the communications between the provider and requester. The service registry has been grayed-out as this presentation will focus on the Service Requester - Service Provider interaction. --- The Service Provider has developed services that they make available as Web Service. These services will be hosted on their application server. A service is invoked by a requester through an XML message. These XML messages are generally carried across the Internet through a network-neutral standard protocol called SOAP. The Service Provider describes the service they are making available with a standard encoding called Web Services Description Language (WSDL). ---The Service Requester is the business that requires a certain business function to be fulfilled. From an architectural perspective, this is the application that is looking for (queries the service registry) and then binds to and invokes the service. The requester has to find the service before invoking it - this process of discovery involves accessing a directory where the services are published. The access occurs through a set of standard APIs defined in the UDDI standard. UDDI stands for Universal Description, Discovery and Integration specification.

Extensible Markup Language -1 XML stands for EXtensible Markup Language. XML is a markup language much like HTML. The prefect choice for enabling cross-platform data communication in Web Services.

Extensible Markup Language -2 XML was designed to describe data. XML tags are not predefined. You must define your own tags. Processes XML messages framed using SOAP Describes its messages using XML Schema You can describe your message with XML in a machine readable way that is also human readable. The data is structured and the meaning is embedded in the data itself. This is core to building flexible architectures that deal with a wide range of different systems.

Simple Object Access Protocol Based on XML A simple markup language for describing messages between applications. Mainly transferred via HTTP.

SOAP - Characteristics Extensibility – security and WS-routing, ... Neutrality - SOAP can be used over any transport protocol such as HTTP, SMTP or even TCP. Independency - SOAP allows for any programming model.

SOAP - Building Blocks 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.

SOAP – Request <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding”> <soap:Body xmlns:m="http://www.Bazaar.org/Bazaar">     <m:GetBazaarPrice> <m:Type>Shirt</m:Type>      </m:GetBazaarPrice> </soap:Body> </soap:Envelope>

Soap - Response <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.Bazaar.org/Bazaar"> <m:GetBazaarPriceResponse> <m:Price>34.5</m:Price> </m:GetBazaarPriceResponse> </soap:Body> </soap:Envelope>

WSDL Stands for Web Services Description Language. Based on XML. WSDL specifies what a request message and a response message must contain. A contract between the XML Web service and the client ... In addition to describing message contents, it defines where the service is available and what communications protocol can be used to invoke it.

WSDL - Primary Elements PortType - Defines the abstract interface to the Service. Associated with one or more operations. Message - Defines the information exchanged at the time an operation is executed (input and output). Made of one or more parts. Part – Elemental piece of information in a message (an individual parameter or return value) Types - The data types used by the web service. Binding - The communication protocols used by the web service Port – Identifies the actual location of the service (a URL, a Java class, etc..)

WSDL - Example <message name="GetBazaarPriceRequest"> <part name=“" type="xs:string"/> </message> <message name="GetBazaarPriceResponse"> <part name="value" type="xs:string"/> <portType name=“BazaarsRates"> <operation name=“GetBazaarPrice"> <input message=“GetBazaarPriceRequest"/> <output message=“GetBazaarPriceResponse"/> </operation> </portType>

WSDL & OO Example: a service implemented by a Java class could define one or more operations. Operations would map to individual Java methods, implemented by the class. Messages would map to the return types of the methods, or to their parameter list. Parts would map to the elemental data in the parameter list or the return values.

UDDI

Service Oriented Architecture

Service Oriented Architecture -2 An approach for building distributed systems that deliver application functionality as services to either end-user applications or other services The minimum requirements of an SOA are: – Services – Enterprise service bus (ESB) – Service directory: An organization-level WSDL repository – Internet gateway: Enables internal services to be exposed to the Internet

Value of SOA Build once, use often Interface by contract One place to make one change Lower development, operations and maintenance costs Interface by contract Loosely couples requestor and provider so each can vary independently Integration is explicitly defined and so better understood, at the application and Enterprise level Simplified, agreed, defined data and process flows