Web Services Architecture Requirements

01 April 2002

This version:
Previous versions:
Daniel Austin, W. W. Grainger, Inc. <austin.d@ic.grainger.com>
Abbie Barbir, Nortel Networks, Inc. <abbieb@nortelnetworks.com>
Sharad Garg, The Intel Corporation <sharad.garg@intel.com>


This draft is provided to the working group for discussion only and represents a very early version of this document. Readers may well expect significant changes in content and organization over time.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


The use of Web Services on the World Wide Web is expanding rapidly as the need for application-to-application communication and interoperability grows. These services provide a standard means of communication among different software applications involved in presenting dynamic context-driven information to the user. In order to promote interoperability and extensibility among these applications, as well as to allow them to be combined in order to perform more complex operations, a standard referernce architecture is needed. The Web Services Architecture Working Group at W3C is tasked with producing this reference architecture.

This document describes a set of requirements for a standard reference architecture for Web Services developed by the Web Services Architecture Working Group. These requirements are intended to guide the development of the reference architecture and provide a set of measurable constraints on Web Services implementations by which conformance can be determined..

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this series of documents is maintained at the W3C. .

This document is a preliminary editor's draft of the Web Services Architecture Working Group which is part of the Web Services Activity.

The Working Group intends that this document will at some point become a Working Draft.

The Web Services Architecture Working Group will not allow early implementation to constrain its ability to make changes to this document prior to final release. Publication as a Working Draft does not imply endorsement by the W3C Membership. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Comments on, and discussions of this draft can be sent on the (archived) public mailing list www-ws-arch@w3.org.

This document may be available in translations in the future. The English version of this specification is the only normative version.

Due to the architectural nature of this document, it affects not only a large number of W3C Working Groups, but also software developers, content developers, and writers and users of specifications outside the W3C that have to interface with W3C specifications.

Table of Contents

1 Introduction
    1.1 What is a Web Service?
2 Requirements Analysis Method
    2.1 Understanding Critical Success Factors Analysis
    2.2 The Analysis Heirarchy
        2.2.1 Mission, Vision, and Values
        2.2.2 Goals
        2.2.3 Assumptions and Information Needs
        2.2.4 Problems and Gap Analysis
        2.2.5 Critical Success Factors
        2.2.6 Analysis Matrix: Problems v. CSFs
3 Requirements
4 User Scenarios
5 Glossary
6 Acknowledgements
7 References
    7.1 Normative References
    7.2 Informative References

1 Introduction

1.1 What is a Web Service?

The group has jointly come to agreement on the following definition:

Web Service

[Definition: A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols]

2 Requirements Analysis Method

Many methods of analyzing requirements for software systems are available. While each of them has strengths and weaknesses, the Web Services Architecture Working Group has decided to make use of two methods concurrently, in the hope that together each of these methods will produce a well-defined set of requirements for Web Services Architecture. The two methods chosen are the Critical Success Factor Analysis method, which will be supplemented through the use of gathering Usage Scenarios. Both of these methods are useful but represent different approaches to the problem of gathering requirements.

The Working Groups intends to use these methods together and to cross-reference the results of each approach to ensure consistency of the overall architectural direction. By ensuring that the requirements each serve to meet the goals of the Working Group through the CSF analysis, and also ensuring that the architecture is consistent with the envisioned Usage Scenarios of the Working Groups in the Web Services activity, we can develop a set of architectural requirements that will provide an architectural model that meets the needs of all of those involved.

Note that in the case of Usage Scenarios, the vast majority of these are taken from the work of other W3C Working Groups in the Web Services Activity domain. Few individual Usage Scenarios will be developed by the Web Services Architecure Working Group directly, and those only in response to perceived gaps or omissions in the work of other Working Groups.

2.1 Understanding Critical Success Factors Analysis

2.2 The Analysis Heirarchy

2.2.1 Mission, Vision, and Values Mission

The mission of the Web Services Architecture Working Group is to develop and maintain a standard reference architecture for Web Services. Vision

The W3C Web Services Reference Architecture is intended primarily for the use of other working groups specifying the components identified in the architecture, secondarily for developers implementing the components, and incidentally for end users of those components. The exposition of the reference architecture must, to the greatest extent possible, be understandable by an experienced software designer or developer: it should use a minimum of specialized jargon, employ simple declarative sentences wherever possible, and be organized and illustrated in a way to minimize the amount of effort required to understand it. The reference architecture should specify as few components and relationships as are absolutely necessary. The reference architecture should contain examples intendedto clarify how an application programmer would use its components to build typical applications that utilize web services.

