Web Services [2006]

Background

In simple terms, web services are third party mini applications which offer extra functionality to developers of web sites. This extra functionality is usually related to an external data or verification service. The web service mini applications are accessed almost exclusively by some form of XML schema over standard web technologies, such as HTTP, SMTP or MIME. This extra functionality is integrated within a web site using web service protocols and offer real-time value added features. These features are predominantly extensions of e-business or e-commerce. The intention of web services is to provide essential e-business functions to those companies that either do not have the resources or the time to develop their own solutions.

Due to the constant pressures on IT managers to deliver more capabilities while reducing costs, the attraction of web services is obvious.

Such solutions include the likes of; user authentication, usage logging and cryptography; sales checkout, payment and credit card validation systems; conversion systems; databases, text messaging (SMS) and much more.

A good example would be the secure credit card payment validation system built into the likes of Amazon or stock quote ticker information on a broker’s web site.

Web services can be developed in any API (Application Programming Interface) that can read and generate the XML data required for successful data sharing. Such technologies include .NET, ASP, Java, C++, etc. Hence; web services are an option for developers from almost all contemporary programming backgrounds.

The specifications of most of the popular web service protocols are standardized by the likes of OASIS (Organization for the Advancement of Structured Information Standards), W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force).

It would be almost impossible to cover all the technologies related to web services. Hence, this paper will focus on the technologies that are most popular and/or had a significant impact on the technology as a whole.

Underlying Technologies

Although there are literally dozens of web service technologies (like WSIF – Web Service Invocation Framework, DCOM – Distributed Component Object Model, CORBA – Common Object Request Broker Architecture and WDDX – Web Distributed Data eXchange) in development and various states of deprecation, the most ubiquitous system of service delivery is the SOAP, WSDL and UDDI group of protocols. As with most of the other, lesser-known and less popular web service invocation protocols, UDDI, WSDL and SOAP are based on an XML schema that is ratified by a number of authorities (as listed above).

I have created a simple table below that shows the relationship and purpose of these three main protocols and how they fit into the overall delivery of web services. Further down, is a diagram that shows the interaction between the these protocols when invoking a service for a client.

UDDI – Universal Description, Discovery & Integration Web Service Directory
WSDL – Web Service Definition Language Web Service Description
SOAP – Simple Object Access Protocol Messaging

UDDI – Universal Description, Discovery & Integration:

UDDI is an initiative developed mainly by IBM, Microsoft and Ariba. UDDI is an XML-based mechanism for any requesting client to locate web services. This allows businesses and enterprises to connect, in real time, to third party web services. UDDI is a registry of services comprised of a WSDL description (see below) that are then communicated to the client via the internet using SOAP messaging.

Essentially it offers a directory of web services and information about their associated providers. The UDDI registries are also industry and platform independent. These registries are maintained by some of the larger IT corporations, such as; IBM, HP and even SAP. UDDI information helps by offering the customer relevant information about web services so they can extend market reach and augment their access to the service.

WSDL – Web Service Definition Language:

As the name implies, this protocol (again, based on XML) provides a way of describing a web service as well as a method for other individuals and businesses to access these services. In essence, it provides the descriptive list of businesses and their associated services for anyone to access. WSDL supplants IBM’s NASSL (Network Accessible Service Specification Language) and Microsoft’s SOAP (Simple Object Access Protocol) as the method used to advertise a business service in the UDDI directory. However, SOAP is used as the messaging protocol to access WSDL descriptions.

Now at version 2.0, WSDL supports a superset of the URI (Universal Resource Identifier) called an IRI (Internationalized Resource Identifier). An IRI allows a much broader set of characters and symbols such as Chinese characters (as opposed to the limited, English alphabet and Roman numerals of URIs).

SOAP - Simple Object Access Protocol:

