Web Services Architecture Requirements

2.2.1 Mission, Vision, and Values

2.2.2 Goals

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:

D-AG0001

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.

D-AG0002

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

D-AG0003

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

D-AG0004

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

D-AG0005

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?

D-AG0006

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).

Requirements

General

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.

Security

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.

D-AG0007

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

D-AG0008

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.

D-AG0009

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)

D-AG0010

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.

D-AG0011

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:

D-AG0012

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.

D-AG0013

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.

D-AG0014

Closed because it was merged with D-AG0013

D-AG0015

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.

D-AG0016

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.

D-AG0017

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

Measurements:

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?

D-AG0018

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.

D-AG0019

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.

D-AG0020

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