RESERVING IMMUTABLE SERVICES THROUGH WEB

SERVICE IMPLEMENTATION VERSIONING

Robert Steele, Takahiro Tsubono

Universit of Technology, Sydney, PO Box 123, Broadway 2007, Sydney, Australia

Keywords: Web Services, versioning, version control

Abstract: Widespread adoption of a Web services-based paradigm for software applications will imply that

applications

will typically have potentially many dependencies upon Web services that they invoke or

consume. These invoked services might typically be available from a remote site and be under the

administration of third parties. This scenario implies a significant vulnerability of a Web services-based

application: one or more of the services which it consumes may become altered, hence potentially

“breaking” the application. Such alterations might be such as those that alter the WSDL signature of the

service or could be changes to the underlying service implementation that do not change the WSDL

signature. In this paper, we will focus on the second of these two cases and will introduce a versioning

system that can detect changes to service implementations and that can avoid the breaking of applications

that call services in the face of changes to the implementations of those called services.

1 INTRODUCTION

If the Web Service or Service Oriented Computing

paradigm is to attain widespread adoption there will

need to be a solution to the potential fragility of Web

service-based applications arising through their

dependencies on called Web services. This is

particularly true for shipped applications that can no

longer be modified to accommodate any changes to

Web services that they call.

There are two types of changes that can occur to

Web se

rvices. One type of change involves a change

to the service’s WSDL signature: that is, a change to

the service’s set of operations or to their parameters

or parameter types. A second type of change

involves changes to the service’s underlying

implementation that leaves the WSDL signature

unaffected.

Although there are many different causes that

may b

reak the client applications, changes to the

service implementations are significantly risky

which directly influence behaviour of the services.

DLL Hell (Eisenbach, et.al., 2002) was a major issue

that broke other applications in response to

application installations and updaters replacing

shared resources. The problem was not only caused

by inherent software entities, e.g. libraries and

executables, being swapped with their old versions,

but also by new versions producing backward-

incompatibility or new bugs (Anderson, 2000).

The solution of DLL Hell was to provide each

plication with the infrastructure of reserving

dependent software entities that are never updated

by other applications. Having learnt from this

experience, the Web service implementation

versioning proposed here reduces risks of “service

hell” for both service providers and requestors by

means of allowing client applications to continue to

use the same versions of services.

1.1 Motivation

A new version of an existing service often replaces

the old version rather than leaving two versions of

the same services operational simultaneously. This is

due to various reasons such as added cost of

maintenance. The old service requestors assume that

service providers never break the existing service

calls. However, such an assumption cannot be

guaranteed in the scenario where existing service

calls use new service implementations that client

applications have not been built and tested against.

Regardless of dynamic or static binding, if the

revious version of the service is unavailable,

125

Steele R. and Tsubono T. (2005).

RESERVING IMMUTABLE SERVICES THROUGH WEB SERVICE IMPLEMENTATION VERSIONING.

In Proceedings of the First International Conference on Web Information Systems and Technologies, pages 125-132

DOI: 10.5220/0001227401250132

 SciTePress

service requestors do not have a choice other than to

upgrade to the new version. However, even when

multiple versions are made available, the service

calls are redirected to the one specified by service

providers, not by service requestors. There is no

standardized infrastructure for service requestors to

have intervention into the choice of versions.

The business needs vary across service

requestors. They may not be willing to upgrade to

the new services simply because the current version

provides sufficient functionality (Irani, 2001), while

some other service requestors may. As the number

of service requestors increases, it becomes

complicated to make a modification to the existing

services in a way all those service requestors

involved agree. Leaving the current version of the

Web service allows the service provider to be

released from receiving unexpected claims resulting

from the arbitrary decision to update an existing

service.

Currently UDDI (OASIS, 2004) does not support

finding a version of services based on the versioning

semantics, e.g. meaning of major numbers. The

service requestors need to know the relationship

between versions prior to choosing the appropriate

