Student: Marek A. Lebelt

Computer Networks (CSCI 6731.82)

Professor: Dr. Gertrude N. Levine

Home Work Assignment: 2

Web Services fundamentals

What are web services?

“Web services." That term seems to be on everyone's lips these days.

It is a relatively new approach to exposing and sharing application services over the Web; it is an application that exposes its features programmatically over the Internet or intranet using standard Internet protocols like HTTP and XML. Think of it as component programming over the Web. There are modular and reusable software components that are created by wrapping a business application inside a Web service interface. 

Currently, there are almost as many trends as there are companies when it comes to standards for developing interfaces and markups for Web services; so to define the standards we would wait until the dust clear after the battles.

In defining the neutral Web service we state that it is any service that:

·        Is available over the Internet or private (intranet) networks

·        Uses a standardized XML messaging system

·        Is not tied to anyone operating system or programming language

·        Is self-describing via a common XML grammar

·        Is discoverable via a simple find tool

XML messaging system has several alternatives. The most common used are XML Remote Procedure Calls (XML-RPC)

or SOAP. Ultimately, you could use HTTP GET or HTTP POST to pass arbitrary XML document. Anything of the above can do the work.

A web service should be self-describing. The newly publish web service should have also publish a public interface to the service. At a minimum, your service should include instructive documentation so that other developers can more easily integrate your service. In particular, the SOAP web services should include public interfaces written in XML to identify all public methods, method arguments and return arguments.

A web service should be discoverable. The interested parties should easily locate the published web services and equally easily locate the public interfaces. Truly, centralized registry systems deliver the entire scheme to discover and interface the web services.

Let’s consider an example of two basic models of e-commerce functionality The Human-Centric Web and The Application-Centric Web. The first one is when a human is a primary actor in initiating most web requests. A customer who ordered goods from company e-Sales is trying to find out the status of his order; so he logs on into the e-Sales web site via web browser and receives results as an HTML page response. The second model is when an application is the main actor in web requests and the order status inquiry could be turned into web service application where the applications via agents connect directly to the service and utilize its functionality. The application-centric Web already proved to be successful in such areas as: credit card verification, package tracking, portfolio tracking, currency conversion and language translation.

The idea of application-centric Web is not new. Developers created CGI programs and Java servlets for use by other applications for years. The crucial difference between then and now is that then was an ad hoc solution, now; the web services brought in standardization that should hopefully lower the barrier of application integration. The web services, drastically separated presentation from its content. As an example could serve a site that contains nothing but container pages that pass parameters to the logic via SOAP or XML-RPS. This allows for better maintenance of content of web site. 

Web Service Architecture

Web service architecture should be examined in a view of individual roles of web service actor and the web service protocol stack.

Web Service Roles

There are three major roles within the web service architecture:

This is the provider of the web service. The service provider implements the service and makes it available on the Internet.

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

Web Service Protocol Stack

However the protocol stack still I evolving we can single out four main layers; Service transport, XML messaging, Service description and Service discovery.

XML Messaging

XML since it introduction has gained wide acceptance of developers’ community because it enables diverse computer systems to share data more easily, regardless of operating system or programming language.

XML tools like parsers and editors are available for nearly every operating system and programming language including Java, Perl, Python, C#, C++, and Ruby. There are two main contenders of XML messaging: XML-RPC and SOAP.


XML-RPC is a simple protocol that uses XML messages to perform RPCs. Requests are encoded in XML and sent via HTTP POST. XML responses are embedded in the body of the HTTP response. Because XML-RPC is platform-independent, it allows diverse applications to communicate over the Internet. For example, a Java client can speak XML-RPC to a Perl server. XML-RPC is the easiest way to get started with web services. In many ways it is simpler than SOAP and easier to adopt. However, unlike SOAP, XML RPC has no corresponding service description grammar. This prevents automatic invocation of XML-RPC services a key ingredient for enabling just-in-time application integration.

We want look at a simple weather service code to understand

XML-RPC. The code accepts a zip code (10016) and returns the current temperature in the area.


Here is a sample XML-RPC request to the weather service (HTTP headers omitted):


Here is a sample XML-RPC response from the weather service:

The response consists of a single methodResponse element that specifies the return value. In this case, the return value is specified as an integer 65.

SOAP (Simple Object Access Protocol)

SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems, and can be delivered via a variety of transport protocols, the main focus of SOAP is RPCs transported via HTTP. Like XML-RPC, SOAP is platform-independent and therefore enables diverse applications to communicate.

SOAP sample code for weather service request (HTTP headers omitted):

Here is a sample SOAP response from the weather service. The response indicates a single integer return value 65.

The SOAP request is slightly more complicated than the XML-RPC request. It makes use of both XML namespaces and XML Schemas. As in XML-RPC, however, the body of the SOAP request specifies both a method name and a list of parameters.

Service Description: WSDL

WSDL currently represents the service description layer within the web service protocol stack. In a nutshell, WSDL is an XML grammar for specifying a public interface for a web service. This public interface can include information on all publicly available functions, data type information for all XML messages, binding information about the specific transport protocol to be used, and address information for locating the specified service. WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.

This WSDL file describes the public interface for the weather service we examined previously. Let's, just focus on two points. First, the message elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the service element specifies that the service is available via SOAP.

Example of WeatherService.wsdl

Using WSDL, a client can locate a web service and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code.

Service Discovery: UDDI

UDDI currently represents the discovery layer within the web service protocol stack. UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and web services.

At its core, UDDI consists of two parts.

The information captured within UDDI is divided into three main categories:

White pages

This category includes general information about a specific company; for example, business name, business description, and address.

Yellow pages

This category includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.

Green pages

This category includes technical information about a web service

(a pointer to an external specification and an address for invoking the web service). 

Service Transport

The bottom of the web service protocol stack is service transport. This layer is responsible for actually transporting XML messages between two computers.


HTTP is simple, stable, and widely deployed. Furthermore, most firewalls allow HTTP traffic. This allows XML-RPC or SOAP messages to masquerade as HTTP messages. This is good if you want to easily integrate remote applications, but it does raise a number of security concerns. 

While HTTP does get the job done, a number of critics have argued that HTTP is not ideal for web services. In particular, HTTP was originally designed for remote document retrieval, and is now being reworked to support RPCs. RPCs demand greater efficiency and reliability than document retrieval does.


One promising alternative to HTTP is the Blocks Extensible Exchange Protocol (BEEP). BEEP is a new IETF framework of best practices for building new protocols. In particular, BEEP is layered directly on TCP and includes a number of built-in features, including an initial handshake protocol, authentication, security, and error handling. Using BEEP, one can create new protocols for a variety of applications, including instant messaging, file transfer, content syndication, and network management.

SOAP is not tied to any specific transport protocol. In fact, you can use SOAP via HTTP, SMTP, or FTP. One promising idea is therefore to use SOAP over BEEP. Doing so provides several performance advantages over HTTP. Specifically, BEEP does require an initial handshake, but after the handshake, the protocol requires only 30 bytes of overhead for each message, making it much more efficient than HTTP. The overhead for each HTTP message is dependent on numerous factors, including the requested URL, the type of client used, and the type of server information returned within the HTTP response. Overhead for typical browser and SOAP requests can therefore vary from approximately 100 to 300 bytes for each message. Furthermore, BEEP supports multiple channels of data over the same connection, providing extra efficiency over HTTP.


Another promising alternative to HTTP is Reliable HTTP (HTTP-R). HTTP-R is being developed by IBM, which plans to submit its proposal to the Internet Engineering Task Force (IETF). HTTP-R enhances HTTP to ensure message reliability. For example, HTTP-R ensures that a message gets delivered only once or gets reported as undeliverable. This is particularly critical for e-commerce services, such as electronic ordering systems and inventory management.

Security Considerations

Security is critical to web services. However, neither the XML-RPC nor SOAP specifications make any explicit security or authentication requirements. Furthermore, the web services community has proposed numerous security frameworks and protocols, but has yet to reach consensus on a comprehensive security package.

We can single out there are three specific security issues: confidentiality, authentication, and network security.


If a client sends an XML request to a server, can we ensure that the communication remains confidential?

Fortunately, both XML-RPC and SOAP run primarily on top of HTTP, and XML communications can therefore be encrypted via the Secure Sockets Layer (SSL). SSL is a proven technology, is widely deployed, and is therefore a very viable option for encrypting messages.

However, a key element of web services is that a single web service may consist of a chain of applications. For example, one large service might tie together the services of three other applications. In this case, SSL is not adequate; the messages need to be encrypted at each node along the service path, and each node represents a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue, but one promising solution is the W3C XML Encryption Standard. This standard provides a framework for encrypting and decrypting entire XML documents or just portions of an XML document, and it is likely to receive widespread industry support.