SOAP was first developed by Microsoft as a structured method of passing XML-based information over the web. SOAP messages can be passed over HTTP, SMTP and MIME protocols. Although its name implies an object-based specification, SOAP quickly evolved into a generalized XML messaging framework. Today’s official definition of SOAP doesn’t even mention objects:

SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

Vasudevan (2001) describes it a little more clearly, "SOAP is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol".

It is relevant to mention that Microsoft’s own .NET Framework is deprecating SOAP.

SOAP

The above diagram shows the most common interaction of the SOAP, UDDI and WSDL protocols when providing a web service to a customer.

1. The Web Service Provider registers his service on UDDI (via a WSDL message).
2. The customer requests a specific service from the UDDI Registry and is then provided the information about that service (also using WSDL).
3. Once an appropriate service is identified, the customer dynamically connects to that service using SOAP.


Other influential technologies:

ADS – Advertisement and Discovery of Services (Protocol) is used to advertise services that may not have XML capability in order to build WSDL descriptions. It works via a single file on a web server that advertises multiple services (on that server). This can also be used to reduce the need for a number of services to advertising themselves individually.

XFS – Xmethods File System allows SOAP to post and read files (rather than simply transfer messages). This can be useful for persistent centralized data such as patches and updates.

Application of Web Services

Web services are used mainly in an e-commerce and e-business context and are a result of a necessity for sites to become more efficient and provide better service at a lower cost. These close ties with e-business are not a limitation of web services, merely the most relevant use of the technology at this stage in its evolution.

Bob Brauer and James Neiser (2006) state in their white paper on utilizing web services that "Commercial Web services provide an alternative way of integrating externally available data and functionality to improve their competitiveness, improve productivity and be more responsive to market and customer needs and changes."

Most on-line businesses require a means to receive electronic payments for their products and/or services. They also need access to relevant real-time database information, such as supplier product catalogues and price lists. As part of the payment process these businesses need to ensure that payments are legitimate and must minimize opportunities for fraudulent activity. Payment and verification facilities promote extra sales in that it is quicker and much more convenient for the customer. Although there is still some resistance to purchasing goods and services over the internet (due in main to the perception of insecurity), most consumers who use the internet to find and research a product or service are more inclined to be comfortable paying via the same means.

However, in a study by Fujitsu into consumer fears of online banking, it showed that 29% of 1,000 UK residents interviewed were fearful of using online banking services due to security worries. This means that merchants will need to integrate biometric security or some other superior means of security to encourage these people by way of changing their perceptions. A biometric or other system would benefit from some form of web service to verify credentials.

One of the most appropriate uses of web services would be an international travel agent. They would require access to a number of useful services to encourage customers to book through them. These essential services would include (but not limited to): flight schedules and direct booking; hotel occupancy data, rates and booking; travel documentation applications (visas, etc.); up-to-date international travel warnings; payment systems; dynamic currency exchange rates; etc. A customer accessing a site that could provide a complete system for designing and booking a full itinerary (using the services as above) would be much more successful than a site that merely provided static information.

Another useful implementation of web services is the delivery of system drivers and/or patches. Using a technology, such as XFS, a web site can incorporate files for download. The web service could upload a small app that, once verified (and this could be via another web service), runs on the client which then determines what drivers and/or patches are required. The service looks up the required files in its database and serves them up to the client. Another service could also be used to verify the legitimacy of these patches and drivers.

Commercial Offerings

There are many commercial offerings of web services, commonly known as SOA - Service-Oriented Architecture. The likes of IBM (with BEA Systems, Inc. and WebSphere); Oracle (with Oblix); SUN (Java); and Microsoft (.NET) offer commercial environments that deal with service-oriented web solutions. There are also a number of open source providers, based on Linux that offer just as convenient solutions. These include Apache (Tuscany Project and Beehive), Red Hat (with their acquisition of JBoss Inc. earlier this year), SAP (Netweaver), etc.

