Virtual Web Services: Extension Architecture to Alleviate Open Problems in Web Services Technology

Introduction

When referring to current Web service architecture, a very important aspect to take care of is the one related to the separation of roles and the meaning of each role inside the architecture. Although the distinction between client, provider, and directory is clear, a great part of the Web services technology is based on a Web service offered by a provider (Booth, Haas, McCabe, Newcomer, Champion, Ferris et al., 2004). That is, according to the roles of the current proposed architecture, the provider is intimately related to the Web service it actually offers. In fact, both Web service and provider are used as only one role inside the architecture, called service provider. Several open problems of the current architecture can be solved by redefining this way of conceiving the roles inside the architecture.

Within the current architecture, the relation between client and provider has been established based on the use of two concepts:

• •

  Binding. It is a process performed at development-time, consisting of adapting client software to the definition or description of a Web service.

• •

  Invocation. It takes place on runtime, and it can be defined as the process by which a running client application calls a Web service.

The revised version of the W3C architecture redefines and merges these two concepts as “interaction.” According to an “interaction” between client and provider, the binding is performed in a static way, so the way invocations must be performed is predefined. According to this:

• •

  Dynamic binding cannot be performed, or, at least, not in an automatic way. There are different options based on the use of metadata (“Web services invocation framework,” 2007) that enable the use of dynamic binding, but it is always mandatory to use metadata to access application data.

• •

  Once a client application is bound to a concrete Web service, the execution of the application will be bound to the service provider selected, initially, at development-time. It will be necessary to bind a new Web service if we decide to use a new service provider. And this means that it will be necessary to develop new code to adapt the client application to the new interface of the new Web service. Although it is possible to change the location of the server providing the Web service without needing to make any modification to client application code, this will be only useful for those providers that have developed and published a Web service in the same way, that is, with the same parameters (its names and types), the same namespaces, and so forth.

• •

  If a client application wants to use more than one provider in order to invoke the same equivalent service (offered by different service providers), the developer must bind the client application to each one of the Web services.

These and other less relevant problems have their origin in the fact that the role of “service provider” is not distinguished from the role of “Web service provider.” When we talk about service-oriented architectures (SOA) (Barry, 2003; Vinosky, 2002), we usually use the terms “clients” and “providers,” and we always relate these term with the use of services. We think it is necessary to slightly change the terminology, and use the terms “client application” when we refer to a SOA client, and “Web service provider” when we refer to a SOA provider.

In addition, we propose the creation of two new roles (as seen in Figure 1): the service provider (differentiated from the Web service provider), and the client entity (differentiated from the client application). The appearance of these two new roles will led us to a mandatory role separation. That is, Web services architecture is now composed of five roles: client entity, client application, directory, Web service provider, and service provider.

Figure 1.

New roles

State Of The Art

In the following subsections we will analyze the state of the art in several open issues in the Web services technology.