Web Service

Human Centric Web : Focused on static content delivery and user interaction through traditional websites.
Application-centric web : emphasizing rich functionality and interactivity similar to desktop or mobile applications.

What kind of technology support is needed to move from human centric web to application centric web? What mechanisms do we need?

Service discovery mechanisms

A way for the applications that need services to find providers of the services

Service description mechanism

A way for the service clients to know what services providers provide
A way for the providers of the services to describe the services they offer

Common standards

A way for service clients to communicate with service providers
Interoperability support

Web Service

A Web Service is a platform-independent service accessible over the internet or private intranets, enabling software applications to communicate and share resources using standard protocols and technologies.

Core Features of Web Services

Availability Over Networks
- Accessible via the Internet or private networks (e.g., intranets).
Standardized Messaging
- Operates using XML-based messaging systems, ensuring platform and language independence.
Platform and Language Neutrality
- Compatible across various operating systems and programming languages, fostering interoperability.
Resource Sharing
- Exposes software resources and functionalities over networks using standard communication protocols.
Standards-Based Integration
- Web services rely on established standards to enable seamless interactions among devices and applications, forming a cohesive, accessible system.

Properties of Web Services

Self-Describing Web Services

A self-describing web service provides sufficient information for others to understand and integrate with it.

Public Interface:
- When publishing a new web service, it's essential to include a public interface that outlines how to interact with the service.
- This interface should use a common XML grammar if the service employs SOAP, such as WSDL (Web Services Description Language).
Human-Readable Documentation:
- Comprehensive, clear documentation must accompany the web service.
- This documentation enables developers and integrators to easily understand its functionality and requirements.

Discoverable Web Services

A discoverable web service ensures that potential users can find and access it with minimal effort.

Publishing Mechanism:
- A mechanism for announcing the availability of a service is essential.
- The publishing method can range from decentralized approaches (peer-to-peer communication) to centralized registries (e.g., UDDI).
Ease of Discovery:
- Interested users or systems should be able to locate the service quickly.
- Discovery processes might involve querying registries, browsing service directories, or utilizing automated discovery protocols.

Web Service Roles

Three major roles in web services:

Service Provider: provider of the web service.
Service Requestor: any consumer of the web service.
Service Registry: logically centralized directory of services.

Web service protocol stack

Service transport: Responsible for transporting messages. Examples: HTTP, BEEP
XML messaging: Responsible for encoding messages in common XML format. Examples: XML-RPC, SOAP
Service Description: Responsible for describing an interface to a specific web service. Example: WSDL
Service Discovery: Responsible for centralizing services into a common search registry. Example: UDDI.

XML-RPC Example

 
# XML-RPC request
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodCall>
   <methodName>weather.getWeather</methodName>
   <params>
      <param><value>10016</value></param>
   </params>
</methodCall>
 
# XML-RPC Response
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodResponse>
   <params>
      <param>
         <value><int>65</int></value>
      </param>
   </params>
</methodResponse>

SOAP Example

 
# SOAP request
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <SOAP-ENV:Body>
      <ns1:getWeather 
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding/">
         <zipcode xsi:type="xsd:string">10016</zipcode>
      </ns1:getWeather>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
# SOAP Response 
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <SOAP-ENV:Body>
      <ns1:getWeatherResponse
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding/">
         <return xsi:type="xsd:int">65</return>
      </ns1:getWeatherResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Part	Purpose	Optional?
Envelope	Root element, defines message structure and namespaces	No
Header	Contains metadata (e.g., authentication, routing)	Yes
Body	Contains main message content (request/response)	No
Fault	Conveys error details when an issue occurs	Yes

WSDL: Web Service Description Language.

WSDL is an XML grammar for specifying an interface for a web service.
Specifies
- location of web service
- methods that are available by the web service
- data type information for all XML messages
- WSDL is commonly used to describe SOAP services.

 
   <message name="getWeatherRequest">
      <part name="zipcode" type="xsd:string"/>
   </message>
   <message name="getWeatherResponse">
      <part name="temperature" type="xsd:int"/>    # <types>:  What data types will be transmitted?
   </message>
 
   <portType name="Weather_PortType">   # <portType>:  What operations (functions) will be supported?
      <operation name="getWeather">
         <input message="tns:getWeatherRequest"/>  # <message>:  What messages will be transmitted?
         <output message="tns:getWeatherResponse"/>
      </operation>
   </portType>
 
 <service name="Weather_Service">   # <service>:  Where is the service located?
      <documentation>WSDL File for 
     Weather Service</documentation>    
      <port binding="tns:Weather_Binding" name="Weather_Port">   # <binding>:  What SOAP specific details are there?
         	<soap:address location="http://ecerami.com/soap/servlet/rpcrouter"/>
      </port>
   </service>
</definitions>

UDDI: Universal Description, Discovery and Integration.

Represents the discovery layer in the protocol stack.
Originally created by Microsoft, IBM and Ariba.
Technical specification for publishing and finding businesses and web services.
Part I: Technical specification
- specification for building a distributed directory of businesses and services.
- XML format for specifying businesses and services.
- API for querying/publishing to the registry.
Part II: Implementation
- UDDI Business Registry, fully operational implementation of the specification.
- Businesses can publish services here.
- Businesses can discover services here.
- Currently maintained by IBM, Microsoft, etc.

UDDI Data

White Pages: Information about a specific company; name description, address, etc.
Yellow Pages : Classification data for company or service. For example: industry, product or geographic codes.
Green Pages : Technical information about specific services. Pointers to WSDL Files.

XML-RPC

Remote Procedure Call (RPC)

RPC is a protocol or technique used to execute a procedure (subroutine or method) on a remote server as if it were a local procedure call. The key idea is to abstract the complexities of network communication, allowing developers to interact with remote services in a seamless way.

XML-RPC is a simple protocol for carrying out remote proceedure calls (RPC) over TCP/IP
It uses two standards of the internet to create a standard way of calling remote web services and receiving a response
- Hypertext Transfer Protocol (HTTP) as a transport mechanism
- eXtensible Markup Language (XML) to encode it’s calls
XML-RPC offers a very simple, but frequently useful, set of tools for connecting disparate systems and for publishing machine-readable information
XML-RPC on the private network
- Systems integrators and programmers building distributed systems often use XML-RPC as glue code, connecting disparate parts of a private network
- By using XML-RPC, developers can focus on the interfaces between systems, not the protocol used to connect those interfaces.
XML-RPC on the public network
- Developers building public services can use XML-RPC, defining an interface and implementing it in the language of their choice
- Once that service is published to the Web, any XML-RPC capable client can connect to that service, and developers can create their own applications that use that service.
What is XML-RPC
- It’s a specification
- It’s a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the internet
- Its remote procedure calling using HTTP as the transport and XML as the encoding
How XML RPC Works ?
- A client performs an RPC by sending an HTTP request to a server that implements XML-RPC and receives the HTTP response
- A call can have multiple parameters and one result
- The protocol defines a few data types for the parameters and result