Browse Prior Art Database

Web Service addressability to non-web service applications Disclosure Number: IPCOM000016585D
Original Publication Date: 2003-Jul-01
Included in the Prior Art Database: 2003-Jul-01
Document File: 2 page(s) / 80K

Publishing Venue



This article proposes a way in which an application that is not web service enabled, or able to directly invoke web services, can participate in a web services architecture and environment through use of an adaptive entity which acts as an agent on the application's behalf, both as a mapping layer from the application to the invocation of the service, and as a web services facade to the application for use by web services clients.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Web Service addressability to non-web service applications

The service oriented architecture (SOA) presents an attractive model for loosely coupling software systems and components together. When an application writer wants to make their application available as a service, however, they must write their application with a view to what interfaces they wish to expose as a service (i.e. support a particular public interface) and set up infrastructure to support the receiving of requests, and a addressable web presence, to direct these requests to their application. This is an inherently static definition and deployment step.

    This article discloses a mechanism for an application writer to be able to expose their application as a service at runtime, dynamically, through function calls to a supporting generic infrastructure layer, allowing the application to specify the public interfaces it wishes to expose, and letting the infrastructure provide support and web addressable presence on its behalf.

    The invention consists of a thin client that presents the functional API to the application to allow it to indicate what and how it wishes to participate in a SOA, and propagates the function calls to a server that will provide the web addressable presence and public interfaces, as specified by the calls to the functional API. The advantage of this approach is the application writer can avoid the requirement to define and deploy their application as a web service, but be able to participate in a SOA through runtime function calls. This allows the application writer to code in their native architectural paradigm and methodology, and make the decision to become a web service at runtime, potentially through business logic and data.

The diagram below illustrates the major components and their interactions.

published WSDL For Client Proxy





    An application that wishes to expose itself as a web service makes a function call to a client API (1). This function call specifies the type of web service it wishes to appear as (its port type, in WSDL terms). This type maybe explicitly defined as a WSDL portType XML description, or it may be a token representing a particular type in a finite set of predefined WSDL portTypes. The client API connec...