HP Web Services Architecture Overview

 Kannan Govindarajan, Arindam Banerji

kannang@hpl.hp.com, axb@hpl.hp.com


Web services are different from traditional distributed computing models. Web services architectures provide a framework for creating, and deploying loosely coupled applications. One of the consequences of the loose coupling is that any entity that a web service may interact with may not exist at the point of time the web service is developed. New web services may be created dynamically just as new web pages are added to the web and web services should be able to discover and invoke such services without recompiling or changing any line of code. In this position paper, we outline some of the high-level architectural requirements of a comprehensive framework for web services, we propose a layered approach to architecting web services that allows for pluggability and interoperability. In addition, we distinguish between infrastructure services and application specific frameworks.


The web service architecture allows businesses to expose business assets as services. Standardizing interactions amongst services has the added advantage that any enterprise can out-source parts of its operation that it does not have expertise in. In addition, since the vision of web services enables web services to dynamically find new web services that it can interact with, enterprises can find new providers for the service relatively quickly. A specific application of this dynamism is in the e-procurement arena. For example, the average sourcing/procurement cycle in enterprises is of the order of 3-4 months. Of this time, about 50% of the time is spent in identifying the appropriate suppliers, about 20% of the time in handling the RFQ (request for quotes) process, and an additional 10% of the time is spent in negotiating the appropriate deal. The ability to dynamically find suppliers can translate to significant time savings, and therefore to lowering of costs. Essentially, the procurement and fulfillment business process are modeled as services, and a hub is the aggregation point for the services. In such an architecture, finding a new supplier is the same as finding the fulfillment service of the supplier at the hub. HPs web services vision enables such a dynamic world by allowing business processes to be modeled as web services, by providing a platform for hosting such web services, by defining the technical conventions that enable the interoperability between web services, and by defining a hub, or aggregation mechanism for web services.

It is our position that fundamentally different component model is required for modeling web services. This is because the assumptions that are made by traditional distributed component models are violated by web services. In addition, we believe that a comprehensive web services platform has at least three related technologies:

  1. The technologies that define the hosting platform that hosts services. Service providers typically will host their services on this hosting platform.
  2. The technologies that define the hub that allows services to dynamically discover other services and establish trust in the context of the community. This hub technology potentially is compatible with other hub-like efforts such as UDDI (www.uddi.org).
  3. The technologies that define the standard conventions that ensure that services can inter-operate with each other irrespective of their implementations.

The hosting platform provides, among other things, technologies that are required to model existing business asset/process as a web-service, allows clients of web services to invoke services, etc. The hub provides technologies for web services to be described, discovered, etc., and the standard conventions specify the things that have to be standardized so that web services hosted on various web service platforms inter-operate. We at HP have found these three technologies to be extremely relevant in the mobile services and electronic marketplace deployments. We now briefly provide an overview of these scenarios. The mobile service we consider provides a sales representative access to manuals from his cell phone and allows him to print the manuals on a printing service that may be determined by his current location. For example, the architecture of a mobile online printing solution may look as follows:

The architecture of an electronic marketplace looks as shown above. Note that the two architectures above are quite similar, the MNO in the mobile solution serves as the aggregating and intermediating entity, whereas the hub in the electronic marketplace serves as the aggregation point and may intermediate the access to services hosted on it.  We suggest that W3C standardize the technical conventions that enable web services to inter-operate with other web services. The conventions that need to be standardized fall into two categories: infrastructural and domain specific. Infrastructural conventions should be separated into many layers that provide the functionality that essentially allow web service creation, deployment, interaction, and execution. In addition, specific web service infrastructures may also standardize common functionality that is applicable in specific domains. Two domains of particular interest in the web services space are electronic marketplaces, and mobile services. In addition, it is important for W3C to keep all the web services related conventions co-ordinated in order to enable a coherent platform.

Infrastructure for Web Services

The basic infrastructure for web services serves the same purpose that CORBA and COM serve for traditional distributed computing infrastructures. However, there is an important distinction between the infrastructure for web services as opposed to traditional infrastructures. The inter-operability problem among web services is more challenging than the inter-operability between traditional distributed enterprises. One reason for this is that web services may be separated by firewalls and the semantics of data being communicated between them may not be uniform at the communicating ends. Another important distinction between web services and traditional distributed component models is that the binding between carious web services is looser and can occur later than the binding between various components of a traditional distributed application.


