Essential Digital Tools for Farm and Food Ventures - 25th Annual Southern SAWG Conference
Briefing for the Solution Architects Working Group (SAWG)
description
Transcript of 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
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 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
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 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
2.3 XML Web Services in Support of e-Gov and the EPA Geospatial Blueprint
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
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.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
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 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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://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, 2002
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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://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, 2002
http://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, 2002
http://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, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.2 Extended Web Services Architecture3.2.2 Diagrammatic representation of features – three stacks
49
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
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
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/3.2 Extended Web Services Architecture3.2.4 Flows – serve multiple roles simultaneously
52
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/3.2 Extended Web Services Architecture3.2.4 Flows – serve multiple roles simultaneously
53
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://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, 2002
http://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, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.1 Wire “Stack”
56
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.2 XML Messaging with SOAP
57
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.3 Description “Stack”
58
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.3 Description “Stack” – applying to a particular Web Service
59
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.4 Discovery Agencies “Stack”
60
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.5 Overarching Concerns
61
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3.3 Web Services Stacks3.3.6 The Complete Web Services “Stack”
62
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://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, 2002
http://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, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/6. AppendicesC. The Bottom Up View of the Architecture
65
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/6. AppendicesC. The Bottom Up View of the Architecture
66
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/6. AppendicesC. The Bottom Up View of the Architecture
67
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/6. AppendicesC. The Bottom Up View of the Architecture
68
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
69
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
70
3.3 W3C Web Services Architecture Working Draft, November 14, 2002
http://www.w3.org/TR/2002/WD-ws-arch-20021114/