version of the desired service. However, as the

format of versions and the versioning scheme are

currently not standardized, thus at the worse case, it

could be unique to each service provider. While

Web service orchestration grows in popularity in

response to its capability of SOA (Service Oriented

Architecture), such a non-standardized versioning

scheme increases the complexity of configuration

for service binding. As an example, if a service

endpoint was dynamically chosen from a pool of

services that all claim a conformance to a

standardized service interface definition in a given

industry, a client application may need to apply

different version selection mechanisms to each

service provider.

Even though a service requestor may see the

same WSDL signature, changes may be opaque to

service description. As the service implementation is

basically invisible to client applications, there is no

means for client applications to detect or verify

changes to the target service implementation.

On the other hand, service modification also adds

to the work of developers by enforcing the backward

compatibility when an existing service is to be

updated. However, the backward compatibility issue

is not only on the service interface description, but

also on the semantics of defined data types and the

immutability of the returned set of data against all

possible formation of inputs on a given state. In this

scenario, testing applications in a way functions

retain the same output is full of complexity.

Moreover, to keep the service interface backward

compatible, new service interfaces constrain

available modifications to fall into some types such

as the addition of operations or new optional

parameters to existing operations (Brown and Ellis,

2004; Butek, 2004; W3C 2003). As time goes by, if

these constraints are followed, the service interfaces

grow in their complexity. For instance, when a

deletion of a service operation is denied,

modification continues increasing service operations.

At some point, the maintenance of all operations and

maintenance of the consistency of some of their

attributes/policies such as naming convention,

becomes complex.

To reduce the number of versioned services in

operation, service providers have to own the

responsibility for the consequence of the service

upgrade. Web service implementation versioning

aims to guarantee that service providers do not

dispatch existing service calls to a different version

of the same service without client agreement.

1.2 Paper Outline

Firstly, the current Web service versioning methods

and relevant technologies are described in the next

section. In Section 3, an overview of our Web

service versioning approach will be presented. The

architecture and the procedure for the use of the

version-aware Web service server are then described

in Section 4. The forthcoming issues are discussed in

Section 5. Finally, Section 6 concludes the paper by

wrapping up the presented idea and providing

proposals for the future work.

2 BACKGROUND

The topic of maintaining the association of an

application and its interdependent components is not

new. Some researches and vendors addressed the

solutions using a versioning strategy. Plasil et. al.

(1998) presented SOFA/DCUP (SOFtware

Application, Dynamic Component UPdating) - a

way to define a set of nested versioned components

and to update a specific component at runtime. .NET

Framework (Microsoft, 2005) tightly couples

applications and the required libraries based on the

assembly versions. Java Product Versioning

Specification (Sun Microsystems, 2003) defines the

method of comprising version details in a package.

To the extent of our knowledge, none of the research

papers have targeted the versioning of Web services

at the time of writing. However this issue is

currently active within the Web Service Description

Working Group (2005). The relevant technologies

and issues are described in the following subsections.

WEBIST 2005 - INTERNET COMPUTING

126

2.1 Version Identification

Where the discussion of Web service versioning is

seen, two approaches are often considered to resolve

the issues of which elements and layers of

application architecture carry version information:

an inclusion of the version in (1) namespace (W3C,

1999) of WSDL elements or (2) service endpoint

URLs.

The former utilizes a namespace in WSDL that

uniquely establishes the logical scope for a group of

WSDL elements. Thus, this versioning strategy

defines a unique namespace for each version of a

service or an operation, for example. As the

namespace does not directly deal with the service

implementation, it needs to be mapped to an

identifier of software entities, which a SOAP (W3C,

2004a) engine can recognise. Web services for J2EE

specification (IBM, 2003) defines to map a

namespace to a Java package (Gosling, et. al., 2000)

that dispatches a service call to an instance of the

class drawn from the associated package.

A version appended URL is often seen on the

Internet. While the format of a version differs in the

purpose of its use, the date-based format is

