Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
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.
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 document series is maintained at the W3C.
This is the first W3C Working Draft of the Web Services Architecture Requirements document. It is a chartered deliverable of the Web Services Architecture Working Group, which is part of the Web Services Activity. Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group about Web services architecture requirements.
This first version of the requirements document is an early snapshot: it may contain conflicting and incomplete requirements and goals. The next version that the Working Group will publish will be more complete and polished.
Comments on this document should be sent to www-wsa-comments@w3.org (public archive). It is inappropriate to send discussion emails to this address.
Discussion of this document takes place on the public www-ws-arch@w3.org mailing list (public archive) per the email communication rules in the Web Services Architecture Working Group charter.
This is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
1 Introduction
1.1 What is a Web service?
1.2 Notational Conventions
2 Requirements Analysis Method
2.1 Understanding Critical Success Factors Analysis
3 The Analysis Heirarchy
3.1 Mission Statement
3.1.1 Mission
3.1.2 Users of Web Services Architecture
3.2 Goals
3.2.1 Top-level Goals
3.2.2 Critical Success Factors and Requirements
3.3 Analysis Matrix: Problems vs. CSFs
3.4 Analysis Matrix: User Scenarios vs. CSFs
4 Glossary
5 Acknowledgements
6 References
6.1 Normative References
6.2 Informative References
7 Change Log
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.
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]
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.
Note:
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-]A(G|F|R|UC)nnnn
[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.
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. Usage scenarios will be published separately.
The Critical Success Factors Analysis methodology for determining requirements is a top-down means of determining requirements based on the needs of the organization. For this reason it is well-suited for requirements analysis for large systems with many stakeholders and an audeience with multiple and sometimes conflicting interests. The CSF analysis method begins with a mission statement and then begins to divide the mission statement into a set of very high-level goals. These high-level goals are then further divided into Critical Success Factors, which themselves are then further broken down into multiple levels of a heirarchy, becoming more concrete. At the lowest level, each CSF becomes a requirement for the system; a single, well-defined task that must be accomplished in order to be successful. Along the way, problems to be solved and assumptions made are recorded.
Once the CSF heirarchy is established and a set of requirements has been derived, these can then be arranged into a matrix for comparison with the problems identified. In order to be considered complete, each problem must be fully addressed by one or more requirements.
By analysing the steps necessary to achieve success, and cross-referencing them against problems to be solved, a complete set of requirements can be determined that can then be correlated with specific user scenarios. Each of the requirements should apply to at least one user scenario, and generally more than one.
This methodology allows requirements to be determined that satisfy the needs of the organization and those of the user. Since architectural frameworks are built and maintained by organizations, this method allows us to create a well-defined and reasonably complete set of requirements.
The mission of the Web Services Architecture Working Group is to develop and maintain a standard reference architecture for Web Services.
The W3C Web Services Reference Architecture is intended primarily for the W3C Web Services Architecture Working Group to analyze, prioritize and characterize the technologies that are needed to fully realize an interoperable and extensible realization of the promise of Web Services. It is also intended for the use of other working groups specifying the technologies identified and described in the architecture. A secondary target audience for the architecture are the developers implementing the specified technologies, and the wider IT community that uses these technologies to deploy Web Services.
The Working Group has determined that at the highest level, its goals can be divided into 6 categories. Each of these is associated with the CSFs and requirements listed in section 3.2.2
Top-level Goals for the Web Services Architecture
D-AG0001 Interoperability
The Web Services Architecture should provide a reference platform for the development of interoperable Web Services across a wide array of environments.
Critical Success Factors for this goal:
DAC0001
DAC0004
DAC0016
D-AG0002 Reliability
The Web Services Architecture must be reliable and stable over time.
Critical Success Factors for this goal:
DAC0007
DAC0018
DAC0019
D-AG0003 Web-friendly
The Web Services Architecture must be consistent with the current and future evolution of the World Wide Web.
Critical Success Factors for this goal:
D-AC0009
D-AC0010
D-AC0011
D-AG0004 Security
The Web Services Architecture must provide a secure environment for online processes.
Critical Success Factors for this goal:
D-AC0006
D-AC0020
D-AG0005: Scalability and Extensibility
The Web Services Architecture must be scalable and extensible.
Critical Success Factors for this goal:
D-AC0002
D-AC0003
D-AC0005
D-AC0017
D-AG0006 Team Goals
The Web Services Architecture Working Group will work to ensure that the Architecture will meet the needs of the user community.
Critical Success Factors for this goal:
D-AC0008
D-AC0012
D-AC0013 (and D-AC0014)
D-AC00015
Proposed lower-level goals and CSFs 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
D-AC0001.1 - Encourage the development of interoperable software products.
D-AC0001.1.1 - Ensure that no individual implementor is favored over others.
D-AC0001.1.2 - Identify all interfaces and messaging protocols within the architecture in a standardized way.
D-AC0001.2 - Develop a means of identifying conformance so that testing software can be constructed.
D-AC0001.2.1 - The WSAWG should co-ordinate with WS-I on development of conformance test suites
D-AC0001.3 - Clearly define and publish a standard reference architecture document for implementors.
D-AC0001.3.1 - Clearly define specific factors that determine conformance, while leaving sufficient slack in the system for vendors to add value.
provides modularity of Web Services components, allowing for a level of granularity sufficient to meet business goals
D-AC0002.1 - Provide conceptual clarity to allow developers to share ideas and code
D-AC0002.1.1 - Reduce complexity by decomposition of the components's functionality and its position within the architecture
D-AC0002.1.2 - Ease development, testing, and maintenance by providing a logical, easy to understand, and consistent organization
D-AC0002.1.2.1 - Decrease debugging time by localizing errors due to design changes
D-AC0002.1.3 - Allow the creation of generic rules, methods, and procedures to aid in consistent development practices
D-AC0002.2 - Support object-oriented design principles by encouraging encapsulation and information hiding by components of the architecture
D-AC0002.2.1 - Encourage reuse by creating well-defined modules that perform a particular task
D-AC0002.2.2 - Allow the creation and deployment of configurable objects that the end user can tailor for different purposes in a standard way.
D-AC0002.3 - Provide for Increased flexibility and maintainability because single components can be upgraded or replaced independently of others
D-AC0002.3.1 - Support a variety of end-user interface and deployment environments by allowing standardized subsets and supersets
is sufficiently extensible to allow for future evolution of technology and of business goals
D-AR3001 separates the transport of data or means of access to Web Services from the Web Services themselves
D-AR3002 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
D-AR3003 technologies following this architecture should not impede the development of complex interaction scenarios likely for future business interactions
D-AR3004 modules that are orthogonal must be allowed to evolove indepently of each other and still work within the architecture
D-AR3005 modularity must support common business functions such as reliability, security, transactions, etc.
D-AR3006 specs that are created in conformance with the architecture do not have to go through a formal process to be considered conformant
ensures platform and device independence of Web Services in a way that does not preclude any programming model nor assume any particular mode of communication between the individual components
D-AC0004,1 Focus on using platform independent development tools and languages.
D-AC0004,2 Interfaces to web resources must be properly defined and designed.
D-AC0004,3 Focus on defining the architecture in terms of components and the relationships between them. Components are defined in terms of interfaces, that define 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.
The Web Services Architecture should:
D-AR4001 provide consistent definition of web resources
D-AR4002 provide well-defined interfaces for Web Services
D-AR4003 use XML based techniques for defining messages/protocols for invoking web resources
applies the principle of simplicity 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.
D-AC0501 does it avoid specialized jargon not familiar to ordinary software designers?
D-AC0502 is it stated in simple declarative sentences?
D-AC0503 is it organized in a way that allows important points to be located?
D-AC0504 does it use illustrations to visually describe key components and relationships?
The reference architecture should be as minimal as possible
D-AC0505 How many components does it describe?
D-AC0506 How many relationships among the components does it describe?
D-AC0507 How do these figures compare to those of notable exemplars of good reference architectures?
D-AC0508 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.
D-AC0509 is the role played by each component in the overall architecture stated clearly?
D-AC0510 are the interdependencies among components noted explicitly?
D-AC0511 are existing specs that fufill the role of a given component referenced?
D-AC0512 are the resulting implementations actually interoperable?
The reference architecture should simplify the task of an application programmer using the specifications it describes.
D-AC0513 does the reference architecture not force a programmer to use exotic constructions?
D-AC0514 Can the architecture be implemented without large amounts of code?
D-AC0515 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
AC0006.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.
AC0006.2 The establishment of a set of Web Services Security Policies to counter and mitigate the security hazards identified in the thread model.
AC0006.3 The construction of a Web Services Security Model that captures the security policies (to be executed by security mechanisms).
AC0006.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).
Requirements
D-AR6011 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.
| Editorial note | |
| The WG has not yet reached consensus on the merits of D-AR6011 and there is still considerable debate | |
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.
D-AR6001 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.
| Editorial note | |
| The WG has not yet reached consensus on the merits of D-AR6001 and there is still considerable debate | |
D-AR6002.1 The security framework must include Authentication for the identities of communicating parties.
D-AR6002.2 The security framework must include Authentication for data (sent and received by communicating parties).
D-AR6003 The security framework must include Authorization, with allowance for the coexistence of dissimilar authorization models.
D-AR6004 The security framework must include Confidentiality.
D-AR6005 The security framework must include (data) Integrity.
D-AR6006 The security framework must include Non-repudiation between transacting parties.
Note that there is a close relationship among D-AR6002.1, D-AR6002.2, D-AR6005, and D-AR6006, a la digital signature.
D-AR6007 The security framework must include Key Management, pertaining to Public Key Encryption (PKE) and Key Distribution Center (KDC).
D-AR6008 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.
D-AR6009 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
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.
D-AC0701. A new version of a standard will clearly describe its "backward compatibility" status with its earlier version in text.
D-AC0702. 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.
D-AC0703. 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
D-AC0704. The reference architecture must define a framework for growth of the architecture.
D-AC0705. The reference architecture should identify its axes for evolution. [e.g., independent specification of WS interaction with WS selection of WS measure WS]
D-AC0706. The standards should be mapped to these axes. [e.g., independent specification, - WSDL interaction - XMLP selection - ? measure - ?]
D-AC0707. Non-normative extension guidelines to be specified for each standard
D-AC0708. 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
is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.
D-AC8001 Simple visualization of architecture in the form of a two-dimensional diagram
D-AC8002 Architecture supports the concepts used in commonly accepted design patterns.
D-AC8003 Architectural components work together to form a logical whole.
D-AC8004 Architecture does not do the same or similar things in mutually incompatible ways; it is not self-contradictory.
D-AC8005 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
D-AR9001 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)
D-AR9002 All recommendations produced by the working group include a normative mapping between all XML technologies and RDF/XML.
D-AR9003 All conceptual elements should be addressable directly via a URI reference.
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.
D-AC0010,1 Each new architectural area is representable in a syntactic schema language like XML Schema.
is consistent with the existing web.
D-AG1101The Web Services reference architecture complies with the architectural principals and design goals of the existing web.
Derived sub-goals:
D-AC1101 universal identifiers
D-AC1102 simplicity
D-AC1103 opaqueness
D-AC1104 decentralization
D-AC1105 statelessness
D-AC1106 scalability of component interactions
D-AC1107 generality of interfaces
D-AC1108 immediate deployment of components
D-AC1109 intermediary components to reduce interaction latency
D-AC1110 enforces security
D-AC1112 encapsulate legacy systems
D-AC1113 caching semantics
D-AR0002 platform independence
D-AG1102 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:
D-AC1114 Use of a standard identifier technology (URI)
D-AC1115 Use of a standard transport technology (HTTP/S over TCP/UPD/IP)
D-AC1116 Use of a standard data encoding technology (XML)
In addition, the Working Group will also act to:
identify or create use cases that support/illustrate the requirements and web services architecture
D-AR1201 - terms must be well defined and used consistently
D-AR1202 - use cases organized around usage scenarios, usage scenarios should reflect common usage patterns for architecture
D-AR1203 - target audience for architectural deliverables must be defined
D-AR1204 - usage scenarios and use cases must be referencable via URI(reference)
D-AR1205 - architecture should support use casesat all levels of WS activity
D-AR1206 - usage scenarios and use cases shall be used as justification for recommending the formation of new WSA WGs
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
D-AR0013.1 Go through the W3C review process, and satisfy dependencies as listed in the charter.
D-AR0013.2 The documents produced are used as input to charter new Web Services Working Groups.
D-AR0013.3 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.
D-AC1501 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?
D-AC1502 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?
D-AC1503 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.
D-AC1504 Does the WSA demonstrate a reasonable number of re-use decisions rather than re-inventing?
D-AC1505 Is the architecture document regularly revised?
D-AC1506 Is the architecture document regularly referenced by other specifications, including but not limited to W3C specifications?
D-AC1507 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:
D-AR1601. Identify what constitutes interoperability
D-AR1601.1 in architectural realm.
D-AR1601.2 in technological realm.
D-AR1602. Identify existing
D-AR1602.1 architecture that supports interoperability
D-AR1602.2 technologies that support interoperability
D-AR1603. Identify gaps
D-AR1603.1 in architectural realm.
D-AR1603.2 in technological realm.
D-AR1604. Formation of WGs to address gaps
D-AR1604.1 in architectural realm.
D-AR1604.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
D-AR0017.1 The Web Services Architecture must support common business functions, to the extent that those funtions are defined in similar methodologies such as EDI.
D-AR0017.2 The Web Services Architecture must support reliable messaging and routing.
D-AR0017.3 The Web Services Architecture must support unique message IDs and message sequencing.
D-AR0017.4 The Web Services Architecture must support reliable 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.
D-AC1801. Develop a standard convention of measuring Web Services metrics so different service providers, implementors and consumers can reach service level agreements.
D-AC1801.1 The standard should include definitions of metrics such as Quality of Service, Reliability of Service and other metrics.
D-AC1801.2 The reference architecture should provide guidelines on measuring those metrics.
D-AC1801.3 Metrics can be independently verified.
D-AC1802. Define standard management instrumentations to Web Services.
D-AC1802.1 The standard should define but not limited to instrumentations such as starting, suspending, and retiring services.
D-AC1802.2 The instrumentations should confirm to other goals of this working group.
D-AC1802.3 The definition of management framework is out of scope. There are a number of such technologies available: www.dmtf.org.
D-AC1802.4 The instrumentations may be exposed as Web Services.
D-AC1803. Clearly define and publish reference architecture for implementors.
D-AC1803.1 Clearly define and publish reference Web Services management model.
D-AC1804 security policies, handling various QoS aspects, negotiation of service level agreements (SLAs) must be facilitated by technologies conforming to this architecture.
ensure reliable, stable, and predictably evolvable Web Services.
D-AC1901 Web Services created using WSA can be reliably discovered, accessed, and executed.
D-AC1902 Web Services created using WSA can be implemented such that they are stable with respect to their definitions.
D-AC1903 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.
D-AC2001 Is it possible for a service consumer to know the privacy policies of the service provider(s) that it is going to deal with? (eg. hooks for P3P)
D-AC2001 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.
D-AR2001 It must be possible to advertise privacy policies for Web Services
| Editorial note | |
| The Working Group intends to publish a separate glossary in a future document, using agreed-upon definitions for common terms throughout the W3C Web Services activity. | |
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.
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]
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
Thanks to Chris Ferris, Hugo Hass, Tom Carroll, and Len Greski for their help and feedback.
| Date | Editor | Description | |
|---|---|---|---|
| 20020418 | CBF | Relocated RFC2119 section. Incorporated abstract into introduction. Revised vision, fixed a few typos, assigned numbering scheme to CSFs and Requirements, updated D-AG0003 - D-AG0008. Releveled things a bit. Removed Usage Scenarios (now separate document). References tweaked. Incorporated Hugo's revised Status section. | |
| 20020422 | abbie | changed goal 11 and renumbered the sub gaols | |
| 20020422 | DBA | integrated many changes, modified document structure | |
| 20020423 | DBA | tried to clean up each goal, modified top-level goal text, general document repair, relettering, status section, publishing details. |