It would be wise for a developer to look at these commercial providers rather than try to make sense of the vast number of technologies and components. Obviously, a company looking at integrating web services in their site would need to take cost into account and their ROA (return on Investment). Some smaller implementations may benefit from the open source solutions, while larger, more complex needs would be best if they looked at paying for first-class support from a bigger commercial company.

Risks and Limitations

As with all technologies, there are limitations and risks. Web services and anything to do with the web will have inherent security implications as one of the main concerns of potential customers. Hagal, J. (2002) states, "the biggest risk is not to understand limits in areas like security and the ability to handle long-lived transactions".

However, there are a few tangible technical limitations, as well.

Cooney, P, (2002) Understanding Web Services, A List Apart, states a number of relevant drawbacks to using web services, they are:

As is always the case, the more complex and popular a technology becomes, the more security becomes an issue. Hackers and fraudsters target high volume high gain technologies. Therefore, as web services become more popular and offer more functionality, the opportunities for illicit activity increase.

From my research, I have noticed that an important limitation of adopting web services is the overwhelming number of technologies available. Developers can become confused about what technologies are available to them and how to implement them. Hence the commercial offerings try to simplify the process of choosing the right combination of protocols. Even so, there is the possibility that site designers may decide against web services altogether and attempt to develop their own solutions.

Even if a web service is implemented, it often dramatically changes the processes of the business as a whole. This usually means a restructuring of many of the existing business procedures, necessitating a paradigm shift for many of the stakeholders. This can cause resistance within the company to accept the proposal of integrating web services. Standard change management procedures must be implemented.

As with any database, data quality associated with web services must be maintained, otherwise there are serious credibility issues. When offering a data-centric web service, the provider must ensure they implement effective ILM (Information Lifecycle Management) in order to maintain fresh, relevant and credible data.

Future Direction

It goes without saying that the Web will become more pervasive in the future. It will become embedded into many existing technologies by offering more functionality and modularity. Not only will we see the need to adopt a next generation IP protocol to accommodate many more connections, we will see the need for more complex services offering much more than simply providing information.

A heterogeneous environment of smaller mini-apps will replace current monolithic application development. Developers will be compelled to abide by the standards to ensure their applications will work with others.

The article "Gazing into the Future of Web Applications and Services" by Preimesberger, C. (2001) where he interviews Paul Saffo, the Director of The Institute for the Future are interesting: Safo states that "In the future, we won't be purchasing automobiles, we'll be subscribing to them." This is in relation to the myriad technologies being embed into them, such as satellite navigation (both in guiding to destinations and locating a vehicle), in-dash e-mail and smart monitoring systems. He says that, "…we won't be buying a car so much as subscribing to services that will run the car for us." All these embedded technologies must be able to communicate and make sense of their role within a collaborative environment.

The article goes on to explain the need for ubiquitous sensor technologies in society, such as face, eye and fingerprint recognition. Obviously, these all need to be integrated and cross referenced in order to be useful (in the detection and prevention of terrorist activities, for example). The only way that airports, train stations, police stations, hospitals, etc. could possible link up and make sense of the vast data would be via a series of web services.


References

Vasudevan, V. (2001). A Web Services Primer. O’Reilly XML.com
http://webservices.xml.com/pub/a/ws/2001/04/04/webservices/

Cooney, P. (2002). Understanding Web Services. A List Apart
http://alistapart.com/articles/webservices

Chaffey D, (2004), E-Business and E-Commerce Management Second Edition, Prentice Hall

Web Service List (2006).
http://www.webservicelist.com/

Preimesberger, C. (2001). The Future of Web Apps and Services. DevX
http://archive.devx.com/free/hotlinks/2001/ednote121201/default.asp

Hagel, J. (2002). The Future of Web Services (Chat Transcript). Forbes.com
http://www.forbes.com/home/2002/12/09/1209hagelchat.html

Brauer, B. Neiser, J. (2006). Extending Your SOA and Internal Applications Utilizing Commercial Web Services. StrikeIron, Inc.
http://www.strikeiron.com