Briefing for the Solution Architects Working Group SAWG of the Federal Enterprise Architecture Progr

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

• Brand Niemann
• Chair, XML Web Services Working Group
• Web Site http//www.web-services.gov
• GSA 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 Councils 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
1. Working Group Meetings

• 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
1. Working Group Meetings

• 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
1. Working Group Meetings

• 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 Councils 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,dbooth_at_w3.org,http//www.w3.org/20
  02/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 XMLs Promise
• 5. Some Demonstrations
• 5.1 Federal CIO Councils Digital Talking Book
• 5.2 Corel-SoftQuads XMetal
• 5.3 NextPages Triad (Contenta, NXT 3, and Solo)
• 6. Federal CIO Councils 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
2.3 XML Web Services in Support of e-Gov and the
EPA Geospatial Blueprint

• 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 connectionall with unparalleled
  manageability and scale.
• Developing a version that will run on Microsofts
  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
2.3 XML Web Services in Support of e-Gov and the
EPA Geospatial Blueprint
15
2.3 XML Web Services in Support of e-Gov and the
EPA Geospatial Blueprint

• 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.go
  v/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
2.3 XML Web Services in Support of e-Gov and the
EPA Geospatial Blueprint
http//geode.usgs.gov/
17
2.3 XML Web Services in Support of e-Gov and the
EPA Geospatial Blueprint
Note NXT 3 interface is like a Web Services
Registry (UDDI, Geode, etc.)
18
2.4 Request for OpenGIS Consortium Participation
in the CIO Councils XML Web Services Working
GroupBackground

• XML Web Services Working GroupNovember 12, 2002
• Slide 9 - Coordination with OGCs 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 Councils XML Web Services Working
GroupRequests

• 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 Groups
  XML Collaborator.
• Demonstration at CIO Councils 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 Councils
  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
  Offices 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
Federal Enterprise Architecture (FEA)
Performance Reference Model (PRM)

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

Business Reference Model (BRM)

• Lines of Business
• Agencies, Customers, Partners

Business-Driven Approach
XML and Web Services
Service Component Reference Model (SRM)

• Service Layers, Service Types
• Components, Access and Delivery Channels

Data Reference Model (DRM)

• Business-focused data standardization
• Cross-Agency Information exchanges

Technical Reference Model (TRM)

• Service Component Interfaces, Interoperability
• Technologies, Recommendations

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 CIOs, 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 governmentlink 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.c
  om/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 W3Cs 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 41 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 41 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
The 41 View Model of Software Architecture
Applied to Web Services
Programmers Software Management
End User Functional Requirements
Implementation (Development or Component) View
Logical (design) View
Use-Case View
Process View
Deployment (Physical) View
System Engineering Platforms
SOA Architects JIT Integration of Web Services
37
3.2 Outline

• 3.2.6 The XML Collaborator Use in the e-Gov
  Initiatives and Across Government Levels
• XML Working Groups 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, 2002http//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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3. Basic and Extended Architecture3.1 Basic
Architecture
46
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.2 Extended Web Services Architecture 3.2.2
Diagrammatic representation of features three
stacks
49
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.2 Extended Web Services Architecture 3.2.4
Flows serve multiple roles simultaneously
Each peer Web service Instance serves in both the
Service Requestor and Service Provider roles.
50
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.2 Extended Web Services Architecture 3.2.4
Flows serve multiple roles simultaneously
The Service Requestor and Discovery Agency role
are fulfilled by the client.
51
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.2 Extended Web Services Architecture 3.2.4
Flows serve multiple roles simultaneously
52
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.2 Extended Web Services Architecture 3.2.4
Flows serve multiple roles simultaneously
53
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.1 Wire Stack
56
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.2 XML Messaging with
SOAP
57
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.3 Description Stack
58
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.3 Description Stack
applying to a particular Web Service
59
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.4 Discovery Agencies
Stack
60
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.5 Overarching Concerns
61
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
3.3 Web Services Stacks 3.3.6 The Complete Web
Services Stack
62
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/

• 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
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
6. Appendices C. The Bottom Up View of the
Architecture
65
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
6. Appendices C. The Bottom Up View of the
Architecture
66
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
6. Appendices C. The Bottom Up View of the
Architecture
67
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
6. Appendices C. The Bottom Up View of the
Architecture
68
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
69
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/
70
3.3 W3C Web Services Architecture Working Draft,
November 14, 2002http//www.w3.org/TR/2002/WD-ws-
arch-20021114/