2.2.2 Goals


A few words on the naming convention used here and throughout this document: all goals, critical success factors and requirements are labelled according to the following convention:


[D-] indicates that the item is in a draft state

A indicates that this is an architectural item.

[G|F|R|UC] is one of Goal|Critical Success Factor|Requirement|Use Case.

nnnn indicates the sequence number of the item.

Proposed Goals for the Web Services Architecture Working Group>

(Each of the following goals is stated as a predicate to the following statement.)

To develop a standard reference architecture for web services that:


provides a complete reference framework that encourages the development of interoperable software products from multiple vendors and provides a defensible basis for conformance and interoperability test suites

  • AC011-A - Encourage the development of interoperable software products.

    • AC0111-A - Ensure that no individual implementor is favored over others.

    • AC0112-A - Identify all interfaces and messaging protocols within the architecture in a standardized way.

  • AC0012-A - Develop a means of identifying conformance so that testing software can be constructed.

    • AC0121-A - The WSAWG should co-ordinate with WS-I on development of conformance test suites

  • AC0013-A - Clearly define and publish a standard reference architecture document for implementors.

    • AC0131-A - Clearly define specific factors that determine conformance, while leaving sufficient slack in the system for vendors to add value.

Goal D-AG0001 CSF Analysis


provides modularity of web services components, allowing for a level of granularity sufficient to meet business goals

  • AC0021 - Provide conceptual clarity to allow developers to share ideas and code

    • AC0211 - Reduce complexity by decomposition of the components's functionality and its position within the architecture

    • AC0212 - Ease development, testing, and maintenance by providing a logical, easy to understand, and consistent organization

      • AC2121 - Decrease debugging time by localizing errors due to design changes

    • AC0213 - Allow the creation of generic rules, methods, and procedures to aid in consistent development practices

  • AC0022 - Support object-oriented design principles by encouraging encapsulation and information hiding by components of the architecture

    • AC0221 - Encourage reuse by creating well-defined modules that perform a particular task

    • AC0222 - Allow the creation and deployment of configurable objects that the end user can tailor for different purposes in a standard way.

  • AC0023 - Provide for Increased flexibility and maintainability because single components can be upgraded or replaced independently of others

    • AC0231 - Support a variety of end-user interface and deployment environments by allowing standardized subsets and supersets

Goal D-AG002 CSF Analysis


is sufficiently extensible to allow for future evolution of technology and of business goals

  • separates the transport of data or means of access to web services from the web services themselves

  • description of web services be clearly separated into abstract descriptions ("what") from their concrete realizations ("how"), or put another way, separate design time aspects from run-time aspects

  • technologies using this architecture should allow for extensibility via inheritance, i.e., deriving one type from another

  • technologies following this architecture should not impede the development of complex interaction scenarios likely for future business interactions

  • security policies, handling various QoS aspects, negotiation of service level agreements (SLAs) must be facilitated by technologies conforming to this architecture


ensures platform independence of web services components in a way that does not preclude any programming model nor assume any particular mode of communication between the individual components

  • Focus on using platform independent development tools and languages.

  • Interfaces to web components must be properly defined and designed.

  • Focus on defining the architecture in terms of components and the relationships between them. Components are defined in terms of interfaces, that defines their inputs and outputs and also the form and constraints on those inputs and outputs. The relationships between components are described in terms of messages and the protocols by means of which these messages are transmitted among the interfaces of the components that make up the architecture.

Derived Requirements

  • a. Consistent definition of web components

  • b. Good definition of web component Interfaces their inputs/outpus and their constraints.

  • c. Use XML based techniques for defining messages/protocols for invoking web components


Make sure the reference architecture is as simple as possible and is defined such that it does not impose high barriers to entry for its intended audience

  • The reference architecture should be easily understandable by the target audience.

    • does it avoid specialized jargon not familiar to ordinary software designers?

    • is it stated in simple declarative sentences?

    • is it organized in a way that allows important points to be located?

    • does it use illustrations to visually describe key components and relationships?

The reference architecture should be as minimal as possible

  • How many components does it describe?

  • How many relationships among the components does it describe?

  • How do these figures compare to those of notable exemplars of good reference architectures?

  • Could any components or relationships be removed without significantly limiting the value of the architecture?

The reference architecture should simplify the task of a programmer writing interoperable implementations of specifications of components described by the architecture.

  • is the role played by each component in the overall architecture stated clearly?

  • are the interdependencies among components noted explicitly?

  • are existing specs that fufill the role of a given component referenced?

  • are the resulting implementations actually interoperable?