Note that one of the key differences between the traditional distributed computing models and web services infrastructure is that the message formats need standardization. This is in addition to standardizing the APIs needed to access the functionality. Standardizing just the APIs as the Java ™ distributed computing platform has done leads to a situation where there are many incompatible implementations. For instance, at the time of writing this position paper getting two JMS implementations to communicate was still an open issue. We believe that the message formats should all be characterized as XML messages and W3C guide their definition so that different web service infrastructure implementations can inter-operate. In addition, as mentioned before, web services are fundamentally different from traditional distributed models for the following reasons:

  • Web services are loosely coupled: Changes to a web service should not require re-installation of software components by the users of the web service.
  • Web services require dynamic binding: Typically, application designers bind software components to one another at development time. Web services, on the other hand, are likely to be implemented and provided by different service providers. In addition, we must enable easy changes to the services we are using, easy discovery of new services, of new capabilities of existing services, and of new binding or location information of services.
  • Web services communication is based on a Document Exchange Model: Traditional component frameworks support a network-object model of interaction in which objects of strictly defined types are transferred between components using a request-response interaction pattern. Cross-organizational business interactions do not fit this framework well for two reasons. The interfaces of services may need to be changed in ways that cannot be captured by simple extensions. This precludes the use of object inheritance to support the inter-operability in presence of change. Secondly, interactions can be long lived. Therefore, asynchronous exchange of XML documents is better suited for cross-organizational business transactions.
  • Web services in different enterprises are likely to use different semantics. The interpretation of the data communicated among enterprises is different for each enterprise. For instance, the address field of a purchase order may have different significance for the parties. If a uniform object model is used, the semantics of data often tends to be similar or homogeneous contributing to tighter coupling.
  • Web services in different enterprises require a distributed model of security. Security responsibilities are split amongst the enterprises. Each enterprise manages its end of the security infrastructure independently.
  • Web services from different enterprises may be built using heterogeneous technology stacks. Each enterprise decides on the computing infrastructure independently taking into consideration many factors.
  • Web service interactions must be able to traverse corporate firewalls. Traditional distributed systems are tuned for applications that are deployed within the enterprise; Web services may be deployed from behind Firewalls. They may need to access other web services across enterprises. For example, in the J2EE™ architecture, the application are written to receive input from outside the enterprise, however, the applications do not often initiate outbound requests to applications in other enterprises. In the realm of web services, accessing applications in other enterprises is the norm rather than the exception.
  • As shown in the picture above, the infrastructure for web services is made up of the following layers:

    The communication layer: The communication layer should be transport independent though bindings for common transport protocols such as HTTP, SMTP, etc., should be defined. Essentially, this layer answers the question: How do web services communicate with each other over standard protocols? The messaging layer provides the requisite properties of the messaging such as reliability, security, etc. In order for web services to communicate with each other they have to agree on the technology, standards and protocols for communication. They also need to agree on the syntax and semantics of data they are going to exchange. However, the data that they exchange can be classified into infrastructure parts that the infrastructure uses in order to route the message and application specific parts that the infrastructure does not inspect.

    The Service definition layer. Essentially, this layer is concerned with defining how services expose their interfaces as well as the service invocation model. It addresses question such as do the web services expose a RPC like invocation model or do they expose a completely asynchronous document exchange model. The invocation model rests on the messaging model. Since the programming model for web services is more likely to be document exchange based, it is difficult to adopt an object interface definition language for the purpose of defining interfaces of web services. Another aspect to keep in mind when defining interfaces in terms of message exchanges is that the order of message exchanges plays a role in the interface definition. In addition, the security infrastructure has to provide mechanisms that allow service providers to easily determine whether the invoker has the authorization for invoking the service. It should be noted that the service definition layer provides the platform on which the other infrastructure services and functionality is built on. We at HP have invented CDL (Conversation Definition Language) as a means of expressing the interface of web services in terms of the documents that are exchanged with the service.

    Introspection: The web service infrastructure has to define mechanisms that allow clients of web services to introspect web services in order to determine how they should interact with them. There are two conversations that allow services to get information about another service they are interested in. These two conversations support the dynamic interaction by allowing a functionality that is similar to the notion of introspection in traditional object systems. The ServicePropertyIntrospection conversation provides general information about the service, the conversation it supports, its provider, and how to access the service. The ServiceConversationIntrospection conversation returns the complete description of the conversations as CDL documents.

    The mechanism for binding to services: This allows clients of services to determine the service they want to use in a declarative manner separate from the interface definition of the service. This essentially involves defining the meta-data of services and registry infrastructure for storing and querying the meta-data of services. Matchmaking is the process of putting service providers and service consumers in contact with each other. The matchmaker is where services that want to be dynamically discovered register themselves or their service offerings, and where services that want to find other services send their request for matches. Some of the services advertising themselves through the matchmaker will be simple end-providers, while others may be brokers, auction houses and marketplaces which offer a locale for negotiating with and selecting among many potential providers. The matchmaker is a very simple, foundational, service on which the rest of the service framework rests, and should be as neutral as possible. It is the web-spider search engine of the web services world. The matchmaker service depends on the meta-data definition system that is provided by the infrastructure. This meta-data system should be flexible and capable of defining the meta-data of a wide variety of services. Some of the requirements of the meta-data definition system are the following. It should be capable of defining the metadata for a wide variety of services. This means that if different vertical industries want to define their metadata for the services in their industry in different ways, the mechanism should allow that. It should allow the metadata to evolve in a gradual manner without changes to the backends or the enterprises that are using old versions of the metadata definition. This allows specific advertisers to differentiate their descriptions of the goods/services they sell with characteristics that enhance their advantage over their competitors. It should be compatible with existing metadata definition mechanisms so that existing web services can be advertised at matchmakers and discovered. It should identify portions of the metadata that are searchable

    The security infrastructure: This enables web services to secure various aspects of the service. Traditional PKI infrastructures may not be suited for the web services space. In addition, the security infrastructure will have to provide not only secure transport, but also higher-level access control mechanisms. Web Services or E-Services pose a unique challenge to the design of a distributed security system. At the high level the security system performs the access control, accountability, system integrity and confidentiality.

    Unfortunately security systems today cannot do these things well in a distributed environment that spans multiple, independently managed security domains. Some of the specific problems that must be solved are:

    Transaction Support: The web services infrastructure should provide support for some notion of transactions so that web services can compose other web services in a transactional manner. Traditional two phase commit protocols may not be appropriate in the context of web services. In addition, transactionality in the web services world may be restricted to providing support for atomicity only. This is in contrast to the consistency, isolation, and durability properties guaranteed by traditional distributed transaction systems. Some of the questions that need to be answered by the support for transactions are:

    Management Support: The web services infrastructure should specify how web services are to be managed so that various aspects of the interaction among web services can be managed. There are two interpretations of manageability for services. Manageability from a management system’s perspective refers to whether a service provides sufficient information (events, measurements, and state) and control points (lifecycle control, configuration control, etc) so that a management system can effectively monitor and control the behavior of the service. There is a second notion of manageability – manageability from a peer service’s perspective. When two services interact with each other, one of them initiates a request (client) and the other services the request (service). From a client’s perspective, a service is manageable if the latter provides sufficient visibility and control over itself and over the transactions or conversations it executes. For example, a service that provides information about the progress of a client’s ongoing transactions and an ability to escalate the speed of transactions in progress (perhaps by paying additional price) is more manageable than a service that does not. Similarly, a service that can be queried about how much quality of service (QoS) it can guarantee and that can provide response time measurements about its transactions is more manageable than a service that does not provide these features. From a service’s perspective, a client is manageable if it can provide enough information about service usage back to the service. For instance, a client that can be queried about its perception or quality of experience with the service is more manageable than a client that cannot be. Similarly, a client that provides end-to-end response time measurements of its transactions back to the service is more manageable than a client that does not.

     Domain Specific Infrastructure

    We now turn our attention to some of the domain specific functionality that the web services infrastructure should standardize. There are two main domains that we believe web services have a major impact. These are: electronic marketplaces, and mobile web services.

     Electronic Marketplaces

    In the specific domain of integrating business applications across enterprises, web services can play a role in standardizing some of the interactions between businesses. The web services infrastructure provides facilities to find web services and interact with web services. However, in the business to business scenario, the negotiation and contract formation functionality has special relevance.

    Negotiation: Standardizing the protocols required for various forms of negotiation such as auctioning, two-party negotiation, etc., allows web services to cleanly attach their own specific strategies while still being able to negotiate with a wide variety of parties in order to complete business transactions. The negotiation framework aims to provide infrastructure that allows two or more independent entities to interact with each other over time to reach agreement on the parameters of a contract. It is aimed primarily, though not exclusively, as a means to reach trade agreements. It can be used both by automated entities, and by users via appropriate software tools. Its value to negotiation participants is that it is a prerequisite to provide decision support or automation of the negotiation, and hence make the process more efficient. Furthermore, they can be confident that the basic rules of interaction in any negotiation are standardised, hence reducing the effort to automate many different kinds of business interactions. They are able to negotiate simple contracts, where only price is undetermined, and more complex contracts where many complex parameters depend on each other. Furthermore, the protocols provide the participants with trust guarantees, that no party has access to extra information or is able to forge false information. Its value to negotiation hosts such as auction houses and market makers is that it provides a standard framework that all potential customers can use to interact with them. However, it does not require a specific market mechanism, so allows the host to decide on an appropriate one. It not only provides standard off-the-shelf market mechanisms such as the English auction, but also allows custom mechanisms to be implemented for particular special needs such as the FCC auction for auctioning bandwidth.

    Contract Formation and Business Composition: The central idea of the conceptual model for contracts is that the business relationship that motivates interactions that follow is captured explicitly in an electronic contract. An electronic contract is a document formed between the parties that enter into economic interactions. In addition to describing the promises that can be viewed as rights and obligations by each party, the e-contract will describe their supposed respective behavior in enough detail, so that the contract monitoring, arbitration and therefore enforcement is possible. The terms and conditions appearing in the e-contract can be negotiated among the contracting parties prior to service execution. In this way businesses with no pre-existing relationships can bridge the trust gap, be able to strike deals and take them to completion. Business composition is the ability for one business to compose e-services, possibly offered by different providers, to provide value-added services to its customers. Composition of e-services has many similarities with business process (workflow) automation. A web service virtualizes the customer interaction aspects of the business processes implementing a service. In order to specify how services should be composed, we must define the interaction process associated with a service as well as the flow of service and inter-service invocations.