Briefing for the Solution Architects Working Group (SAWG)

1

Briefing for the Solution Architects Working Group (SAWG) of the Federal Enterprise Architecture Program Management Office

Brand NiemannChair, XML Web Services Working Group

Web Site: http://www.web-services.govGSA ListServ: CIOC-WEB-SERVICES

December 3, 2002

2

Outline

• 1. Working Group Meetings• 2. Related Activities:

– Web Services and More: Integrating Business Processes and Information Across Agencies, October 29th

– The Promise of XML Web Services in Government, October 29th – XML Web Services in Support of e-Gov and the EPA Geospatial

Blueprint, November 19th

– Request for OpenGIS Consortium Participation in the CIO Council’s XML Web Services Working Group, November 22nd

– SBA Business Compliance One-Stop Architecture Design Session and Proof of Concept, November 25th

• 3. White Paper for IAC and SAWG

3

1. Working Group Meetings

• November 12th:– In conjunction with Universal Access Collaboration

Expedition Workshop #19.– Business: Charter, Priorities, Initial Pilots, XML

Conference 2002 Exhibit, and Next Meetings.– Presentations: Education/Analysts-ZapThink,

Organizations-MITRE, Vendors-Zope, and Priorities/Pilots-XML Collaborator.

• December 10th:– In conjunction with XML Conference 2002,

“Registering the First Federal Web Service in the XML Collaborator, 1-2 p.m. Room 319, Baltimore Convention Center. Also joint Exhibit with the XML Working Group, December 10-12th.

4


• January 14th:– In conjunction with Universal Access Collaboration

Expedition Workshop #21.• Robert Haycock, Manager for the Office of Management and

Budget's Federal Enterprise Architecture Initiative, The Federal Enterprise Architecture (FEA) - An Overview of Vision and Progress

– Business: ListServ, Web Site, Collaboration Place, and Initial Pilots and Priorities.

– Presentations:• Education/Analysts-Giga Information Group• Organizations-W3C or Web Services-Interoperability• Vendors-OpenGIS Consortium• Priorities/Pilots-Navy Medicine On-line and XML

Collaborator.

5


• Looking for the following in "vendor“ presentations (really want multi-vendor pilots instead of single vendor products):– 1. Support for the Web Services Interoperability Initiative (see

usage scenarios and test tools available from their Web site) (e.g. demonstrate conformance to the Web Services Standards Stack).

– 2. Support for Universal Access and Interoperability in the e-gov Initiatives by showing chaining/linking of Web Services across multiple vendor platforms to accomplish an end-to-end e-Gov solution.

– 3. Support for the XML Collaboration and Registry Software Platform so your Web Service(s) can be registered as examples of "best practices“ and for reuse by others (the "publish, find, and bind" in the W3C Web Services Architecture).

6


• Coming Attractions:– Open Source for Federal and State eGovernment

Programs, Washington, DC, March 17 - 19, 2003:• XML and Web Services Track (3-6 one hour sessions)

– FedWeb Spring 03, GMU, Arlington, VA, May 5-7, 2003:

• Proposed Tutorial – Using the XML Collaborator to Help Federal, State, and Local Governments Architect and Build XML Web Services.

• Proposed Session – Architecting and Piloting the e-Gov Business Compliance One Stop with XML Web Services.

7

2. Related Activities

• 2.1 Web Services and More: Integrating Business Processes and Information Across Agencies, October 29th

• 2.2 The Promise of XML Web Services in Government, October 29th

• 2.3 XML Web Services in Support of e-Gov and the EPA Geospatial Blueprint, November 19th

• 2.4 Request for OpenGIS Consortium Participation in the CIO Council’s XML Web Services Working Group, November 22nd

• 2.5 SBA Business Compliance One-Stop Architecture Design Session and Proof of Concept, November 25th

8

2.1 Web Services and More: Integrating Business Processes and Information Across Agencies

• David Booth, Ph.D., W3C Fellow / Hewlett-Packard,[email protected],http://www.w3.org/2002/Talks/1029-fedweb-dbooth/

• Outline:– Objective:

• Integrate business processes across agencies• Re-use data more easily

