Limitations of the Current Web Services Model

Limitations of the Current Web Services Model

Limitations of the Current Web Services Model

Two central limitations in the Web Services model negatively affect all stages of the Web Service lifecycle.

Firstly, the Web Service addressing model is rigid and only suited to highly reliable networked environments with highly reliable hosts. It does not take into account the intrinsic dynamism and fallibility of hosts on the Internet, and applications which aim to be robust to the failure of hosts become littered with failure-recovery code.

Secondly, an over-burdened and under-specified Service Provider role has led to the development of proprietary deployment systems and closed-world environments where the use of Web Services is only incidental. Saddled with these two drawbacks, the wide adoption of the Web Services model has resulted in a landscape of software services that is highly populated by applications which expose Web Service interfaces, but which are largely incompatible in terms of their required deployment systems and hosting environments.

Conviction

Our work is driven by the conviction that isolating the tasks and separating the concerns of participants in a distributed Web Services framework allows for abstractions over location and technology which enable the provision of pervasive Web Services which can be reliably addressed, bound to, and utilized, at any time and from any location.

Further, it is proposed that mechanisms can be developed to provide reliability and reduce complexity for users of Web Services, and that these mechanisms can be equally applicable to static, homogeneous computing environments as to dynamic environments composed of heterogeneous Web Service implementations and Web Service-hosting technologies. [S2]

Current Downsides for Service Providers

The Service Provider role, as currently defined, involves high cognitive complexity and has high barriers to entry, discouraging participation by individuals due to the cost and complexity involved in fulfilling all the responsibilities of the role. It is argued that the Service Provider task list is too long, incorporates too broad a set of fields, and necessitates a significantly greater amount of domain-specific knowledge than should be required of any one actor. A modularization of the service provider role into multiple sub-roles, specifying their responsibilities, and defining concrete interfaces for interacting with them, will allow the sub-role tasks to be automated, outsourced or replaced within their environment – enabling service providers to progressively and transparently mature their systems and lowering the barriers to participation in the provision of Web Services.

This work rests on the belief that the traditional Web Service model has many entangled concerns which are in fact distinct, independent tasks. Implementing the business logic of a Web Service, for example, is very different from hosting a Web Service, requires a completely different skill-set, and a completely different set of software and hardware technologies. Similarly, while Web Services are developed for particular application servers (software applications which expose interfaces to Web Services’ operations) the consideration of the target application server is very different from the tasks of preparing a host environment and deploying an instance of the Web Service – and even further removed from the decision of when and where a Web Service should be deployed.


Current Downsides for Application Developers

From the point of view of application developers, it is argued that the task of implementing the business logic of an application is different than handling Web Service implementation- and distribution-related errors, and that a mechanism should be developed which abstracts over the location of a service while still preserving the current Service Consumer actor’s view upon the system – factoring out redundant failure detection and recovery code while maintaining compatibility with existing client applications.

It is argued that the rigid addressing model forces the entanglement of application business logic with remote-invocation failure recovery techniques, is detrimental to the usability and reliability of applications, adds significant time and complexity to the creation of client applications, and is a serious drawback to the adoption of the existing Web Services model. It is also argued that the over-burdened and under-specified Service Provider role has fostered the development of progressively insular, closed-world environments composed of Web Services and client applications for which the use of Web Services is only incidental. It is finally argued that the goals of universal interoperability, loose-coupling and platform-independence espoused by Web Services and service-oriented computing are worthwhile goals, that they are currently undermined by the traditional Web Services model, and that a new, next-generation model can be developed which better facilitates the realization of these goals.


Requirements

Requirements

Limitations of the Current Web Services Model

This section defines a set of requirements that a next-generation architecture must meet, based on the previously-identified drawbacks of current approaches. These requirements aim to encourage a separation of concerns between participants in the architecture, to advance the creation of mechanisms which can accommodate heterogeneous technologies, and to promote the development of architectures which are resilient to various types of failure. Although some of the existing architectures address some of the individual requirements, the satisfaction of this complete set of requirements is unique to this next-generation model.