Web Services: Background and Implementation

Introduction

There are numerous papers around in the net that explains the usage of Web Services, but quite a few papers which have all the theoretical details of Web Services plus their implementation.

In this paper, I am concentrating on the detail background: technologies prior to Web Services and their disadvantages, technologies that enable Web Services to be more flexible, and finally, how Web Services solve the issues confronting older technologies.

Since it got a bit lengthy, I divided it into Parts 1 and 2. In Part 2, I will include the details of the implementation of Web Services using C#.

Background

Application integration is one of the most important issues that is facing information systems nowadays. Application integration is the mechanism that enables different software systems to share and use information. Application integration helps businesses to run smoothly. Any break down of information may cause process break down, and eventually lose of money. Effective application integration facilitates both tactical and strategic decisions. Web Services help application integration.

What makes application integration hard?

In simple terms, the heterogeneity of the platforms in which the applications are developed. Organisations are developing different application systems within different time and technologies, and this heterogeneity makes the process of communication hard. Most third party applications are not merely designed to communicate with other applications, and it requires a lot of effort, time, and eventually money to enable data integration among these applications.

Types of application integration

Data level application integration: this is the basic way of application integration. In this method, applications basically share the same database. However, this method of integration is not very helpful as it can be used only for reading purposes. Also, in this approach, business logic which handles the business processes of the organisation are not shared among applications. So there is always the risk of violating the business rules.

A much better approach is application level integration. In this method, an application makes its information and its business logic available to other applications through APIs or Application Programming Interfaces. API is a mechanism that enables an application to expose its functions to other applications. Web Services help build platform independent APIs.

If an application requires to exposes its functionalities to the outside world over the network, we usually need to build some kind of middleware to achieve this goal of network-enabled-API. Middleware are software applications that sit between one application and the underlying platform, and provide core system facilities, e.g., network, storage, processor etc. Communication middleware are the ones that enable applications to talk to each other over the network. The biggest issues using middleware are that they are platform dependent, programming language dependent, and network protocol dependent.

Moreover, traditional middleware store data in the form of binary format, and even the format each one saves the data as are different from each other. Therefore, communication among these middleware gets complicated. Web Services solve these issues.

Types of middleware

Basically, there are two styles of communication. Applications can communicate either via message passing (Message Oriented Middleware) or by invoking functions (RPC Middleware). These were the traditional middleware prior to Web Services. Web Services support both methods of communication.

Message Oriented Middleware

There are a number of MOM middleware including IBM Websphere, Microsoft MQ etc.; however, the biggest problem is that each product uses a special communication protocol that is not useable by other. MSMQ is only usable in the Windows platform while IBM Websphere can be used both in Windows and UNIX; however, both applications need to have the same MOM, and also the license fees are getting too expensive.

RPC Middleware

RPC or Remote Procedure Call uses the client server style of communication where one application acts as the server and the other as the client. The client requests the server for specific information. Some examples of RPC style middleware are MS Distributed Component Object (DCOM), OMG's Common Object Request Broker Architecture (CORBA), Open Network Computing (ONC RPC) etc. However, the biggest challenge here is that it is very hard to find a unique RPC middleware to support all the programming languages and all the platforms in a reasonable price. DCOM works only in Windows; UNIX has built in functionality for ONC, however, very rarely used in Windows. Possibly, CORBA might be the only option for UNIX and Windows platforms, but Microsoft tools, e.g., Visual Basic, don't provide any support for CORBA, and therefore makes it hard to use.

Traditional middleware problems

• Traditional middleware doesn't support heterogeneous platforms.
• Traditional middleware doesn't work over the internet easily.
• Traditional middleware are hard to use, and therefore needs a lot of expertise both in the application domain and middleware experience.
• Traditional middleware get really complex when the number of systems to be integrated gets more complex.
• Traditional middleware are expensive to use. You have to pay to use it for every system.
• Traditional middleware maintenance cost is high as small changes can cause many problems and changes in the middleware.
• Traditional middleware are hard to reuse as they are very fragile code and data type specific.

Born of Web Services

What is a Web Service?

There is not any unified description for Web Services. However, the best descriptions I have found are:

• "Web Service is an application that provides a web API. A web API is an API that lets other application systems to communicate with it using XML and web". [1]
• By UDDI: "Web Services are a self-contained, modular business applications that have open, internet-oriented, standards-based interfaces". [2]
• By W3C: "A software application identified by a URL, whose interfaces and bindings are capable of being defined, described, and discovered as XML artefacts. A Web Service supports direct interactions with other software agents using XML based messages exchanged via internet based protocols".

Possibly, the last description by W3C is more complete.

In simpler terms, if I combine all the above descriptions, we can get a more detailed description as: A Web Service is a service-oriented web application that provides a web API (interface) that is well defined using an XML based document WSDL (Web Service Description Language), and enables other applications to bind to it via URLs and internet based protocols, and communicate to using XML based messages using SOAP.

To understand this description fully, let us consider the details of all the technologies used to make Web Services.

Web Service Technologies

As per Web Service description, it is a Service-Oriented web application that communicates using XML. All the technologies used to define Web Services are included in this description: Web, XML, and Service Oriented Architecture (SOA).