– Web Services:• SOAP, WSDL, Semantics

– What fundamental problems will arise?• “Babelization”

– How can these problems be addressed?• Ontologies• URLs as Unambiguous Names• RDF

9

2.1 Web Services and More: Integrating Business Processes and Information Across Agencies

Representing Semantics

•Owners of Client and Service must agree on semantics•Can be verbal or written (preferably)•Can be human-oriented (e.g., English) or machine-processable (e.g., RDF)

•Ideally, Web Service Description should point to semantics•E.g. "targetNamespace" URL

My recommendation: Web Service Description should reference its semantics

10

2.2 The Promise of XML Web Services in Government

• Brand L. Niemann, Office of Environmental Information, U.S. Environmental Protection Agency, Jay Di Silvestri, Director of XML Services, Corel, and Ed Scrivani, Major Accounts Executive, NextPage

• Outline:– 1. Abstract– 2. What is XML?– 3. The Benefits of Structured Content– 4. Some Examples of XML’s Promise– 5. Some Demonstrations:

• 5.1 Federal CIO Council’s Digital Talking Book• 5.2 Corel-SoftQuad’s XMetal• 5.3 NextPage’s Triad (Contenta, NXT 3, and Solo)

– 6. Federal CIO Council’s XML Web Services Initiative– 7. Contact Information

11

2.2 The Promise of XML Web Services in Government

Corel XMetal XYEnterprise Contenta NextPage NXT 3 and Solo

Multiple vendors providing an end-to-end solution based on XML standards.

12

2.3 XML Web Services in Support of e-Gov and the EPA Geospatial Blueprint

• The incubator pilot projects demonstrated at the EPA GIS Day were:– (1) LandView 5 Web-connected DVD and CITRIX Web Server

and LandView 6 (OGC Conformant Web Client Application and Distributed GeoData Services).

– (2) Advanced Visualization Tools for EPA Spatial Databases (VisiMine and I-Miner).

– (3) Accuracy Assessment and Improvement of EPA Facility Registry Data and Emergency Notification and Data Collection with VoiceXML.

– (4) An Integrated Virtual Workplace for EPA and Its Partners.– (5) Spatially Enabling the EPA with the OGC XML Standards

and the OGC Spatial Web Registry Service (WRS).

13


• LandView 5 on CITRIX Web Server:– Citrix solutions for the virtual workplace:

• Secure, Internet-based access to Windows®, UNIX® and Java™-based applications from virtually any device, via any connection—all with unparalleled manageability and scale.

• Developing a version that will run on Microsoft’s upcoming .NET Enterprise Server to provide portal access to .NET-enabled applications, Java-based applications as well as Windows- and UNIX-based applications to create an integrated virtual workplace environment.

14


Pilot No. Purpose Database VoiceXML Query

1 (Fall 2001) EPA Emergency Response

FileMaker 5.5 (Apple Computer)

Tellme, Inc. ZIP Code (Area Code-to-ZIP Code Default)

2 (Spring 2002) Federal “Blue Pages” Directory

MS Access-NextPage

NXT 3

Tellme, Inc. Government Function

3 (Fall 2002) Public Directory Listings

Qsent Real Soft, Inc. Name, Address, Phone Number, Geography, etc.

4 (in process) Public & Government Directory Listings

Qsent & Agency XML Web Services

Real Soft, Inc. and Partners

Name, Address, Phone Number, Geography, etc.

5 (in process) EPA Facility Data Accuracy Improvement and Data Collection

Qsent & EPA Facility XML Web Services

RealSoft, Inc. and Partners

Name, Address, Phone Number, Geography, etc.

15


• USGS GEODE (Geo-Data Explorer):– Fully distributed data analysis and display model:

• Can link to any data server, world-wide. Can import and use their own data (http://pubs.usgs.gov/fs/fs132-01/).

– Currently over 6,000 data layers that can be retrieved, displayed and manipulated over the Internet without any special hardware, software, and training.

– Consist of six interoperable modules: Data format conversion, Spatial data engine, Web server, Image compression engine, Map server, and Relational database management system.

– Working with the OGIS specifications to become an OGIS compliant map server.

16


http://geode.usgs.gov/

17


Note: NXT 3 interface is like a Web Services Registry (UDDI, Geode, etc.)

18

2.4 Request for OpenGIS Consortium Participation in the CIO Council’s XML Web Services Working Group:

Background

• XML Web Services Working GroupNovember 12, 2002:– Slide 9 - Coordination with OGC’s Open Web Services 1.2 at

EPA GIS Day November 19th and again locally on November 22nd.

– Slide 17 - 2.3 Pilots: (4) Geospatial One Stop – partners: Open GIS Consortium, Ionic Enterprise, US EPA, Army Corps of Engineers, and Interagency LandView Team (OGC/OWS 1.2 and LandView 5 and 6).

• OGC Web Services 1.2 Demonstration, November 22, 2002:– Conversations with David Schell, President, and Jeff Harrison,

Director, Interoperability Program.– Participating in the Geospatial One-Stop Portal Team Meetings.

19

2.4 Request for OpenGIS Consortium Participation in the CIO Council’s XML Web Services Working Group:

Requests• Prepare a White Paper on OGC Web Services in the e-Gov

Initiatives:– More than just in the Geospatial One-Stop. Specifically, the Business

Compliance One Stop and possibly others.– Coordination between the OGC Web Services Registry and the XML

Web Services Working Group’s XML Collaborator.• Demonstration at CIO Council’s Exhibit at the XML 2002

Conference, December 10-12, Baltimore Convention Center (DVD and Internet).

• Presentation of White Paper and OGC Web Services 1.2 Demonstration DVD at the CIO Council’s Workshop #21 and XML Web Services Working Group Meeting on January 14, 2003, at the National Science Foundation, Ballston, VA.

• Presentation of the OGC White Paper and OGC Web Services 1.2 Demonstration to the Federal Enterprise Architecture Program Management Office’s Solution Architects Working Group (SAWG) (date to be determined).

20

2.5 SBA Business Compliance One-Stop Architecture Design Session and Proof of Concept

• Used in some of the White Papers at the IAC Enterprise Architecture Workshop, November 14th

– Suggest packaging to help BCOS and a cross - walk between the 5 models and their counterparts in XML Web Services Architecture, e.g. BRM maps to "community vocabulary", "work flow description", etc.

• Microsoft offered a no-cost Architecture Design Session/Proof of Concept at the November 25th Team Meeting for the early February 03 deadline.– Trucker One-Stop component with DOT and mid-west

states using .Net for both knowledge management and transactions.

21

2.5 SBA Business Compliance One-Stop Architecture Design Session and Proof of Concept

• Suggested Support Tasks:– A digital talking book.– VoiceXML for a subset of the digital talking

book content.– An Open Web Services mapping component

that is part of the Geospatial One Stop Portal.– Distributed content authoring, management

and dissemination.– Use of the XML Collaborator to design and

register the Web Services.

22

3. White Paper for IAC and SAWG

• 3.1 XML Conference 2002 Keynote• 3.2 Outline• 3.3 W3C Web Services Architecture Working

Draft, November 14, 2002• 3.4 Schedule:

– 3.4.1 Discussion Draft at January 14th Meeting.– 3.4.2 Presentation at February 5-6th MITRE XML/Web

Services Conference.– 3.4.3 Completed for February 11th Meeting.

23

3.1 XML Conference 2002 Keynote

• Robert Haycock, Manager for the Office of Management and Budget's Federal Enterprise Architecture Initiative, Tuesday, December 10 / 9.00am - 9.45am - The Federal Enterprise Architecture (FEA) - An Overview of Vision and Progress– http://www.xmlconference.org/xmlusa/2002/keynotes_haycock.asp

• Outline:– Introduction to E-Government– Overview of the Federal Enterprise Architecture (FEA)– XML and Web Services in the Federal Government– Questions

24

The FEA is being constructed through a collection of inter-related “reference models” designed to facilitate cross-agency collaboration, and horizontal / vertical information sharing

Business Reference Model (BRM)• Lines of Business• Agencies, Customers, Partners

Service Component Reference Model (SRM)• Service Layers, Service Types• Components, Access and Delivery Channels

Technical Reference Model (TRM)• Service Component Interfaces, Interoperability• Technologies, Recommendations

Data Reference Model (DRM)• Business-focused data standardization • Cross-Agency Information exchanges

Busin

ess-D

riven A

ppro

ach

Performance Reference Model (PRM)

• Government-wide Performance Measures & Outcomes• Line of Business-Specific Performance Measures & Outcomes

Federal Enterprise Architecture (FEA)

XM

L and W

eb S

erv

ices

25

3.1 XML Conference 2002 Keynote

• While several technologies can assist in this "game-changing" transformation, only a few can be considered as the enabling cornerstones. Extensible Markup Language (XML) and Web Services provide a foundation to assist in Horizontal and Vertical Information Sharing, while providing an underlying framework to support the delivery of services. XML provides the Federal Government with a standard and consistent means to classify/describe information that may be shared, exchanged, or delivered to stakeholder in, and across, the business value-chain. Web Services, in the broadest context, provide stakeholders with the ability to leverage existing (and proven) business services, data warehouses, knowledge repositories, and intellectual capital - independent of technology platform and geographical boundary. Both XML and Web Service create a foundation to support the horizontal and vertical integration of federal, state, local, and municipal government services. This level of interoperability, an integrated U.S. Government, will provide citizens with an avenue of approach, to engage the services of an integrated U.S. Government.

26

3.2 Outline

• 3.2.1 Title and Abstract (John Dodd)• 3.2.2 Introduction (John Dodd)• 3.2.3 The FEA and Options and Mapping to Web

Services (John Dodd and Bob Haycock)• 3.2.4 XML Web Services: The Standards (Brand

Niemann and Kevin Williams)• 3.2.5 Architecting XML Web Services for e-Gov: The

Basics and Some Examples (Brand Niemann)• 3.2.6 The XML Collaborator: Use in the e-Gov Initiatives

and Across Government Levels (Kevin Williams)

27

3.2 Outline

• 3.2.1 Title and Abstract– Web Services and XML Technologies Integrated with the Federal Enterprise

Architecture and G2G Access Channels by John C. Dodd- CSC, Bob Haycock- OMB- FEA-PMO, Brand Niemann-EPA, and Kevin Williams-BlueOxide

– The promise of Web Services and the underlying XML Technology can not mature without being linked and integrated with the greater whole which is the enterprise architecture and in particular the business architecture and process that delivers enterprise and in many cases extended enterprise value. Web Services offer great promise for improvement of government to government collaboration along a set of business lines. Over the last year a Federal Enterprise Architecture has been developed and is in early use. This paper describes the integration of the new emerging Web Services technologies into that Architecture framework and how it can be of special value in the definition and operations of government to government access channels between federal, state, and local organizations using and being ready to use standards and products. Described is a proactive technology integration planning and piloting approach that is backed by industrial partners represented by the Industry Advisory Council, the Federal CIO Council, NASCIO the state CIO’s, and the Office of Management and Budget- Federal Enterprise Architecture- Program Management Office. The paper describes a blueprint for Web Service deployment as part of the larger e-government transformation process. It points out what is ready now, what is being piloted, and the options and needs of the government sector for Web Services.

28

3.2 Outline

• 3.2.2 Introduction– Enterprise Architecture is becoming more business oriented but must

link Business needs to the Technology Readiness and become aligned.– Technology can be managed around the Enterprise Architecture

Blueprint both at the Department, Agency but most efficiently at the Federal Enterprise level.

– We can also leverage the “vast” number of technology pilot and study projects in the government to speed up the acceptance and reduce the “risk” in introducing a new technology.

– Web Services can be an enabling and transformational approach-if it can be linked and integrated with the Blueprint for Transformation that Enterprise Architecture efforts

– A government-industry team has developed the concepts in this paper and is using the ideas to managing the emerging Web Service pilots.

– We have also created a collaborative environment where learning and the knowledge and sharing and an extended government-industry Web Service “open-source” culture can be defined.

29

3.2 Outline

• 3.2.3 The FEA and Options and Mapping to Web Services– Technology Management an element of Enterprise Architecture: key

principles and practices to follow. – FEA and where XML Web Services fit into Business Lines, Access

Channels, etc. Security and Privacy elements. Information Sharing a key government skill.

– Crossing the Boundaries of government…link to NASCIO and other EA approaches.

– Service Oriented Architecture: Components Based Approach that can extended with Web Services

– Learning from Pilot Projects and taking a Strategic View of Emerging areas while keeping options open

– Role of SAWG and e-government projects– Industry involvement and participation. – Architects and Technologist working together to provide Business Value

and long lived-agile, adaptable, systems,….

30

3.2 Outline

• 3.2.4 XML Web Services: The Standards– Standards are judged by the process and organization that

created them.• Governments will always be the best place to establish a standard

that can be enforced by law, regulation, and established guidelines of conduct.

– The World Wide Web Consortium (W3C):• Preeminent standards-setting body in the XML world - to say its

word is the gold currency of the industry is an understatement.• “Recommendation” is the W3C non-politically charged word for

standard.• Three central principles: interoperability, evolution, and

decentralization.– Key XML Specifications and Standards (ZapThink 2002) - Over

450 standards in existence with 135 key specifications categorized by Core XML, Document-oriented, Message-Oriented, and Community Vocabularies representing eight standards organizations. See http://www.zapthink.com/reports/poster.html

31

ZapThink XML Standards Poster!Over 135 XML and Web Services Standards At-a-Glance

32

3.2 Outline

• 3.2.5 Architecting XML Web Services for e-Gov: The Basics and Some Examples– Architectural Principles of the World Wide Web, W3C

Working Draft 30 August 2002• http://www.w3.org/TR/2002/WD-webarch-20020830/

– Attended W3C’s Web Services Architecture (WSA) and Description (WSD) Working Groups (September 9-13, 2002).

• http://www.w3.org/TR/2002/WD-ws-arch-20021114/

– Examples in process: BCOS, GSOS, GSA(DHS), etc.

33

3.2 Outline

• 3.2.5 Architecting XML Web Services for e-Gov: The Basics– Textbook Stuff:

• Chapter 14: Architecting Web Services, in XML and Web Services Unleashed, 2002, Sams, Ron Schmelzer, et. al., pp. 592-628.

– Business modelers seek to represent business concepts with business components to limit complexity and costs, to support reuse of business components, speed up the development cycle, etc.

– The Web Services model can be thought of as the next step in the evolution of business components – whereas business components are large, recursively defined collections of objects, Web Services should be relatively small, self-organizing components with well-defined, dynamic interfaces.

• Chapter 8: Implementing Web Services, in Understanding Web Services, 2002, Eric Newcomer, Addison-Wesley, pp. 255-308.

– Vendor Views on Adoption of Web Services Technologies.

34

3.2 Outline

• 3.2.5 Architecting XML Web Services for e-Gov: The Basics– Software architects need to understand the paradigm

shift of Web Services and communicate it to their teams as well as their management.

– The 4+1 View Model of Software Architecture popularized by Philippe Kruchten of Rational Software:

• The architect has clear vision seeing the elephant from all four views, not the four separate views of the four blind men. The architect has a comprehensive picture of the elephant.

• Each of the four main views takes the perspective of key stakeholders in the development process. The fifth view overlaps the other views and plays a special role.

35

3.2 Outline

• 3.2.5 Architecting XML Web Services for e-Gov: The Basics– The 4+1 View Model of Software Architecture:

• The Implementation Architectural View – The Web Services Technology Stack.

• The Logical Architectural View – Composition of Web Services.

• The Deployment Architectural View – From Application Servers to Peer-to-Peer.

• The Process Architectural View – Life in the Runtime.• Use-Case View – Users That Know What They Want a Web

Services Architecture to Do (not the case at this time).

36

3.2 Outline 3.2.5 Architecting XML Web Services for e-Gov: The Basics

Use-Case View

Logical (design) View

ProcessView

Implementation(Development orComponent) View

Deployment(Physical) View

End UserFunctional Requirements

SOA ArchitectsJIT Integration of Web Services

ProgrammersSoftware Management

System EngineeringPlatforms

The 4+1 View Model of Software Architecture Applied to Web Services

37

3.2 Outline

• 3.2.6 The XML Collaborator: Use in the e-Gov Initiatives and Across Government Levels– XML Working Group’s Registry/Repository Team

Meeting, September 18th

• Collaboration and Registration: XML Collaborator-Presentation and White Paper.

– http://www.blueoxide.com/Pages/products.html

– XML Web Services Working Group Meeting #1, November 12th

• Component-based XML and XML Web Service Design with XML Collaborator.

– XML Web Services Working Group Meeting #2, December 10th

• Registration of the First Federal Web Service (Navy Medicine on-line) in the XML Collaborator.

38

3.2 Outline

• 3.2.6 The XML Collaborator: Use in the e-Gov Initiatives and Across Government Levels– The XML Collaborator approach:

• XML document structures (DTDs and XML Schemas) and XML Web services (WSDL) are built up from components.

• Components are individually tracked and versioned.• Single repository allows simple repurposing of structures

(e.g. automatically-generated documentation or parser code).

• As standards change and evolve, the platform-agnostic nature of the repository allows components to be repurposed to the new standards (e.g., RDF/Topic Maps).

39

3.2 Outline 3.2.6 The XML Collaborator: Use in the e-Gov Initiatives

and Across Government Levels

XML Collaborator: XML Design Collaboration and Registry Software

40

3.3 W3C Web Services Architecture Working Draft, November 14, 2002

http://www.w3.org/TR/2002/WD-ws-arch-20021114/• 0. Abstract• 1. Introduction• 2. What is a Web Service?• 3. Basic and Extended Architecture

– 3.1 Basic Architecture– 3.2 Extended Web Services Architecture– 3.3 Web Services Stacks

• 4. Web Service Architecture– 4.1 Identifiers– 4.2 Formats– 4.3 Protocols

• 5. Processing Model• 6. Appendices

41


http://www.w3.org/TR/2002/WD-ws-arch-20021114/

• 0. Abstract– Identifies the functional components, defines

relationships among the components, and establishes a set of constraints upon each.

– First Public Working Draft – a work in progress, still incomplete in many respects, and does not represent a consensus of the W3C Web Services Architecture WG, which is part of the W3C Web Services Activity.

– There is a list of open issues associated with the document.

42


http://www.w3.org/TR/2002/WD-ws-arch-20021114/• 1. Introduction

– Web Services on the World Wide Web is to meet the growing need for application-to-application communication and interoperability among different software applications, running on a variety of platforms and/or frameworks.

– This documents identifies candidate technologies that have been determined to meet the functionality requirements.

– “Web services” includes:• “Distributed Objects” or “Application Integration”• EDI /B2B• The World Wide Web itself

– The popular Web services technologies SOAP 1.1 and WSDL 1.1, originally developed outside the W3C, have successors that are now being developed with the W3C Web Services Activity.

• Extensible messaging framework (SOAP 1.2) and interface definition language (WSDL 1.2).

43



• 2. What is a Web service?– A Web service is a software system identified by a

URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner described by its definition, using XML based messages conveyed by Internet protocols.

• Note: This definition does not presuppose the use of SOAP and WSDL, but the architecture does assume that higher levels of the Web services protocol stack are built on the foundation of SOAP and WSDL.

44


http://www.w3.org/TR/2002/WD-ws-arch-20021114/• 3. Basic and Extended Architecture

– 3.1 Basic Architecture• Includes technologies capable of:

– Exchanging messages.– Describing Web services.– Publishing and discovering Web services descriptions.

• Models the interactions between three roles:– The service provider (publish).– Service discovery agency (find).– Service requestor (bind).

• Typical scenario:– A service provider hosts a network accessible software module (an

implementation of a Web service).– The service provider defines a service description for the web service

and publishes it to a requestor or service discovery agency.– The service requestor uses a find operation to retrieve the service

description locally or from the discovery agency (i.e. a registry or repository) and uses the service description to bind to the service provider and invoke or interact with the web service implementation.

45


http://www.w3.org/TR/2002/WD-ws-arch-20021114/3. Basic and Extended Architecture3.1 Basic Architecture

46



• 3. Basic and Extended Architecture– 3.1 Basic Architecture:

• The components are The Service and The Service Description (see 3.1.1). The nodes of the triangle represent roles (see 3.1.2) and the edges represent operations (see 3.1.3).

• Requestors and providers interact using one or more message exchange patterns (MEPs) that define the sequence of one or more messages exchanged between them.

• A software agent can act in one or more multiple roles acting as requestor or provider only, both requestor and provider, or as requestor, provider, and discovery agency.

• One or more intermediaries may exist in a message path between requestor and provider, but cannot interfere with the MEP.

• Web services can be used alone or in conjunction with other web services to carry out a complex aggregation or a business transaction.

47



• 3. Basic and Extended Architecture– 3.2 Extended Web Services Architecture

• Provides additional features and functionality by extending the technologies and components defined within the basic Web services architecture.

• Describes Web services support for MEPs that group basic messages into higher-level interactions, details support for such features as security, transactions, orchestration, privacy and others may be represented in messages (SOAP modules), and describes how additional features can be added to support business level interactions.

48



3.2 Extended Web Services Architecture3.2.2 Diagrammatic representation of features – three stacks

49



3.2 Extended Web Services Architecture3.2.4 Flows – serve multiple roles simultaneously

Each peer Web serviceInstance serves in boththe Service Requestorand Service Provider roles.

50


http://www.w3.org/TR/2002/WD-ws-arch-20021114/3.2 Extended Web Services Architecture3.2.4 Flows – serve multiple roles simultaneously

The Service Requestorand Discovery Agencyrole are fulfilled by theclient.

51



52



53



• 3. Basic and Extended Architecture– 3.3 Web Services Stacks:

• Towards the bottom layers of the stack, the technologies and concepts are relatively more mature and achieve a higher level of standardization than many of the upper layers.

• At the end of this section the independent stacks are assembled into a single stack where each additional layer builds upon the capabilities provided by those below it.

• The vertical towers represent the variety of over arching concerns that must be addressed at every level of each of the stacks.

54



• 3. Basic and Extended Architecture– 3.3 Web Services Stacks

• 3.3.1 Wire “Stack”• 3.3.2 XML Messaging with SOAP• 3.3.3 Description “Stack”• 3.3.4 Discovery Agencies “Stack”• 3.3.5 Overarching Concerns• 3.3.6 The Complete Web Services “Stack”

55



3.3 Web Services Stacks3.3.1 Wire “Stack”

56



3.3 Web Services Stacks3.3.2 XML Messaging with SOAP

57



3.3 Web Services Stacks3.3.3 Description “Stack”

58



3.3 Web Services Stacks3.3.3 Description “Stack” – applying to a particular Web Service

59



3.3 Web Services Stacks3.3.4 Discovery Agencies “Stack”

60



3.3 Web Services Stacks3.3.5 Overarching Concerns

61



3.3 Web Services Stacks3.3.6 The Complete Web Services “Stack”

62



• 4. Web Service Architecture– A single specification of the way in which artifacts of

the system are identified: URIs (see 4.1 Identifiers).– A non-exclusive set of data formats designed for

interchange between agents in the system: XML Infoset, XML Schema, SOAP, and WSDL (see 4.2 Formats).

– A small and non-exclusive set of protocols for interchanging information between agents: HTTP and others (see 4.3 Protocols).

– A small and non-exclusive set of … (see 5 Processing Model).

63



• 6. Appendices:– A. Acknowledgments – about 70 members– B. References – Web Services Glossary Working

Draft http://www.w3.org/TR/ws-gloss– C. The Bottom Up View of the Architecture – used in

section 3, remains to be harvested. See 8 (really 7) figures. May only need Figure 8.

– D. Architectural Use of Technologies – same purpose as C.

– E. Other Harvested Material – ebXML interesting.– F. Web Services Architecture Change Log

64


http://www.w3.org/TR/2002/WD-ws-arch-20021114/6. AppendicesC. The Bottom Up View of the Architecture

65



66



67



68



69



70



Documents

Briefing for the Solution Architects Working Group (SAWG)