If a client connects to a web service, how do we identify the user? And is the user authorized to use the service?

One solution is to leverage HTTP authentication. HTTP includes built-in support for Basic and Digest authentication, and services can therefore be protected in much the same manner as HTML documents are currently protected. Most security experts, however, agree that HTTP authentication is a relatively weak option.

As with encryption, there is no clear consensus on a strong authentication scheme, but there are several frameworks under consideration. The first is SOAP Security Extensions: Digital Signature (SOAP-DSIG). DSIG leverages public key cryptography to digitally sign SOAP messages. This enables the client or server to validate the identity of the other party.

Second, the Organization for the Advancement of Structured Information Standards (OASIS) is working on the Security Assertion Markup Language (SAML). SAML is designed to facilitate the exchange of authentication and authorization information between business partners.

In a related effort, several companies have put forth the XML Key Management Services (XKMS). XKMS defines a series of services for distributing and managing public keys and certificates. The protocol itself is built on SOAP and WSDL, and it is therefore an excellent example of a web service.

Network Security

Extending HTTP via SOAP enables remote clients to invoke commands and procedures, something that firewalls are explicitly designed to prevent.

You could argue that CGI applications and servlets present the same security vulnerabilities. After all, these programs also enable remote applications to invoke commands and procedures. There is currently no easy answer to this problem, and it has been the subject of much debate. For now, if you are truly intent on filtering out SOAP or XML- RPC messages, one possibility is to filter out all HTTP POST requests that set their content type to text/xml

(a requirement of both specifications). Another alternative is to filter for the SOAP Action HTTP header attribute. Firewall vendors are also currently developing tools explicitly designed to filter web service traffic.

All fit together

Once you understand each layer in the web service protocol stack, the next important step is to understand how all the pieces fit together. There are two ways of approaching the issue, either from the service requestor perspective or the service provider perspective.

Service Request Perspective

The service requestor is any consumer of web services. Here is a typical development plan for a service requestor:

  1. First, you must identify and discover those services that are relevant to your application. This first step therefore usually involves searching the UDDI Business Directory for partners and services.
  1. Once you have identified the service you want, the next step is to locate a service description. If this is a SOAP service, you are likely to find a WSDL document. If this is an XML-RPC service, you are likely to find some human-readable instructions for integration.
  1. Third, you must create a client application. For example, you may create an XML-RPC or SOAP client in the language of your choice. If the service has a WSDL file, you also have the option of automatically creating client code via a WSDL invocation tool.
  1. Finally, run your client application to actually invoke the web service.

Service Provider Perspective

The service provider is any provider of one or more web services. Here is a typical development plan for a service provider:

  1. First, you must develop the core functionality of your service. This is usually the hardest part, as your application may connect to databases, Enterprise ]avaBeans (EJBs), COM objects, or legacy applications.
  1. Second, you must develop a service wrapper to your core functionality.    This could be an XML-RPC or a SOAP service wrapper. This is usually a relatively simple step, as you are merely wrapping existing functionality into a larger framework.
  1. Next, you should provide a service description. If you are creating a SOAP application, you should create a WSDL file. If you are creating an XML-RPC service, you should consider creating some human-readable instructions.
  1. Fourth, you need to deploy the service. Depending on your needs, this could mean installing and running a standalone server or integrating with an existing web server.
  1. Fifth, you need to publish the existence and specifications of your new service. This usually means publishing data to a global UDDI directory or perhaps a private UDDI directory specific to your company.

Standards and Coherence

The most crucial elements to the long-term success of web services will be standardization and the coherency of those standards. SOAP and WSDL have both been submitted to the W3C, but have no official recommendation status. XML-RPC has not been submitted to any standards body. UDDI is currently under the review of an industry consortium and will probably go through several more iterations before being handed over to a standards body.

In September 2000, the W3C created an XML Protocol Group.  This group represented the W3C's first official foray into the world of web services. Its first task was to create an official recommendation for SOAP, and the group is currently finalizing a SOAP 1.2 specification. In January 2002, the W3C incorporated the XML Protocol Group into a more general Web Services Activity. The new Activity adds Working Groups for Web Services Architecture and Web Services Description.

Standardizing each layer in the web service protocol stack will be a major challenge. Making sure all the layers fit together and make coherent sense to developers will be an even greater challenge.