Movatterモバイル変換

1. Introduction

The use of Web services on the World Wide Web is expandingrapidly as the need for application-to-application communicationand interoperability grows. These services provide a standard meansof communication among different software applications involved inpresenting dynamic context-driven information to the user. In orderto promote interoperability and extensibility among theseapplications, as well as to allow them to be combined in order toperform more complex operations, a standard reference architectureis needed. The Web Services Architecture Working Group at W3C istasked with producing this reference architecture.

This document describes a set of requirements for a standardreference architecture for Web services developed by the WebServices Architecture Working Group. These requirements areintended to guide the development of the reference architecture andprovide a set of measurable constraints on Web servicesimplementations by which conformance can be determined.

1.1 What is a Web service?

The Working Group has jointly come to agreement on the followingworking definition excerpted from[WSGlossary]:

Web service

[Definition: A Webservice is a software system identified by a URI[RFC 2396], whose public interfaces and bindings aredefined and described using XML. Its definition can be discoveredby other software systems. These systems may then interact with theWeb service in a manner prescribed by its definition, using XMLbased messages conveyed by Internet protocols.]

1.2 Conventions Used in ThisDocument

The key words"must","must not","required","shall","shall not","should","should not","required","may", and"optional" in this document are to beinterpreted as described inRFC 2119.

Note:

A few words on the naming convention used here and throughoutthis document: all goals, critical success factors and requirementsare labeled according to the following convention:

[D-]A(G|F|R|UC)nnn.n.n