sometimes preferred than a tuple of incremental

integers. A benefit of using the date format is that

clients can intuitively find the release date, while no

indication of version implications hides the

relationship between different versions.

Regardless of the formats, URL-based

versioning for Web services causes an infrastructural

issue for Web services architectures. The problem is

in the layer at which URL is evaluated. As for HTTP,

a web server is in charge of evaluating incoming

HTTP requests and forwards them to wherever the

URL is linked to. Thus, if a version selection

mechanism exists in this scenario, the web server is

in charge of parsing a version. Moreover, as such a

server is beyond the control of a SOAP engine, the

versioning issue is forced up to the transport

protocol. Thus, the version-parsing mechanism must

be implemented for every transport protocol. Tasks

of version identification could be delegated to a

layer below the URL in order to insulate a service

endpoint from the versioning issues and, therefore,

service endpoints remains abstract representation of

service location.

2.2 Change Notification

Apart from the versioning method, clients need to

know the occurrence of changes to the service

interfaces and implementation. Some proposals have

been available for informing the client interested

parties of such events.

NSPF (Kalali, et. al., 2003a) and later SOMR

(Kalali, et. al., 2003b) are proposals of frameworks

for notifying service requestors about the status of

services such as availability and changes to service

interfaces. Web Services Eventing (Box, et.al, 2004)

and Web Services Notification (Akamai, et.al, 2004)

are the followers for standardizing such notification

architecture.

The latest UDDI version 3 (W3C, 2004b) also

implemented Subscription API, which notifies

changes in the UDDI registry to its subscribers.

However, the UDDI registry maintains a service

endpoint and the location of the WSDL rather than

the actual WSDL document. As changes in service

implementation are not necessarily reflected to the

service endpoint or WSDL location, the notification

is not invoked without service providers deliberately

altering the registered service description. Thus

maintaining a WSDL repository as suggested by

NSPF and SOMR is still beneficial in terms of

detecting changes in service interfaces.

Unfortunately, service providers are still free of

restrictions when changing implementations behind

the scenes without altering the WSDL. Furthermore,

even though non-changed services might be

maintained by a service provider, a part of their

system may start accessing altered software entities

from third parties, should the dependency of those

entities be disregarded.

2.3 Version Semantics

A typical format of a version number conveys the

interpretation rule and version semantics, by

assigning meaning to each segment of a version and

by reserving specific letters. Although, a number of

well-defined numbering schemes are available

nowadays, to the extent of our knowledge, nothing is

practically accepted as the global standard.

However, many have commonality in ruling the

semantics.

From the perspective of those who are affected

by version changes, the interest is often in the

backward compatibility with the old version. Many

publications on versioning distinguish numbers into

major and minor portions for this purpose.

Typically, major enhancements imply a possibility

of backward incompatibility, whereas minor

enhancement is backward compatible (Brada, 2000;

W3C, 2003).

Vendors concerned with the unit of low-level

software entities equip their published programming

languages with the ability of expressing precise

changes such as revision and build numbers. .NET

Framework (Microsoft, 2005) tightly couples

applications and the required software entities based

RESERVING IMMUTABLE SERVICES THROUGH WEB SERVICE IMPLEMENTATION VERSIONING

127

on the assembly versions. Java Product Versioning

Specification (Sun Microsystems, 2003) defines the

method of comprising a version in a Java package.

In either case, the version details are attached to a set

of software entities, a Java package or .NET

assembly. The relationships between those packages

or assemblies are comparable in relation to the

version semantics. However, these schema come

with a manual configuration of a version and

therefore, there is nothing to bar stating

incompatible changes as compatible.

3 A VERSION-AWARE WEB

SERVICES SERVER OVERVIEW

The server-side system needs to enforce non-change

of version unless the consumer explicitly chooses to

change. This implies that a service-based application

will not unexpectedly break due to changes in the

service implementation. Apart from this basic

motivation, Web service implementation versioning

yields benefits for improving manageability,

