WSCandis is a caching and directory solution especially tailored for enterprise environments in which client applications rely on a layer of webservices that may be located on separate locations. In these environments applications are often deployed from one or more development servers to one or more production servers.

The Webservices Caching and Directory Service (wscandis) tries to address the following issues:

• The need of applications that act as webservices clients to have the webservice WSDL address hardcoded as part of the application code.
• The lack of a single directory of web services used by all applications
• Lack of a consistent naming scheme for all webservices (i.e. "com.uvi.general.resorts") regardless of their network location, implementation language and environment.
• An application's need to use a different webservice, or the same webservice but on different locations, based on whether the application is being executed on a development or production server.
• Performance hit on high demand applications due to having to continually instantiate and discard webservice stubs for each request.

WSCandis tries to solve these problems using a two-part approach: a webservice stub caching mechanism and the use of a central directory and lookup service.

The following diagram displays a general overview of how the elements of wscandis are interconnected.

Caching Engine

The other component of wscandis is the caching engine. This is a mechanism that allows for caching webservice stubs on memory after they have been created so that they can be reused again. This caching can be made application-wide or server-wide depending on where the webServiceFactory component is stored.

The stateless nature of webservices allows for reusing the same webservice stub by different requests, since no state information will be actually stored on the webservice stub instance. This reuse decreases the performance penalty on the server originated by having to instantiate and discard webservices for every request. This gain is more noticeable on applications that sustain heavy traffic and that rely on one or more webservices to perform frequent tasks. Stress tests have indicated that an application using wscandis is able to process and respond to over 10 times more requests on the same time than an application without any caching facility.

The key of the caching mechanism, as mentioned before, is the webServiceFactory component. Client applications use only this factory to obtain references to webservices. The factory works in tandem with the Directory Service, so a client will pass only the webservice name and the factory will return an instance of the requested service. Internally the factory will check its cache to see if there is still any valid webservice instance to return, if there is none then it will use the directory service to obtain the latest WSDL for the requested webservice. With the WSDL the factory will create a new instance of the webservice, store it on the cache and return it to the calling application. After that, any requests for the same webservice name will be served from the cache without the need to re-instantiate the webservice again.

Directory Service

At the center of wscandis is the Directory Service, this is a central location that maps webservice WSDLs addresses to arbitrary names. It is up to the actual implementation of wscandis to use a consistent naming convention to identify the WSDLs. Thus, the directory service allows for WSDL lookups just by using a commonly agreed name. Table 1 displays a simplified view of how the Directory Service is organized. A benefit of this solution is that the use of a standard name abstracts the client from the details of where a webservice is actually located or even the details of their implementation. For example, a client application attempting to use a credit card webservice may only look for a simple name such as "com.uvi.creditCard.engine" instead of having to know about the full network location of the WSDL (i.e. http://some.where.in.network:port/in/some/directory/file?wsdl)

When working with webservices is common to have two versions of the same service, one for development use and another for production use. When this is the case the application itself must be aware of its own executing environment, that is, whether it is being executed on a development server or in a production or "live" server. Then the application uses this information to choose between the different WSDLs in order to make the call to the desired webservice. This situation can easily get out of hand when more development servers are added, requiring the application to be aware of where it is being executed, thus reducing its portability.

To address this issue, the Directory Service in wscandis is implemented as a basic rule-based system, in which the address reported by the directory depends on who is asking. For example, a rule can be added so that whenever a client located in a development server asks for a given webservice a special "development-only" WSDL address is returned, otherwise the real "live" WSDL is sent back.

This solution allows for several interesting possibilities, for example you may restrict the directory service to only respond to requests from certain domains. Of course, this will only block the resolution of the webservice name and not the access to the actual service. A more interesting possibility is to make the same client application behave differently by pointing it to different webservices based on the location of the client.

Additionally, all the responses from the Directory Service contain a "TTL" or "Time-To-Live" field, which indicates the time in minutes for which the provided response should be considered valid. After a response has expired, whoever is using the Directory Service should query it again and obtain a new response. This mechanism eliminates the need of clients to be constantly querying the Directory Service, since once an answer is obtained there will be no reason to query the Directory Service again for a period of time. Table 2 shows a more accurate depiction of how the information is stored on the Directory Service. When a request is received the referrer of the client will be compared with the "Referrer" field on each rule until the first match is found. The asterisk (*) is used as a "catch-all" wildcard that will match to whatever referrer is used. This is provided so that it is possible to create a "default" answer for the webservice name.

Using WSCandis

To use WSCandis in your application you must first put a copy of the WSCandis package on your root directory, or if you prefer to use a different location create a CF mapping named "WSCandis" to wherever the package is stored.

On the application side the key element of WSCandis is the webServiceFactory component. This is the CFC that will act as a gateway to all the WSCandis functionality. It is important to note that the cache exists as part of the webServiceFactory instance, so in order for the caching to be effective, this same instance must remain available throughout the application, for example by storing it on the Application or Server scopes.

To instantiate the webServiceFactory use the following code:

This code snippet will store the webServiceFactory instance on the Application scope. The variable serverWSDL is used to indicate the location of the DirectoryService WSDL. Also, make sure that this code snippet is only executed once for the lifetime of the application, since executing it again will effectively clear the cache. On the other hand, re instantiating the webServiceFactory is also a good way of flushing the cache.

Later, whenever your application requires the use of a webservice, you will only need to use the following line to get an instance of the webservice stub:

Where "com.oscararevalo.test" is the name under which the webservice is registered on the wscandis server. As you can see, the application is completely oblivious to the actual location of the webservice, or even that there is a caching mechanism involved. From the application point of view, the only thing that matters is the name of the webservice. Furthermore, the names for the webservices can be set to follow any naming convention that is suitable for the enterprise. As mentioned before, an additional benefit, is that using this mechanism makes the application code completely portable between development and production servers without the need of changing the code or having the application itself try to figure out whether it is in production or development modes.