Web services, background and implementation

Introduction

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

In this paper, I am concentrating on detail background, technologies prior to web services and their disadvantages, technologies that enables web services to be more flexible, and finally how web services solves the issues confronting older technologies.

Since it got bit lengthy I divide it into part 1 and 2. In part 2, I will include the details of implementation of web services using C#.

Background

Application integration is one of the most important issues that is facing information system now a days. 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 loose of money. Effective, application integrations facilitates both tactical and strategic decisions. Web services help application integration.

What makes application integration hard?

Simple terms, heterogeneity of the platforms 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 of the 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 integrations:

Data level application integration, this is the basic way application integration. In this method, applications basically share the same database. However this method of integration is not very helpful as it cannot be used only for reading purposes. Also in this approach, business logic which handles 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 API or Application Programming Interface. API is a mechanism that enables an application to exposes its functions to other applications. Web services help to build platform independent APIs.

 If an application requires to exposes its functionalities to 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 application that are sitting between one application and underlying platform and provides core system facilities eg 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 are different than the other. Therefore, communication among these middlewares gets complicated. Web services solve these issues.

Type of Middlewares:

Basically there are mainly two styles of communications. Applications can communicate either via message passing (Message Oriented Middleware) or by invoking functions (RPC Middleware). These are traditional middleware prior to web services. Web services support both methods of communications.

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. MS MQ only usable in windows platform while IBM Websphere can be used both in windows and UNIX however both application needs to have same MOM and also the licence fees are getting too expensive.

RPC Middleware:

RPC or Remote Procedure Call is using client server style of communication where one application acts as server and other as 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 platform but Microsoft tools eg Visual Basic doesn’t provide any support for CORBA and therefore makes it hard to use.

Traditional Middleware problems:

• Traditional middleware doesn’t support heterogynous 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 application domain and middleware experience.

• Traditional middleware are getting 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 and application that provides web API. A web API is an API that lets other applications systems to communicate with it using XML and web”. [1]

• By UDDI: “Web service is 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 description, we can get a more detailed description as: web service is a service-oriented web application that provides web API (interface) that is well defined using an XML based document WSDL (Web Service Description Language) and enable 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 is considering 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 purpose of communication and relies on 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 uses this architecture to communicate, the technologies that are used to provide SOA for web service are new and therefore make web service more flexible and platform free.

So what is SOA?

SOA is an architecture that is based on three roles: Provider who provides the service, Consumer who uses the service and 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 is registering 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 service broker and binds to provider using the contract and communicates.

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

WSDL (Web Service Description Language)

This is the XML language that describes web service. WSDL is a XML document 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 Web Service.

The elements of the WSDL documents fall into two main categories of:

Abstract Description which describe the interface of Web Service, its operations including the input and output parameters.

• Type Elements: it lists all the data types that are used by the XML messages as input or output.

• <Message> Element: this describes the details of the SOAP message. It can have multiple parts eg Input, Output. Message is equivalent of parameters of a function. let is say if we have a method with 2 input parameters then the equivalent <message> elements will have 2 <part> element as input.

• <Operations> Element: This is equivalent of the method definition and provides 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 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.

And Concrete Implementation that provides details of how to physically bind to Web Services.

• <Binding> Element: list the Protocols that can be used to communicate with Web Service and also the address of Web Service i.e. the namespace it is located.<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: it provides the URL where the Web Service located and it implements a <binding> element.

• <Service> Element: is a collection of one or more <ports>.       

UDDI (Universal Discovery, Description and Integration)

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

• An UDDI contains 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 WEB SERVICE. It provides a mechanism that allows one application to communicate to other application using XML. 

SOAP is similar to a shipment box for the XML message. It encapsulates the message and enable it to be shipped over the network. As the 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 web service solves the classical middleware problems?

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

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 compare to traditional middleware.

Furthermore, a web service is a special addition to middleware that uses internet to provide interfaces to other applications. 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 Service flexible and adaptable. Since web service messages are based on XML technology which is basically a text based communication therefore it makes it platform, language and vender independent. It resolves the biggest challenge that traditional middleware were faced to due to heterogeneity of platforms and languages and therefore makes it the best technology to be used for application integration.

History

In part two of this paper I will explain the creation and implementation of web services using C#.

Conclusion

In this paper explained Application Integration which is one of the biggest challenges of IS now days and the problems that makes application integration hard including platform, 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 heterogenous platforms, heterogenous programming developing, hardship of maintenance, hard to link it to internet, reusability problems and finally a lot of costs. All these issues make traditional middleware hard to use and maintain. These are the reasons that make web services to born.

Finally, I explained web services and 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.