reliability, flexibility and visibility of the versioned

services. The major features are summarized as

follows:

• Modification events are enforced to be

reflected from implementation to services.

Thus, service-level version management

become more reliable.

• Inter-service compatibility for service

orchestration is maintainable in relation to

version dependencies (Andrews, et. al.,

2003).

• SCM (Software Configuration

Management) systems on the client side

can manage dependencies of their

applications and remotely implemented

Web services in relation to the versions.

• Developers are allowed to implement both

backward compatible and incompatible

changes to the same endpoint. The URL of

the service endpoint maintains its

representation as of service marketing time.

• Version management details such as a

history and the version graph can be made

available to client applications.

At the time of writing, many extensions to the Web

service architecture e.g. WS-Security and WS-

Reliability are emerging. The SOAP header and its

handler provide a flexible way of adding pre- and/or

post-message processing functionality to Web

services. A version-aware Web service server

utilizes this mechanism by simply incorporating the

version information into the SOAP header. The

considered architecture here is the component based

deployment of service implementations. The

constituents are summarized below.

3.1 Change Detection

For the version-aware Web service server to monitor

the service implementation for changes, some

changes in the component repository and the

configuration of the components’ container should

be transparent to the version management systems.

Therefore, version management systems and

application servers need to collaborate closely with

each other. Resulting benefits: (1) separating roles of

resource management from container specific tasks,

(2) making version management systems

independent of a particular application server as well

as other systems/servers, and (3) enabling version

management of fine-grained software entities such

as packages and classes. Application servers should

detect changes that have occurred to the relevant

component by either push or pull semantics,

otherwise the use of modified components should be

denied. The implementation of the change detection

functionality depends on the SCM systems and will

not be discussed further in this paper.

3.2 Service Immutability

In order to ensure immutability of service

implementations in the component repository, the

version-enabled Web service server uses a digest - a

fingerprint of the service implementation. The

hashing functions, MD5 (Rivest, 1992) and SHA-1

(Eastlake, 2001), are two major candidates to

generate such digests. If a digest is sent with a

SOAP message, the service implementation of

requested version is verified against this. A digest

mismatch will always be a result if the

implementation changes. A digest is generated and

stored for each version of a service. The SCM

system needs to know the managed (and potentially

unmanaged) software entities.

A version-aware Web service server provides a

built-in function for service requestors to retrieve

and preserve the digest of a particular service

version. Service requestors can then verify non-

changes to the service implementation by matching

the local and remote copies of the digests. To avoid

modification to the functions of digest generation,

this function needs to be kept built-in.

WEBIST 2005 - INTERNET COMPUTING

128

3.3 Version Parser

Web Service Implementation Versioning is based on

the idea that multiple versions of service

implementations are available simultaneously.

Therefore, the version-enabled Web service server

should be able to parse a version out of a service

request message. Specifically, this is done by a

Version Handler.

The version number is included in a header of

SOAP messages. When the Version Handler detects

the existence of a version header named Service

Version Header (SVH) in a SOAP request message,

it verifies the existence of the requested version

number against the version repository.

Unlike the case of attaching a version to the

URL, the version-aware Web service server can

differentiate errors due to incorrect endpoint and the

non-existence of a version number. Moreover, the

SVH is also extensible to support an intentional

versioning that takes account of user preferences

specified in the message. This is described in the

next section.

3.4 Version Selection

As seen by current practices, the version format may

not be simple especially where it is concerned with a

wide variety of applications or industry specific

variants. If the new version is not an evolved

component of its baseline, this is not even applicable

to a version graph (Conradi, 1998). However, we

take into account that the client’s concern is not the

format itself but the derived impact to the client

application from changes - compatibility.

While the format may vary among applications,

the interested version group (Bendix, 1996; Gergic,

2003), aka version sets (Conradi, 1998) which is a

versioned item, on the level of product unit is often

as simple as described by major and minor numbers

in this situation. Therefore, the selection of software

