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.

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.