[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 SuccessFactor|Requirement|Use Case.

nnn.n.n indicates the sequence number of the item.

2. Requirements Analysis Method

Many methods of analyzing requirements for software systems areavailable. While each of them has strengths and weaknesses, the WebServices Architecture Working Group has decided to make use of twomethods concurrently, in the hope that together each of thesemethods will produce a well-defined set of requirements for WebServices Architecture. The two methods chosen are the CriticalSuccess Factor (CSF) Analysis method, which will be supplementedthrough the use of gathering Usage Scenarios. Both of these methodsare useful but represent different approaches to the problem ofgathering requirements.

The Working Groups intends to use these methods together and tocross-reference the results of each approach to ensure consistencyof the overall architectural direction. By ensuring that therequirements each serve to meet the goals of the Working Groupthrough the CSF analysis, and also ensuring that the architectureis consistent with the envisioned Usage Scenarios of the WorkingGroups in the Web Services activity, we can develop a set ofarchitectural requirements that will provide an architectural modelthat meets the needs of all of those involved.

Note that in the case of Usage Scenarios, the vast majority ofthese are taken from the work of other W3C Working Groups in theWeb Services Activity domain. Few individual Usage Scenarios willbe developed by the Web Services Architecture Working Groupdirectly, and those only in response to perceived gaps or omissionsin the work of other Working Groups. Usage scenarios will bepublished separately.

2.1 Understanding Critical SuccessFactors Analysis

The Critical Success Factors Analysis methodology fordetermining requirements is a top-down means of determiningrequirements based on the needs of the organization. For thisreason it is well-suited for requirements analysis for largesystems with many stakeholders and an audience with multiple andsometimes conflicting interests. The CSF analysis method beginswith a mission statement and then begins to divide the missionstatement into a set of very high-level goals. These high-levelgoals are then further divided into Critical Success Factors, whichthemselves are then further broken down into multiple levels of ahierarchy, becoming more concrete. At the lowest level, each CSFbecomes a requirement for the system; a single, well-defined taskthat must be accomplished in order to be successful. Along the way,problems to be solved and assumptions made are recorded.

Once the CSF hierarchy is established and a set of requirementshas been derived, these can then be arranged into a matrix forcomparison with the problems identified. In order to be consideredcomplete, each problem must be fully addressed by one or morerequirements.

By analyzing the steps necessary to achieve success, andcross-referencing them against problems to be solved, a completeset of requirements can be determined that can then be correlatedwith specific user scenarios. Each of the requirements should applyto at least one user scenario, and generally more than one.

This methodology allows requirements to be determined thatsatisfy the needs of the organization and those of the user. Sincearchitectural frameworks are built and maintained by organizations,this method allows us to create a well-defined and reasonablycomplete set of requirements.

3. The Analysis Hierarchy

3.1 Mission Statement

3.1.1 Mission

The mission of the Web Services Architecture Working Group is todevelop and maintain a standard reference architecture for Webservices.

3.1.2 Users of Web ServicesArchitecture

This document envisions three distinct groups of users of thestandard reference architecture for Web Services. The primaryaudience for whom the reference architecture is intended is the ITcommunity and developers who wish to deploy Web Services or todevelop software that enables the use of Web Services. Anotherintended group of users is that of other W3C Working Groups who aredeveloping the technologies identified for use within the referencearchitecture. The third intended audience is the Web ServicesArchitecture Working Group itself, in order to fully realize thepromise of Web Services.

3.2 Goals

3.2.1 Top-level Goals

The Working Group has determined that at the highest level, itsgoals can be divided into 7 categories. Each of these is associatedwith the CSFs and requirements listed insection 3.2.2 which further elaborate on each ofthe respective top-level goals. Of course, it is also important torecognize that an important motivation for the product of thisWorking Group is to support the needs of enterprises that use Webservices for the purpose of engaging in e-business.

Top-level Goals for the Web Services Architecture (WSA):

AG001 Interoperability
The WSAshould enable the development of interoperableWeb services across a wide array of environments.
Critical success factors and requirements for this goal:
- AC004 does not preclude any programmingmodel.
- AC023 is comprised of loosely-coupledcomponents and their interrelationships.
In addition, the Web Services Architecture Working Groupwill:
- AC016 examine architectural issues thatmight pose an impediment to interoperability of implementations,and between components of the architecture.
AG002 Reliability
The WSAmust be reliable and stable over time.
Critical success factors and requirements for this goal:
- AC019 enables conforming Web services to bereliable, stable, and evolvable over time.
AG003 Integration with the World Wide Web
The WSAmust be consistent with the current and futureevolution of the World Wide Web.
Critical success factors and requirements for this goal:
- AC009should avoid any unnecessarymisalignment with the Semantic Web.
- AC011 is consistent with the architecturalprinciples and design goals of the existing Web.
- AC021 ensures device independence of Webservices.
- AC022 conforms to the internationalizedcharacter model defined in "Character Model for the World Wide Web"Recommendation[CHARMOD]
AG004 Security
The WSAmust provide a secure environment for onlineprocesses.
Critical success factors and requirements for this goal:
- AC006 addresses the security of Webservices across distributed domains and platforms.
- AC020 enables privacy protection for theconsumer of a Web service across multiple domains and services.
AG005 Scalability and Extensibility
The WSAmust enable implementations that are scalableand extensible.
Critical success factors and requirements for this goal:
- AC002 provides for modular web servicesarchitecture components, with each at a level of granularityappropriate to meet the other goals.
- AC003 is sufficiently extensible to allowfor future evolution of technology and of business goals.
- AC005 applies the principle of simplicityand is defined such that it does not impose high barriers to entryfor its intended audience.
- AC017must satisfy therequirements of enterprises wishing to transition from traditionalEDI.
- AC024must enable peer to peerinteracting web services
AG006 Team Goals
The Web Services Architecture Working Group will work to ensurethat the Architecture will meet the needs of the usercommunity.
Critical success factors and requirements for this goal:
- AC007 is reliable, stable, and evolves overtime.
- AC008 is consistent and coherent. Thisapplies to both the reference architecture itself and the documentthat contains its definition.
In addition, the Web Services Architecture Working Groupwill:
- AC012 identify or create user scenarios anduse cases that support and illustrate the requirements and webservices architecture.
- AC013 co-ordinate with other W3C WorkingGroups, the Technical Architecture Groups and other groups doingWeb services related work in order to maintain a coherentarchitecture for Web services.
- AC015 organize its efforts in such a way asto address vital time-to-market issues for its products, includingiterating over successive refinements of the overall requirementsfor the standard reference architecture.
AG007 Management and Provisioning
The standard reference architecture for Web Servicesmust provide for a manageable, accountable environment forWeb Services operations.
Critical success factors and requirements for this goal:
- AC018must enable the managementand provisioning of Web Services

3.2.2 Critical Success Factors andRequirements

The Web Services Architecture Working Group has identified thefollowing CSFs and requirements for the WSA.

Each of the following CSFs is stated as a predicate to thefollowing statement except where noted.

To develop a standard reference architecture for Webservices that:

AC002

provides for modular web services architecture components, witheach at a level of granularity appropriate to meet the othergoals.

AC002.1 provides conceptual integrity, i.e. a unified themerather than a set of disjoint ideas, which generally characterizesdesigns that are easy to understand and implement.
- AC002.1.1 reduces complexity by decomposition of the component'sfunctionality and its position within the architecture
- AC002.1.2 eases development and maintenance of implementationsof the architecture by defining architectural components that arelogical, consistent, and thus easy to understand.

AC003

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

AR003.1 separates the transport of data or means ofaccess to Web services from the Web services themselves.
AR003.3 technologies following this architectureshould not impede the development of complex interactionscenarios
AR003.4 components of the architecture that areorthogonalmust be allowed to evolve independently of eachother and still work within the architecture
AR003.5 systemsmust not be precluded fromquoting, either unmodified or modified, messages within othermessages, to an arbitrary depth.

AC004

does not preclude any programming model.

AR004.2 is comprised of loosely-coupled componentsand their interrelationships.

AC005

applies the principle of simplicity and is defined such that itdoes not impose high barriers to entry for its intendedaudience

The reference architectureshould be easilyunderstandable by the target audience.

AC005.2 the WSA is stated in simple, declarativesentences
AC005.3 the WSA identifies and defines all of itscomponents precisely and unambiguously.
- AC005.3.1. there is a unique identificationscheme for identifying each component, and all components areidentified using this identification scheme.
- AC005.3.2 the terms and language used to describethe WSA and its components are unambiguously defined.
AC005.4 the WSA uses illustrations to visuallydescribe key components and relationships

The reference architecture defined by the WSAshould beas minimal as possible

AC005.5 the WSA will use the minimum number ofcomponents required for a coherent and complete description of theweb service architecture.
AC005.6 the WSA will avoid redundancies whendescribing relationships between components.

The WSAshould simplify the task of a programmerwriting interoperable implementations of specifications ofcomponents described by the architecture.

AC005.9 the role played by each component in theoverall architecture is clearly stated
AC005.10 the interdependencies among componentsare noted explicitly
AC005.11 existing specs that fulfill the role of agiven component are referenced

AC006

addresses the security of Web services across distributeddomains and platforms

AC006.1 the construction of a Web Services ThreatModel based on thorough analysis of existing and foreseeablethreats to Web service endpoints and their communication.
AC006.2 the establishment of a set of Web ServicesSecurity Policies to counter and mitigate the security hazardsidentified in the threat model.
AC006.3 the construction of a Web Services SecurityModel that captures the security policies.
AC006.4 the realization of the security model inthe form of a Web Services Security Framework that is an integralpart of the WSA.

Requirements:

AR006.1 the WGshould consider the threatof Accessibility attacks ([D]DOS, DNS spoofing, etc.) in thesecurity framework.
AR006.2.1 the WS security frameworkmustenable Authentication of the parties participating to anexchange.
AR006.2.2 the WS security frameworkmustenable persistent and transient authentication of authorship ofdata.
AR006.3 the WS security frameworkmustenable Authorization
AR006.4 the WS security frameworkmustenable Confidentiality.
AR006.5 the WS security frameworkmustenable (data) Integrity.
AR006.6 the WS security frameworkmustenable non-repudiation of origin and receipt between transactingparties
AR006.10.1 the WS security frameworkmust provide ameans of expressing security policy.
AR006.10.2 the WS security frameworkmust provide ameans to access a web service's security policy.
AR006.12 the WS security frameworkmust enableAuditing.
AR006.13 where a Web service provides security features in linewith AR006, itshould provide the ability to administerthat security.

AC007

The WSA is reliable, stable, and evolves over time.

AC007.1 the WSA is reliable.

AC007.1.1 the WSA is precisely defined withoutambiguity,
- AR007.1.1.1 using standard definition languageswhenever applicable and available,
- AR007.1.1.2 using standard terms, and clearlydefined new terms.

AC007.2 the WSA is stable and evolves overtime.

AR007.2.1 the WSA has stable conceptual models,definitions, assumptions, and scopes.
AR007.2.2 the WSA is governed by a well definedversioning policy.
AC007.2 .3 newer versions of WSAshouldbe compatible with older versions.
- AR007.2.3.1 when a component within the WebService Architecture changes, the change is precisely identified,and the changed WSA is reliable.
- AR007.2.3.2 the assumptions behind a change inthe component, and its scopemust be clearly stated.

AC008

is consistent and coherent. This applies to both the referencearchitecture itself and the document that contains itsdefinition.

AC008.1 the WSA provides simple visualization of architecture inthe form of a two-dimensional diagram
AC008.4 the WSA does not do the same or similar things inmutually incompatible ways; it is not self-contradictory.
AC008.6 the definition and use of the components isconsistent within the WSA and the architecture document itself.

AC009

should avoid any unnecessary misalignment with theSemantic Web

AR009.2 new Web services technologies, developed byW3C Web Services WGs,should be capable of being mapped toRDF/XML.
AR009.3 all conceptual elementsshould beaddressable directly via a URI.
AR009.4 the WSAmust not preclude thecharacterization of a Web Service that attempts to make itssemantics clear to an automatic system using technologies such asthose adopted as part of the Semantic Web.
AR009.5 Web service descriptionsshould becapable of referencing concepts identified by a URI in an ontology,such as W3C OWL[OWL].

AC011

is consistent with the architectural principles and design goalsof the Web. These principles and design goals are generallyoutlined in[WebArch],[AXIOMS],[WEBAT50K], and in[REST].

AC010 uses W3C XML technologies in the development ofthe Web services architecture to the extent that this is compatiblewith the overall goals listed here.
AC010.1 each new architectural area that has arepresentationshould be normatively defined using XMLSchema.
AC011.2 recommends the use of existing Web technologies thatadhere to the architectural and design principles of the Web andthat provide clear functional coverage of the responsibilities andconstraints for an identified architectural component.
AC011.3 recommends the design of new Web technologies thatadhere to the architectural and design principles of the Web toprovide functional coverage of the responsibilities and constraintsfor an identified architectural component.
Derived requirements:
AR011.1 the Web Services Architecture Working Groupmust closely monitor the deliverables of the TAG as theyfurther refine and or document the architecture and designprinciples of the Web

AC012

The Web Services Architecture Working Group will identify, orcreate, usage scenarios and use cases that support and illustratethe requirements and Web services architecture

AR012.1 - termsmust be well defined and usedconsistently
AR012.2 - use cases organized around usage scenarios, usagescenariosshould reflect common usage patterns forarchitecture
AR012.3 - target audience for architectural deliverablesmust be defined
AR012.5 - architectureshould support use cases for allaspects of Web services.
AC012.7 the WSAmust be validated againstWSA use cases.

AC013

The Web Services Architecture Working Group will co-ordinatewith other W3C Working Groups, the Technical Architecture Groupsand other groups doing Web services related work in order tomaintain a coherent architecture for Web services

AR013.2 the documents produced are used as input to charter newWeb services Working Groups.
AR013.3 the Working Group will maintain liaisons with relevantexternal groups, such as those listed in the charter and possiblyothers.

AC015

The Web Services Architecture Working Group will organize itsefforts in such a way as to address vital time-to-market issues forits products, including iterating over successive refinements ofthe overall requirements for the standard referencearchitecture.

AC016

The Web Services Architecture Working Group will examinearchitectural issues that might pose an impediment tointeroperability of implementations, and between components of thearchitecture.

The Web Services Architecture WGshould:

AR016.1 explore architectural relationships between componentsof the architecture.
AR016.2. identify architectural gaps or disconnects betweencomponents of the architecture.
AR016.3. recommend or solicit proposals for addressing anyidentified gaps and/or disconnects.
AR016.4 identify architectural principles and constraints thatenable interoperability of implementations, and between componentsof the architecture.

AC017

The WSAmust satisfy the requirements of enterpriseswishing to transition from traditional EDI.

AR017.2 the WSAmust support reliable messaging.
AR017.4 the WSAmust support long running, stateful andchoreographed interactions, both within and across trustboundaries.

AC018

The WSAmust enable the management and provisioning ofWeb Services

AC019

enables conforming Web services to be reliable, stable, andevolvable over time.

AR019.1 Web services conforming to WSA can bereliably discovered, accessed, and executed.
- AR019.1.2 WSA will enable the availabilityconstraints of a Web service to be known to its clients.
  Editorialnote
  there has been somediscussion as to whether consumers is the most appropriate termused in this context.
AR019.2 the WSAmust enable a conformingWeb service implementation to be stable with respect to itsdefinition.
- AR019.2.1 a Web service can be definedindependent of its implementation.
- AR019.2.2 the WSAmust enable a Webservice implementation to be stable based on serviceagreements.
AR019.3 the WSAmust enable a conformingWeb service definition to be evolvable by ensuring it is governedby a well defined versioning scheme for Web services that is madeavailable independent of the service.

AC020

enables privacy protection for the consumer of a Web serviceacross multiple domains and services.

AR020.1 the WSAmust enable privacy policy statementsto be expressed about Web services.
AR020.2 advertised Web service privacy policiesmust beexpressed in P3P[P3P].
AR020.3 the WSAmust enable a consumer to access a Webservice's advertised privacy policy statement.
AR020.5 the WSAmust enable delegation and propagationof privacy policy.
AR020.6: Web Servicesmust not be precluded fromsupporting interactions where one or more parties of theinteraction are anonymous.

AC021

ensures device independence of Web services.

AR021.1 assumes no specific device or level ofconnectivity for clients or servers so that wireless,intermittently connected, mobile and strongly connected devices aresupported.
AR021.2 makes no assumptions about the utility orvisibility of services based on user locality.
AR021.3 assumes a spectrum of device capabilities(from high end servers to handheld devices).

AC022

conforms to the internationalized character model defined in"Character Model for the World Wide Web" Recommendation[CHARMOD]

AC023

is comprised of loosely-coupled components and theirinterrelationships.

AR023.1 components are defined in terms ofunambiguous, well-defined interfaces.
AR023.2 components are described by theirfunctional roles and responsibilities.
AR023.3 component interfaces define their inputsand outputs and also the format and constraints on those inputs andoutputs.
AR023.4 component relationships are described interms of messages and message exchange patterns.
AR023.5 messages are transmitted and consumed bythe component interfaces that make up the architecture.
AR023.6 support XML based techniques for definingmessages/protocols for invoking web resources.
AR023.7 support both early and late client bindingto web services.
- AR023.7.1 defines or identifies a base interfacethat all Web services can implement, that permits communicationwithout prior knowledge of the service.

AC024

The WSAmust enable peer to peer interacting webservices

AR024.1 the WSAmust support atleast thefollowing peer to peer message exchange patterns:
- AR024.1.1 request-response
- AR024.1.2 publish-subscribe
- AR024.1.3 events and event notification
AR024.2 the WSAmust not precludepersistent identities for peers
AR024.3 the WSAmust not precludedetermining capabilities for peers
AR024.4 the WSAmust enable direct peer topeer interactions without the use of third party intermediaries
AR024.5 the WSAmust not preclude the useof third party intermediaries (e.g. forwarding)
AR024.6 itmust be possible for peers todiscover each other

4. Acknowledgments

The editors would like to thank the following Working Groupmembers for their contributions to this document: Mark Baker, DougBunting, Mike Champion, Roger Cutler, Suresh Damodaran, PaulDenning, Zulah Eckert, Chris Ferris, Hugo Haas, Hao He, DaveHollander, Joe Hui, Yin-Leng Husband, Mike Mahan, Francis McCabe,Nilo Mitra, Dave Orchard

This document is a product of theWeb Services Architecture WorkingGroup.

Members of the Working Group are (at the time of writing, and by alphabetical order): Geoff Arnold (Sun Microsystems, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Tom Carroll (W. W. Grainger, Inc.), Alex Cheng (Ipedo), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), James Davenport (MITRE Corporation), Paul Denning (MITRE Corporation), Gerald Edgar (The Boeing Company), Shishir Garg (France Telecom), Hugo Haas (W3C), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Mario Jeckle (DaimlerChrysler Research and Technology), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jeff Mischkinsky (Oracle Corporation), Eric Newcomer (IONA), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Bijan Parsia (MIND Lab), Adinarayana Sakala (IONA), Waqar Sadiq (EDS), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Bryan Thompson (Hicks & Associates, Inc.), Sinisa Zimek (SAP).

Previous members of the Working Group were: AssafArkin (Intalio, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.),Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), DiptoChakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alan Davies(SeeBeyond Technology Corporation), Glen Daniels (Macromedia), Ayse Dilber(AT&T), Zulah Eckert (Hewlett-Packard Company), Colleen Evans (Sonic Software), Chris Ferris (IBM), DanielaFlorescu (XQRL Inc.), Sharad Garg (Intel), Mark Hapner (Sun Microsystems,Inc.), Joseph Hui (Exodus/Digital Island), Michael Hui (Computer Associates),Nigel Hutchison (Software AG), Marcel Jemio (DISA), Mark Jones (AT&T),Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson(IBM), Steve Lind (AT&T), Mark Little (Arjuna), Bob Lojek (Intalio, Inc.), Anne Thomas Manes(Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft),Nilo Mitra (Ericsson), Don Mullen (TIBCO Softwar.e, Inc.), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel), Henrik Frystyk Nielsen (MicrosoftCorporation), Duane Nickull (XML Global Technologies), David Noor (Rogue WaveSoftware), Srinivas Pandrangi (Ipedo), Kevin Perkins (Compaq), Mark Potts (Talking Blocks, Inc), Fabio Riccardi (XQRL, Inc.), Don Robertson(Documentum), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar(Cisco Systems Inc), Jim Shur (Rogue Wave Software), Patrick Thompson (RogueWave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.),Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.) .