entities can be performed by two means: (1)

providing the complete version identifier or (2)

specifying a baseline (partial version identifier)

which leaves the selection of revision and build

numbers, for instance, to be derived from the client

preferences and the up-to-date version graph. Taking

the benefit of XML schema languages, the SVH can

constrain acceptable options of such client

preferences. On the other hand, if a version is totally

missing, then the choice will be either the latest up-

to-date version or a SOAP fault.

4 ARCHITECTURE

A version-aware Web service system provides a way

to decouple the versioned service implementation

from its interface description. Typically, changes to

service implementation occur more frequently than

to its interface. However, if an endpoint URL is to

indicate a version identifier, the number of endpoints

increases by each release of an existing Web service.

More precisely, regardless of non-change to the

abstract interface definition, the concrete

implementation definition may need to specify every

possible version formulation in WSDL. Here, the

version formulation also implies the possible use of

change-based systems for SCM. In such a case, the

possible versions of a service increase exponentially

by the number of versions of the underlying

software entities behind WSDL. This causes a

number of issues: (1) confuses clients with a wide

range of URLs, (2) may multiply dependencies of

WSDL files (3) complicates management of service

endpoints, (4) makes URL non-abstract (5) confuse s

the faults that arise from version mismatch and

incorrect endpoints.

As noted earlier, the solution to these issues we

propose here is to separate a version identifier from

the endpoint URL and the namespace exposed by

WSDL. Thus, the clients configure their application

with a version-free endpoint and namespace. This

reduces the need of re-configuration or re-

deployment of client applications when they want to

bind to new versions, which also help the URL to be

kept meaningful to humans. On the other hand, this

requires a way for the clients to retrieve the same

version of the WSDL document from the same

endpoint as well as for clients to preserve a version

identifier to which their applications are bound.

The following subsections describe procedures

for the service configuration, deployment and

invocation that occur for an installation of the

version-aware Web service server.

4.1 Implementation Deployment

The deployment of software entities go through a

SCM system. While not violating the container

functionality such as security and transactions,

actual service implementations are stored in a

component repository in the SCM. This is necessary

because the maintenance, storage and retrieval of

software entities are more efficient by using SCM

Figure 1 illustrates the procedure of implementation

deployment. The detailed steps follow the figure.

RESERVING IMMUTABLE SERVICES THROUGH WEB SERVICE IMPLEMENTATION VERSIONING

129

1. A software entity is added or checked-in to

the component repository.

2. The version management system generates

a new version for related services and an

associated digest.

3. The version dependency is updated in

response to the semantics of the new

version.

4. The version management system creates a

new component name derived from the one

in the base deployment descriptor. Then,

the new deployment descriptor is generated

with the new component name for

deployment.

5. The version management system notifies

the application server that the new version

of the existing components is available (or

the application server detects it by itself).

6. The application server configures itself

with the new deployment descriptor. The

new deployment does not affect other

components in use. The detailed procedure

of deployment follows the instruction from

application servers so that the architecture

does not defeat the benefits of current

deployment automation.

7. The version management system notifies

the SOAP engine of the new deployment

descriptor for new service configuration.

8. The details of the new version are added to

the UDDI registry if applicable.

9. If the service requestors subscribes for the

notification of changes in the UDDI

registry for the relevant services, the UDDI

communicates with the subscribers for new

versions available.

4.2 Client Application Configuration

Client applications are configured in much the same

way as for non-version-aware Web services. The

only difference is the existence of the SVH in

messages that contains version information. The

procedure is simply:

1. A service requestor obtains a WSDL file.

2. The latest version of WSDL file is returned

from the server.

3. Client applications are implemented in a

way that sends a SOAP message containing

version preferences in the SVH.

4.3 Service Invocation

Figure 1: Component deployment procedure

An additional handler in the SOAP engine means the

selection and verification of the correct version is

performed before the invocation of the service

implementation. The selection procedure utilizes

both a namespace of the requested services in the

