Chapter 17
Trying to Make Sense of Web Services in a Telco Environment
17.1 Introduction
In this chapter, we take a high level informal look at Web Services and the Service Oriented Architecture paradigm, from the perspective of telecommunications deployments. We will look at the simple core of Web Service infrastructure standards (the publish/find/bind triangle and the WSDL/SOAP/UDDI core) and argue that the model calls for a number of extension specifications and additional technologies required for realistic, large scale, carrier grade Web Service deployments.
We often hear that telecommunication services design and standardization needs to change. ‘Telco services need to be more like Internet services’ is the adage. But what does that mean? We need shorter development life cycles; we need to be able to tap into the sheer unlimited pool of Internet-savvy developers. We need the service proliferation, the service customization, the service personalization, and above all, the service profitability and cost-effectiveness of Internet services. But how is this achieved? The answer, if one is to believe popular publications on the web, is Web Services and Service Oriented Architecture. Or if you are really up to speed with the latest buzzwords, the answer is Semantic Web Services. However, these answers really raise the same questions all over again. What does this mean? How is this achieved?
One approach at tackling these questions is to examine what exactly a Service Oriented Architecture means and which problems it tries to solve, see which technologies from the web are adopted in order to realize it, and then see if those technologies can be ported to telecommunications services realm. It is hoped that this approach will get us beyond much of the inevitable hype, and allow us to really understand Web Services. Such an understanding will better facilitate us to assess future directions of service mediation and service delivery architectures, rather than simply adopting and porting seemingly successful and enabling technologies from one paradigm and applying them to another.
This chapter has two objectives. The first is to gain a basic understanding of some of the more recent activities in academia and industry to be able to see at least one possible future direction in which our current Service Architectures may evolve. The second objective is to be able to assess and understand the current standards contributions and strategies of some of the non-traditional players in telecommunications standards. This chapter is not intended as a survey on available research topics and technologies; there are many of those around already. Instead, this chapter functions more as information and background for people interested in service mediation and service delivery. It tries to identify and understand those technologies that may play a role in one of the possible future directions for industry standards in the area of service architectures.
Certain parts may seem trivial to the more astute reader, but are included here in order to attempt to paint a complete picture. Some of the topics addressed in this chapter are very popular in research and academia, and hence numerous publications as well as pre-standards activities are available[1]. As such this chapter may not provide many novel insights. However, for those with a history in telecommunications standardization for services, service delivery and service mediation, using tightly coupled, object oriented, distributed paradigms, some of these new concepts might appear quite alien.
17.2 Web Services and Service Oriented Architecture
A Service Oriented Architecture (SOA) is an approach to describing a distributed computing environment for Web Services. Web Services are discoverable software components available on the web. Basically, the model of the web as a collection of resources (e.g. documents, images, audio files, video files, etc.) is extended to considering the web as a collection of services. The concept of web resources is being generalized to anything that can be identified on the web, anything that has a URL[2].
As described in OWSERv1.0 [OMA 2004], in its simplest form, a SOA can be depicted as the well-known triangle (Figure 17.1). A Web Services-based architecture contains three functions:
· a Web Service requester (WSR);
· a Web Service (offered by a Web Service Provider, or WSP); and
· a Web Service Registry.
A Web Service Provider’s[3] responsibility is to create a Web Service description (in WSDL), publish that Web Service description to one or more means of Discovery (e.g. a UDDI Registry), and have the Web Service ready to receive messages from Web Service Requesters (WSRs). A WSR finds (discovers), possibly through one of the many available service registries, the service description of interest and uses this service description to bind to the Web Service provided by the Web Service Provider (WSP). Messages are exchanged conforming to a particular protocol (specified in SOAP) and schema (specified in WSDL).
Figure 17.1 Web Service Architecture
A Web Service Registry's responsibility is to ‘advertise’ the Web Service descriptions (WSDL) published to it by WSPs and to help WSRs search through its registry to find a service description of interest. In this context, the service registry is similar to a matchmaker; once a match is found, it is no longer needed, and all subsequent interactions are strictly between the WS and a WSR.
17.2.1 What Problem is SOA Solving?
In its realization of Web Services, Service Oriented Architecture is a distributed computing technology, one of the many that are around. The main differentiating characteristic of SOA is that it is loosely coupled. Let us first look at why a tightly coupled system has its problems.
Tightly coupled services are rigid. If you try to wiggle one component out of the composition (e.g. to upgrade) the entire thing caves in. As an example we take a look at the Parlay User Location service. Parlay interfaces are defined using the object oriented computing paradigm, which supports the notion of a type system that is shared among software components (objects that implement an interface). It is very difficult to take this interface and for instance extend the address parameter to support the URI’s in addition to just MSISDN’s. Client and server need to be upgraded simultaneously. Updating the one but not the other breaks the system. In SOA terminology, we call this brittle.
So what constitutes a loosely coupled system? The following description is taken from [Webber 2003].
A Web Service does not expose a set of operations, methods, or functions. Instead, it advertises the set of structured messages that it will exchange. Perhaps the most important difference between service orientation and object orientation resides in the way software integration is achieved. As we’ve seen above, the concept of a type system that is shared among software components is fundamental to object orientation. In the general case, a hierarchy of interfaces has to be agreed upon in advance, before those software components can be integrated.
In contrast, services and their consumers achieve integration through the exchange of messages. The only thing that is shared between them is the vocabulary used to define the structure of those messages. The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment (but only after discovery time).
Good service-oriented design mandates that all the information necessary to invoke an action be contained in a message, unlike object orientation where ‘chatty’ interactions between client and server object are the norm.
In object orientation, it is necessary to share an understanding about the underlying type system and the behaviors that are realized through the sharing of interfaces/types. Type sharing results in systems that cannot evolve easily, especially when they are distributed and not under a single entity’s control. The latter is, of course, the case in the communications environments we envision. The evolution of one interface/class may break the entire system. The result is tight coupling, with brittle systems as its consequence.
Services on the other hand are deployed, implemented, and maintained independently. They have well defined boundaries and they communicate with others through messages. The only common understanding that is shared between services is how to do message validation. Services define the message-exchange patterns and formats of those messages that they are willing to accept. Hence, loose coupling is achieved.
The Web Services paradigm is picking up where distributed object computing standards such as CORBA left off, attempting to provide more flexible, and less structured, assembly of software components [Hull 2003]. A primary goal of the Web Services paradigm, achieved through this loose coupling, is to support dynamic discovery, selection, and composition of Web Services, be they atomic or themselves composite. Furthermore, a key motivator for this paradigm is the promise of supporting a high degree of customization and personalization in the provision of services, e.g. through the use of intricate user profile and preferences data, and the use of policy engines in the atomic Web Services [Bultan 2003].
17.2.2 Sounds Great Doesn’t It?
We have introduced SOA as a loosely coupled distributed computing environment, aimed at overcoming some of the drawbacks and limitations of other such environments. As with any new technology, SOA is being presented as the panacea of service architectures, solving all our past problems, including the Ebola virus and world hunger it seems. Superlatives like better, simpler, more flexible and more elegant are not uncommon. However, is it really as simple as depicted in Figure 17.1 and described above? Or course not, nothing ever is.
Web Services, like any other technology area, has seen an explosion of the number of acronyms in use. The Web Services core (WSDL, SOAP, UDDI) is continually being extended with proposals for new WS-* specifications[4]. This is a natural phenomenon in any developing technology; one starts with the basics, then gradually provides add-ons for those pieces of functionality expected of any mature technology (such as security, reliability, etc.), and finally numerous bells and whistles may be added once the technology has been established in the mainstream. Some of the extensions however are intrinsically required as a result of the chosen paradigm itself. The basic Service Oriented Architecture model, consisting of the core triangle, will not yield any larger scale, realistic service. In order to be practical and scaleable, extensions are required which are to be viewed separately from the add-ons, like security and reliability.
We are trying to distinguish between those extensions that are intrinsic to the SOA paradigm, and those that seem aimed at mimicking or re-creating all the CORBA Services. This chapter will try to show that the simple paradigm of Web Services and Service Oriented Architectures requires complicated and advanced extensions in order to design and deploy realistic, high-performance, value added end-user services. This chapter will focus on those intrinsic extensions.
17.3 Service Composition
We have seen that Service Oriented Architecture resolves the major drawback of object-oriented architectures, namely the brittleness of tightly coupled services. However, like OO systems, the main objective of SOA systems is still to design value added services out of distributed component services. Or, for instance in an OMA context, to build value added mobile end-user applications out of OMA enablers. Service composition using tightly coupled components is relatively straightforward, due to being tightly coupled. All the characteristics of tightly coupled systems – chatty conversations, fine-grained programmatic client-server interfaces, shared type system – allow larger, complex services to be composed out of individual service components. Because you know how the components operate, what they do and how they interoperate, you can ‘easily’ pre-design a composite service, and its composite behavior is deterministic.
One could say that with tightly coupled systems, most of the workflow, or business process, is embedded in the interface definitions; that is, the client object invokes a method on the server object, and depending on the state of the server object, a pre-defined number of response behaviors can be expected[5]. For example, if you look at the Parlay interface specifications, there are extensive sequence diagrams and state machines included. In Service Oriented Architectures, this is not the case. Services are defined to operate as stand-alone or potentially as peers, but without a priori knowledge of each other’s message sets, of each other’s purpose, or even of each other’s existence. That’s what loosely coupled means; that’s what message based means; that’s what service oriented means.
Web Services are self-contained, web-enabled software components, capable of performing a business activity. The platform independent nature of Web Services, through the service oriented, message-based way they are defined, opens the possibility to combine individual Web Services into more complex ones. Service composition refers to the technique of composing arbitrarily complex services from relatively simpler services available over the web.
With loosely coupled, message based services, composing a well behaved, aggregated service with deterministic behavior is significantly more difficult. Service composition becomes an issue, which is implicit to the paradigm of Service Oriented Architectures; it was never such a large issue with other service paradigms. A solution will have to be found.
17.3.1 Workflow
Different loosely coupled services are, or should be, designed and deployed independently from one another. However, in a composed service they still need to collaborate during run-time. To do this, the loosely coupled services have to expose their behavior (including the ordering between interactions) in a machine-readable (i.e. formal) manner, beyond the messages they provide (i.e. beyond merely their WSDL definitions).
Web Service workflows are a set of Web Services that are executed in a structured way. A more traditional definition of workflow is the automation of a business process during which information or tasks are passed from one participant to another for action, according to a set of procedural rules. This latter definition reveals that the problem of workflow predates the Web Services technology. Workflow has a history that dates way back, but formal thinking on workflow and workflow tools became important with assembly line planning and warehouse systems planning, ordering, and shipping. This formal thinking has led to research in the area of workflow languages or process description languages. Much of the more recent research activity in the area of service composition builds on this older work.