5. References

5.1 Normative References

[P3P]: The Platform for Privacy Preferences 1.0 (P3P1.0)Specification, L. Cranor, M. Langheinrich, M. Marchiori, M.Presler-Marshall, J. Reagle, W3C Recommendation 16 April 2002 (Seehttp://www.w3.org/TR/P3P/.)
[RFC 2396]: Uniform Resource Identifiers (URI): GenericSyntax, IETF RFC 2396, T. Berners-Lee, R. Fielding, L.Masinter, August 1998 (Seehttp://www.ietf.org/rfc/rfc2396.txt.)

5.2 Informative References

[WSARCH]: Web Services Architecture, W3C Working Group Note, D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D. Orchard, 11 February 2004 (See http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)
[WS Glossary]: Web Services Glossary, H. Haas, A. Brown, W3C Working Group Note, 11February 2004 (See http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.)
[CSF-Primer]: A Primer on Critical Success Factors, MIT Sloan School ofManagement Working Paper, Bullen, C. and J. Rockart, 1220-81
[WebArch]: Architecture of the World Wide Web, First Edition (Seehttp://www.w3.org/TR/2003/WD-webarch-20031209/.)
[AXIOMS]: Universal Resource Identifiers -- Axioms of Web Architecture,Berners-Lee, T. , 1996 (Seehttp://www.w3.org/DesignIssues/Axioms.html.)
[WEBAT50K]: Web Architecture at 50,000 Feet, Berners-Lee, T., 1998 (Seehttp://www.w3.org/DesignIssues/Architecture.html.)
[REST]: Architectural Styles and the Design of Network-based SoftwareArchitectures, Fielding, R., 2000 (Seehttp://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)
[CHARMOD]: Character Model for the World Wide Web 1.0, M. Dürst, F.Yergeau, R. Ishida, M. Wolf, T. Texin, W3C WorkingDraft 22 August 2003 (Seehttp://www.w3.org/TR/2003/WD-charmod-20030822/.)
[OWL]: OWL Web Ontology Language Reference, M. Dean, G. Schreiber,W3C Recommendation 10 February 2003 (Seehttp://www.w3.org/TR/2004/REC-owl-ref-20040210/.)