The reference architecture should simplify the task of an application programmer using the specifications it describes.

  • does the reference architecture not force a programmer to use exotic constructions?

  • Can the architecture be implemented without large amounts of code?

  • Does it allow simple invocations as well as elaborations with more functionality when building web services or applications that employ web services?


addresses the security of web services across distributed domains and platforms

1) The construction of a Web Services Threat Model based on thorough analysis of existing and foreseeable threats to Web Service endpoints and their communication.

2) The establishment of a set of Web Services Security Policies to counter and mitigate the security hazards identified in the thread model.

3) The construction of a Web Services Security Model that captures the security policies (to be executed by security mechanisms).

4) The realization of the security model in the form of a Web Services Security Framework that is an integral part of the Web Services Architecture (which is the ultimate deliverable of this working group).



WSAGenReq011 The architecture MUST provide an interface for web services to directly communicate with their underlying infrastructure.

The interface is for negotiating services that an infrastructure may provide to, or perform on behalf of, a requesting web services. Such value-added services may include: security, content delivery, QoS, etc. For instance, a web service may instruct (via the interface) the security agents of its infrastructure to defend against DOS/DDOS attacks on its behalf.

See also WSASecReq001.


There are six aspects in the security framework for web services architecture: Accessibility, Authentication, Authorization, Confidentiality, Integrity, and Non-repudiation. Together they form the foundation for secure web services.

WSASecReq001 Accessibility to a web service can be impaired by DOS/DDOS attacks. It is understood that there's little a web service residing well above the transport layer of a network stack can effectively detect such transgression, let alone deploy countermeasures. Therefore, the security framework MUST provide recourse for web services to mitigate the hazard.

WSASecReq002.1 The security framework MUST include Authentication for the identities of communicating parties.

WSASecReq002.2 The security framework MUST include Authentication for data (sent and received by communicating parties).

WSASecReq003 The security framework MUST include Authorization, with allowance for the coexistence of dissimilar authorization models.

WSASecReq004 The security framework MUST include Confidentiality.

WSASecReq005 The security framework MUST include (data) Integrity.

WSASecReq006 The security framework MUST include Non-repudiation between transacting parties.

Note that there is a close relationship among WSASecReq002.1, WSASecReq002.2, WSASecReq005, and WSASecReq006, a la digital signature.

WSASecReq007 The security framework MUST include Key Management, pertaining to Public Key Encryption (PKE) and Key Distribution Center (KDC).

WSASecReq008 The security framework document SHOULD provide some guidelines for securing private keys, though the methods for securing private keys is outside the scope of the architecture.

WSASecReq009 The security framework document SHOULD recommend a baseline for trust models.


is reliable, and stable, and whose evolution is predictable over time

Nomenclature: reference architecture components are referred to as "standards" below.

Reliability of Architecture

CSF RA1. All standards are versioned.

CSF RA2. Non-circular standards: Each standard is specified without the use of another standard within the reference architecture except when a standard is an extension of another standard.

CSF RA3. A standard may depend only on non-proprietary standards - standards developed within open standards bodies (W3C, IETF, ISO, OASIS,...).

CSF RA4. When a standard uses other standards outside of the reference architecture, the exact versions of other standards will be specified. If the other standards do not have version numbers, WSA will create and assign version numbers and map to a particular instance of the external standard.

D-CSF RA4 Each release of the WS-A also should be versioned with the versions of the standards that go in the WS-A. Such a consistent set of versions will be called a "C-set" - for consistent set.

D-CSF RA5. Each such combination, as in R2 must be tested with a set of conformance tests.

D-CSF RA6. Extension to a standard by anybody must be submitted to WS-A with a C-set and a set of conformance tests.

Stability of Architecture

Stability of Architecture is defined under the "force field" of the reference architecture, i.e., when a standard changes, then the change will be clear and consistent with the rest of the reference architecture components.

CSF SA1. A new version of a standard will clearly describe its "backward compatibility" status with its earlier version in text.

CSF SA2. A new version of a standard will not conflict with other standards in the reference architecture that do not conflict with the old version of the standard.

CSF SA3. Evolvability in identified technologies/standards should be considered up front as much as possible from the point of view of interoperability with other standards [to prevent hasty change of standards]

Predictable Evolution of Architecture

CSF PE0. The reference architecture must define a framework for growth of the architecture.