SOAP message and the SVH. More specifically,

whereas the namespace in the message merely

specifies a version group, the SVH carries a specific

version local to the group.

For the service invocation, the version identifier

means a unique identity for a collection of software

entities that implement a service. When

incorporating the complete version identifier in the

request message, it is guaranteed to be dispatched to

the desired version of software entities. The Figure 2

illustrates the interactions of clients, SOAP engine,

components container in the application server and

version management system. For brevity, other

necessary SOAP handlers are omitted from the

figure. The detailed procedure is as follows:

1. A SOAP message arrives to an

intermediary or the ultimate destination,

either of which is capable of handling the

SVH.

2. When the SVH is detected, it searches for a

matching version identifier from the

version repository. If it is found, then the

Version Handler replaces the namespace of

the requested service in the message with a

version identifier. If it cannot be located or

multiple version identifiers are located,

then the request is rejected with an

appropriate SOAP fault.

3. If the SVH is missing, the service call is

either rejected or dispatched to the most up-

to-date version of the requested service.

4. The return message carries the original

namespace that is identical to the one in the

WEBIST 2005 - INTERNET COMPUTING

130

Figure 2: Service invocation procedure

request message, and a version identifier of

the service executed.

Finally, a version identifier and a digest are the

required ingredients for the verification of service

immutability. The verification of implementation

immutability occurs as a consequence of

incorporating a digest into the SVH; otherwise it

would not be performed. This is due to the

performance concern that the verification puts an

overhead to a service invocation. As well as

allowing clients to verify the service implementation

immutability, on the server side, this provides a

basic protection against the violating interaction that

attempt to alter the existing software entities without

creating a new version.

5 DISCUSSION AND FUTURE

WORK

The main drawback of this approach is the

maintenance complexity of different versions of

components deployed on the same application server.

As the version management is not the primary role

of a component container, it is not attractive to

implement version management functionality into an

application server.

Moreover, in the case of dynamic binding, the

newest service implementation is still only a choice

for a given industry-specified interface

Additionally, a slight performance latency can be

expected due to the process for the version

verification. However, this would not be a major

issue since such a comparison cost is lightened with

the help of caching.

6 CONCLUSION

The versioning issue is a long examined (and

potentially never ending) issue in software

development and management. The collaboration of

SCM systems and SOAP engine simplifies tasks of

both client applications and service developers by

providing automated support for version selection.

This also enables the SOAP engine to spot the exact

place of faults and return a more informative guide

to client applications. This paper has described the

fundamental requirements and methods of versioned

service deployment, version configuration, version

look-up, version identification and change detection,

which is sufficiently feasible to implement with the

help of currently available standards and software

products. The future work will target the evaluation

of architectural resistance to malicious modification

of version identification and service implementation.

REFERENCES

Akamai Technologies, Computer Associates International,

Fujitsu Laboratories of Europe, Globus, Hewlett-

Packard, IBM, SAP, AG, Sonic Software, TIBCO

Software, 2004, Web Services Notification, ,

http://www-

106.ibm.com/developerworks/library/specification/ws-

notification

RESERVING IMMUTABLE SERVICES THROUGH WEB SERVICE IMPLEMENTATION VERSIONING

131

Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein,

J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte,

S., Trickovic, I. & Weerawarana, S. 2003,

Specification: Business Process Execution Language

for Web Services Version 1.1,

http://www-

128.ibm.com/developerworks/library/ws-bpel/

Anderson, R. 2000, The End of DLL Hell, Microsoft

Cooperation,

http://msdn.microsoft.com/library/en-

us/dnsetup/html/dlldanger1.asp

Bendix, L. 1996 'Fully Supported Recursive Workspaces ',

in, Proceedings of the SCM-6 Workshop on System

Configuration Management Springer-Verlag, pp. 256-

261

Box, D., Cabrera, L.F., Critchley, C., Curbera, F.,

Ferguson, D., Graham, S., Hull, D., Kakivaya, G.,