Web is a global information system that is used for the purpose of communication, and relies on the internet and internet technologies, including internet protocols HTTP, SMTP, DNS, and URLs. XML is a programming language to represent electronic documents in a structured way. Even though Service Oriented Architecture is not something totally new as most of the RPC based middleware use this architecture to communicate, the technologies that are used to provide SOA for Web Services are new, and therefore make Web Services more flexible and platform free.

So What is SOA?

SOA is an architecture that is based on three roles: a Provider who provides the service, a Consumer who uses the service, and a Service Broker which facilitates the advertising and finding of the service. The three basic functions of this architecture are: Register, Find, and Bind. Provider, the code that provides the service, registers its service with a Service Broker. Service Broker creates a contract which defines all the details of the Provider and the service. The Consumer finds the services via the Service Broker, and binds to the Provider using the contract and communicates.

The main technologies that are used in SOA (WSDL, UDDI, and SOAP) are described below:

WSDL (Web Service Description Language)

This is the XML language that describes the Web Service. WSDL is an XML document that provides information about what the Web Service does, where to find it, and how it works. WSDL can be compiled to provide the code (client proxy) to connect to a Web Service.

The elements of WSDL documents fall into two main categories:

• Abstract Description which describes the interface of the Web Service, and its operations, including the input and output parameters.
• Type Elements: lists all the data types that are used by the XML messages as input or output.
• <Message> element: describes the details of the SOAP message. It can have multiple parts, e.g., Input, Output. Message is equivalent of the parameters of a function. Let's say, if we have a method with two input parameters, then the equivalent <message> elements will have two <part> elements as input.
• <Operations> element: This is the equivalent of the method definition, and provides the details of input and output of the operations of the Web Service.
• <PortType> element: A high level description of operations of the Web Service. It is more like an interface that lists all the operations or methods provided by the Web Service.

If we look at the above elements in hierarchical order, a <porttype> is a collection of <operations>, <operations> is a collection of <message>s, and in turn, <message> can be a collection of types.

• Concrete Implementation that provides details of how to physically bind to Web Services.
• <Binding> element: lists the protocols that can be used to communicate with a Web Service, and also the address of the Web Service, i.e., the namespace it is located in. <Binding> is linked with a specific <PortType>. A binding corresponds to a PortType implemented using a particular protocol such as SOAP. If the service supports more than one protocol, the WSDL includes a binding for each.
• <Port> element: provides the URL where the Web Service is located, and it implements a <binding> element.
• <Service> element: is a collection of one or more <port>s.

UDDI (Universal Discovery, Description, and Integration)

This is a Web Service registry, and it facilitates the process of advertising and discovery of a Web Service. It manages information about service types and provider types. UDDI is a Web Service itself. UDDI is mainly used during development time. It can be used to find a service and bind to, or it can be used at runtime programmatically. UDDI contains the following information:

• Businesses and other service providers.
• Services they will expose.
• Binding information (locations) of those services
• Interfaces supported by those services.

One of the major purposes of UDDI is to provide an API for publishing and retrieving information about Web Services. The operations can be invoked by a SOAP call to the exposed methods of a certain Web Service.

SOAP (Simple Object Access Protocol)

It is an XML protocol that is used to communicate with a Web Service. It provides a mechanism that allows one application to communicate with another application using XML.

SOAP is similar to a shipment box for the XML message. It encapsulates the message, and enables it to be shipped over the network. As a shipment box can be transported over via different means including airplane, ship, car, etc., a SOAP encapsulated message can be transferred via different web protocols including HTTP, SMTP, and FTP.

How a Web Service Solves the Classical Middleware Problems?

The technologies that are used enable a Web Service to solve most of the issues of traditional middleware.

A Web Service provides a Web API using internet and SOAP which is based on XML messages using internet protocols, which is much more flexible and easy to bind and less delicate compared to traditional middleware.

Furthermore, a Web Service is a special addition to middleware that uses internet to provide interfaces to other applications. A Web Service uses standard internet protocols including HTTP, SMTP, and these protocols are designed to work over the internet and with firewalls etc. It solves the issues of costs attached by using traditional middleware as internet is free, and the technologies used are supported by most of the manufactures as free.

XML makes Web Services flexible and adaptable. Since Web Service messages are based on the XML technology which is basically text based, it makes it platform, language, and vender independent. It resolves the biggest challenge that traditional middleware have to face due to heterogeneity of platforms and languages, and therefore makes it the best technology to be used for application integrations.

History

In part two of this paper, I will explain the creation and implementation of Web Services using C#.

Conclusion

In this paper, I explained Application Integration which is one of the biggest challenges of IS nowadays, and the problems that make application integration hard, including platform and development language heterogeneity. Therefore, we need some kind of middle man to resolve these issues. Middleware are components or software that enable us to provide some kind of interface or API to other applications and enable them to communicate with among. However, there are many problems involved with these traditional middleware including heterogeneous platforms, heterogeneous programming, hardship of maintenance, hard to link to internet, reusability problems, and finally high cost. All these issues make traditional middleware hard to use and maintain. These are the reasons that caused Web Services to be born.

Finally, I explained Web Services, and the technologies involved including XML, Web, and SOA. I also explained these technologies and how these technologies enable Web Services to solve most of the traditional middleware issues.

References

• Anne T Manes, 2003, Web Services, a manager's guide, Boston: Addison-Wesley.
• Jeffrey Hasan, 2004, Export service oriented architecture in C#, USA: Apress.

• [1] Web Services, a manager's guide
• [2] Export service oriented architecture in C#