CSF PE1. The reference architecture should identify its axes for evolution. [e.g., independent specification of WS interaction with WS selection of WS measure WS]

CSF PE2. The standards should be mapped to these axes. [e.g., independent specification, - WSDL interaction - XMLP selection - ? measure - ?]

CSF PE3. Non-normative extension guidelines to be specified for each standard

CSF PE4. Stagger "features" in a standard so that even software that implemented only the minimal features in the standard can interoperate with another software that implemented more features

CSF PE5. The version number is available for verification from the software that implements the standard to support CSF PE4


is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.

Simple visualization of architecture in the form of a two-dimensional diagram

Architecture supports the concepts used in commonly accepted design patterns.

Architectural components work together to form a logical whole.

Architecture does not do the same or similar things in mutually incompatible ways; it is not self-contradictory.

There shall not be wildly different means to achieve the same ends in the architecture.


is aligned with the semantic web initiative at W3C and the overall existing web architecture

Any meta data about any aspect of the Web services reference architecture should be expressible with an RDF based language (such as RDF itself, RDF Schema, DAML+OIL)


uses W3C XML technologies in the development of the web services architecture to the extent that this is compatible with the overall goals listed here.

Each new architectural area is representable in a syntactic schema language like XML Schema. I stress the "syntactic" adjective to schema language because the TAG has occasionally ratholed into HTML and RDF documents being "schema" languages.


is consistent with the existing web to the greatest extent possible.

CF1) The Web Services reference architecture complies with the architectural principals and design goals of the existing web.

Derived sub-goals:

CF1-A) universal identifiers

CF1-B) simplicity

CF1-C) opaqueness

CF1-D) decentralization

CF1-E) statelessness

CF1-F) scalability of component interactions

CF1-G) generality of interfaces

CF1-H) immediate deployment of components

CF1-I) intermediary components to reduce interaction latency

CF1-J) enforces security

CF1-K) encapsulate legacy systems

CF1-L) caching semantics

CF1-M) platform independence

CF2) The Web Services reference architecture recommends the use of existing web technologies which adhere to the above principals and which provide clear functional coverage of the responsibilities and constraints for a component identified in the reference architecure.

Derived sub-goals:

CF2-A) Use of a standard identifier technology (URI)

CF2-B) Use of a standard transport technology (HTTP/S over TCP/UPD/IP)

CF3-C) Use of a standard data encoding technology (XML)

In addition, the Working Group will also act to:


identify or create the use cases that validate the requirements and the web services architecture and illustrate the benefits of web services

The goal for the WSAWG and the architecture document should be to address a broad set of applications reflecting the diversity of the W3C membership as well as the organizations that we have identified as important liaisons (OMG, OASIS, etc.)

There should be a mapping between usage scenarios and requirements for the web service architecture document. I'm not sure we want a usage scenario to actually be the requirement. I think there is a difference between a requirement and a usage scenario.

The benefit of web services should be obvious from the usage scenarios. The architecture document introduction will probably talk about the benefits of web services. I would rather keep the usage scenarios short and not add the text that would be needed to explicitly state the benefits of each scenario.

In what way does a usage scenario validate a requirement? The form of a requirement will be "The web services architecture shall ..."

For example, "... shall define a way to describe web services". A related usage scenario might be "a web service provider publishes a description of its web service, and a web service user reads the description to determine how to invoke the web service." This requirement is derived from the usage scenario, so in a sense the requirement is valid because it relates to a usage scenario. If a requirement cannot be traced back to a usage scenario, then we can consider it invalid (or perhaps we would need to figure out a usage scenario for it). So, it would be a requirement of the requirement document to include a matrix showing the traceability between requirements and usage scenarios. We would then need to have traceability between the architecture document and each requirement in the requirements document.


co-ordinate with other W3C Working Groups, the Technical Architecture Groups and other groups doing Web services related work in order to maintain a coherent architecture for Web services

Go through the W3C review process, and satisfy dependencies as listed in the charter.

The documents produced are used as input to charter new Web Services Working Groups.

Maintain liaisons with relevant external groups, such as the ones listed in the charter and possibly others.


Closed because it was merged with D-AG0013


organize its efforts in such a way as to address vital time-to-market issues for its products, including iterating over successive refinements of the overall requirements for the standard reference architecture.

1. Is the Web Services Activity a center for web services standards specification, that is is the community able to start new working groups in a manner that is usable by the community?

2. Is the WSA perceived as a reliable forum for architectural guidance? Do other working groups ask for advice from the WSA, or do they not bother?