Lewis, A., Lovering, B., Mihic, M., Niblett, P.,

Orchard, D., Saiyed, J., Samdarshi, S., Schlimmer, J.,

Sedukhin, I., Shewchuk, J., Smith, B., Weerawarana, S.

& Wortendyke, D. 2004, Web Services Eventing (WS-

Eventing), IBM et.al,

http://www-

106.ibm.com/developerworks/webservices/library/spec

ification/ws-eventing/

Brada, P. 2000, SOFA Component Revision Identification,

Department of Software Engineering, Charles

University, Prague.

Brown, K. & Ellis, M. 2004, Best practices for Web

services versioning, IBM,

http://www-

106.ibm.com/developerworks/webservices/library/ws-

version/

Butek, R. 2004, Make minor backward-compatible

changes to your Web services, IBM,

http://www-

106.ibm.com/developerworks/webservices/library/ws-

backward.html

Conradi, R. & Westfechtel, B. 1998 'Version models for

software configuration management ', ACM Comput.

Surv. , vol. 30 no. 2 pp. 232-282

Eastlake, D. & Jones, P. 2001, US Secure Hash Algorithm

1 (SHA1), RFC Editor.

Eisenbach, S., Jurisic, V. & Sadler, C. 2002, 'Feeling the

way through DLL Hell', In The First Workshop on USE

‘02, http://joint.org/use2002/, Málaga, Spain.

Gergic, J. 2003, 'Towards a versioning model for

component-based software assembly', In Proceedings

of ICSM 2003, pp. 138-147.

Gosling, J., Joy, B., Steele, G. & Bracha, G. 2000, The

Java Language Specification, viewed 19 Jan 2005

http://java.sun.com/docs/books/jls/.

IBM 2003, Web services for J2EE Specification,

http://jcp.org/aboutJava/communityprocess/final/jsr921

Irani, R. 2001, Versioning of Web Services - Solving the

Problem of Maintenance,

http://www.webservicesarchitect.com/content/articles/i

rani04.asp

Kalali, B., Alencar, P.S.C. & Cowan, D.D. 2003a 'NSPF:

Designing a Notification Service Provider Framework

for Web Services ', in, Revised Papers from the NODe

2002 Web and Database-Related Workshops on Web,

Web-Services, and Database Systems Springer-Verlag,

pp. 73-90

Kalali, B., Alencar, P. & Cowan, D. 2003b 'A service-

oriented monitoring registry ', in, Proceedings of the

2003 conference of the Centre for Advanced Studies on

Collaborative research IBM Press, Toronto, Ontario,

Canada pp. 107-121

Microsoft 2005, .NET Framework,

http://msdn.microsoft.com/netframework/.

OASIS 2004, UDDI Version 3.0.2,

http://uddi.org/pubs/uddi-v3.0.2-20041019.htm.

Plasil, F., Balek, D. & Janecek, R. 1998, 'SOFA/DCUP:

Architecture for Component Trading and Dynamic

Updating', In Proceedings of ICCDS '98, IEEE CS

Press, Annapolis, Maryland, USA, pp. 43-52.

Rivest, R. 1992, The MD5 Message-Digest Algorithm,

RFC Editor.

Sun Microsystems 2003, Java Product Versioning

Specification,

http://java.sun.com/j2se/1.4.2/docs/guide/versioning/sp

ec/versioning2.html

W3C 1999, Namespaces in XML,

http://www.w3.org/TR/REC-xml-names/.

W3C 2003, Versioning XML Languages,

http://www.w3.org/2001/tag/doc/versioning.

W3C 2004a, SOAP specifications,

http://www.w3.org/TR/soap/.

W3C 2005, Web Services Description Working Group,

http://www.w3.org/2002/ws/desc/.

W3C 2004b, Web Service Description Language (WSDL),

http://www.w3.org/TR/wsdl.

WEBIST 2005 - INTERNET COMPUTING

132