3. Is the WSA document perceived as usable and referenceable in time for products? New/revised products would be able to reference this WSArch doc if it was delivered in time for their products.

4. Does the WSA demonstrate a reasonable number of re-use decisions rather than re-inventing?

5. Is the architecture document regularly revised?

6. Is the architecture document regularly referenced by other specifications, including but not limited to W3C specifications?

7. Is there a lack of press/developer commentary that refers to time-to-market problems with WSA? To paraphrase, no press is good press on this issue.


identify architectural and technology gaps that prevent interoperability, recommend existing standards and technologies where available, and formation of working groups to formulate new, or to standardize existing, specifications or technologies for filling the gaps.

The Web Services Architecture WG should:

1. Identify what constitutes interoperability

1.1 in architectural realm.

1.2 in technological realm.

2. Identify existing

2.1 architecture that supports interoperability

2.2 technologies that support interoperability

3. Identify gaps

3.1 in architectural realm.

3.2 in technological realm.

4. Formation of WGs to address gaps

4.1 in architectural realm.

4.2 in technological realm.


provides guidance for the development of the web services infrastructure needed to implement common business functions in a standards-based environment


Is there a frameword within the web services architecture that will support at least an 80-20 of the functions currently offered by proprietary VAN's (Value Added Networks) to support EDI functions? In particular, will the web services architecture support reliable messaging, routing and intermediaries, unique ID and sequencing of messages and transaction processing?


provide a standard set of metrics for measuring aspects of Web Services such as reliability, quality of service, and performance, and to define a standard means of measurement of these metrics and instrumentation for management of Web Services.

1. Develop a standard convention of measuring Web Services metrics so different service providers, implementors and consumers can reach service level agreements.

1.1 The standard should include definitions of metrics such as Quality of Service, Reliability of Service and other metrics.

1.2 The reference architecture should provide guidelines on measuring those metrics.

1.3 Metrics can be independently verified.

2. Define standard management instrumentations to Web Services.

2.1 The standard should define but not limited to instrumentations such as starting, suspending, and retiring services.

2.2 The instrumentations should confirm to other goals of this working group.

2.3 The definition of management framework is out of scope. There are a number of such technologies available: www.dmtf.org.

2.4 The instrumentations may be exposed as Web Services.

3. Clearly define and publish reference architecture for implementors.

3.1 Clearly define and publish reference Web Services management model.


ensure reliable, stable, and predictably evolvable web services.

Web Services created using WSA can be reliably selected, accessed, and executed.

Web Services created using WSA can be implemented such that they are stable with respect to their definitions.

Web Services created using WSA may be evolved/extended while maintaining their reliability and stability.


To develop a standard reference architecture for web services that enables privacy protection for the consumer of a Web service across multiple domains and services.

Is it possible for a service consumer to know the privacy policies of the service provider(s) that it is going to deal with? (a.k.a. hooks for P3P)

Private data provision during a Web service transaction should not exceed the consumer's consent, where the consumer must be provided with reasonable means for opt-out.

2.2.3 Assumptions and Information Needs

2.2.4 Problems and Gap Analysis

2.2.5 Critical Success Factors

2.2.6 Analysis Matrix: Problems v. CSFs

3 Requirements

4 User Scenarios

D-UC0001: Fire-and-forget

Definition: A one-way message with no delivery semantics guaranteed.

Scenario Description:

A metrics collection service exposes an interface for applications running in an environment to report their application usage metrics. Instead of reporting individual metrics, these applications report a computed sum that represents the summary of their usage. Therefore, the loss of a message is not important because the next update will again provide an updated summary. In the interest of efficiency, the client applications are not interested in receiving any faults, and just want to send a message and forget about it until the next time. Another example service could be sending a stock price update every 15 minutes.

D-UC0002: One-Way Message With Guaranteed Delivery

Definition: A one-way message with guaranteed delivery.

Scenario Description:

A web service that provides a messaging service could be a higher-level interface over enterprise messaging capabilities such as JMS. On the publisher side, it exposes an interface that allows applications to publish messages to a logical messaging channel. The publishing clients do not expect to receive a response to their invocation, however, it is important for them to know that the message has been delivered. So while they make a one-way request, they do want to receive faults if the message could not be successfully published, whether due to a system error on the server side or due to an application error on the server side.

D-UC0003: Document Centric Computing

Definition: Services whose operations support document centric computing.

Scenario Description:

In this scenario, a web service is ebXML based web service that requires document-oriented computing. The operations that its interface includes are all actually asynchronous messages with no parameters. All the data to the messages is sent as document attachments. Its description document will then describe the data expected by its operations in terms of the expected attachments and not in terms of its parameters.

D-UC0004: Remote Procedure Call

Definition: A service being invoked remotely by passing parameters.

Scenario Description:

The sender invokes the service by passing parameters that are serialized into a message for transmission to the receiving server.

D-UC0005: Request with acknowledgement

Definition: Data exchange with status acknowledgment between sender and receiver.

Scenario Description:

A sender wishes to reliably exchange data with a receiver. It wishes to be notified of the status of the data delivery to the receiver. The status may take the form of: 1. The data has been successfully delivered to the receiver, or 2. Some failure has occurred which prevents the successful delivery to the receiver.

D-UC0006: Third party intermediary

Definition: Services interacting with each other via a third party.

Scenario Description:

A blind auction marketplace serves as a broker between buyers and suppliers. Buyers submit their requirements to the marketplace hub, which broadcasts this information to multiple suppliers. Suppliers respond to the marketplace hub where the information is logged and ultimately delivered to the buyer.

D-UC0007: Communication via multiple intermediaries

Definition: Services interacting with each other via multiple intermediaries.

Scenario Description:

An intermediary forwards a message to the ultimate receiver on behalf of an initial sender. The initial sender wishes to enforce the non-repudiation property of the route. Any intermediate message service handler that appends a routing message must log the routing header information. Signed routing headers and the message readers must be logged at the message handler that passes the message to the ultimate receiver to provide the evidence of non-repudiation.

D-UC0008: Asynchronous messaging

Definition: Services interacting with asynchronous messaging.

Scenario Description:

A sender sends a message asynchronously to a receiver expecting some response at a later time. The sender tags the request with an identifier allowing the response to be correlated with the originating request. The sender may also tag the message with an identifier for another service (other than the originating sender) that will be the recipient of the response.

D-UC0009: Multiple asynchronous responses

Definition: Services interaction requiring multiple asynchronous messaging

Scenario Description:

An application requests some information from a server, which is returned at a later time in multiple responses. This can be because the requested information was not available all at once (e.g., distributed web searches).

D-UC0010: Events and Event notification

Definition: Service provider notifies events, or consumer subscribes to events.

Scenario Description:

A WS provider can describe events generated by a service, and WS client may subscribe to events The underlying WS framework would take care of the event by either polling (sending a SOAP request) with a specified interval or registering a SOAP listener (endpoint) with the target WS (according to the event definition in WSDL). For example, an application can subscribe to notification of various aspects of a printer's status (e.g., running out of paper, ink etc.).

D-UC0011: Versioning

Definition: Services providing different versions of its interfaces.

Scenario Description:

A WS provider can describe versions of interfaces implemented by a service. WS client can bind to the necessary interface version. This way there is no ambiguity when WS provider changes service interfaces and client has created a static proxy that uses previous version of interfaces. WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.

5 Glossary


The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. [BASS98]


An association between an Interface, a concrete protocol and a data format. A Binding specifies the protocol and data format to be used in transmitting messages defined by the associated Interface.


A logical grouping of operations. An Interface represents an abstract Service type, independent of transmission protocol and data format.


The basic unit of communication between a Web Service and a Client: data to be communicated to or from a Web Service as a single logical transmission.


A set of messages related to a single Web Service action.


An association between a Binding and a network address, specified by a URI, that may be used to communicate with an instance of a Service. A Port indicates a specific location for accessing a Service using a specific protocol and data format.

Reference Architecture

A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems. The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures. First, it generalizes and extracts common functions and configurations. Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively.[Gallagher2000]

Web Service

A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols

6 Acknowledgements

7 References

7.1 Normative References

Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Reading, Mass.: Addison Wesley, 1998.
Gallagher, Brian P. Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study CMU/SEI-2000-TN-007 June 2000 (See http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.htm.)
Sadiq, W, Web Service Usage Scenarios, W3C Working Draft March 2002, Work in Progress (See http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/att-0043/01-ws-desc-usecases.html.)
Ibbotson, J. XML Protocol Usage Scenarios, W3C Working Draft, Work in Progress (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
Bullen, C. and J. Rockart -- A Primer on Critical Success Factors, MIT Sloan School of Management Working Paper 1220-81

7.2 Informative References

Yin, Kevin "A Refrence Architecture for Smart Web Services" Sun Developer Connection, August 2001 (See http://dcb.sun.com/practices/devnotebook/webserv_refarch.js.)