Pilot to Assess Readiness of XML Web Services for EGov Initiatives

1
Pilot to Assess Readiness of XML Web Services for
E-Gov Initiatives

• Brand Niemann
• Chair, Web Services Work Group
• http//web-services.gov
• Truman Room, White House Conference Center
• June 2, 2003 (minor edits on June 21st)

2
Announcement

• Members of the SAWG (Federal), the AIC and its
  Subcommittees, and E-Gov Program Managers are
  invited to an all-day workshop on June 2nd to
  assess the readiness of XML Web Services for
  E-Gov Initiatives. The workshop will be held from
  830 a.m. - 430 p.m. in the Truman Room of the
  White House Conference Center. Eleven vendors
  have committed to pilot an E-Gov Initiative with
  XML Web Services and participate in the workshop.
  The completed templates (posted at
  http//web-services.gov) will be made available a
  week before this workshop for review and
  experimenting with the pilots on the Web. RSVP is
  required to Brand Niemann because space is
  limited (bniemann_at_cox.net).

3
Clarification

• No vendor is in any special category for this
  June 2nd or the June 26th events and we are not
  doing this pilot for just one E-Gov Initiative
  (e.g. E-Grants). All the E-Gov Program Managers,
  etc. have been invited and will receive the
  assessment of readiness.
• One "vendor" that is presenting their template
  today, actually the Open GIS Consortium, is
  however, in an advanced state of readiness having
  just completed the Geospatial One-Stop Portal
  that uses XML Web Services for geospatial data
  for that E-Gov Initiative.

4
Logistics

• Restrooms
• Mens on this floor Womens on 2nd floor.
• Refreshments (a.m. and p.m.) and Lunch
• Need volunteer(s) to collect orders and money and
  contact Wall Street Delli.
• Meeting notes
• Rick Rogers, E-Forms for E-Gov Pilot team
  Leader.
• Presentations (20 minutes strictly enforced)
• Test laptop connection to projector or load files
  on PC.
• Distribute handouts beforehand.
• Focus on the template and allow time for Q A.
• Questions and Answers
• Now about logistics.
• Specific to each vendor (in morning) and general
  (in afternoon).

5
Overview

• 830 - 9 a.m. Welcome, Introductions, and
  Background.
• 9 a.m. - 12 noon Individual vendor presentations
  using the template.
• Break from about 10-1015 a.m.
• 12 noon - 130 p.m. Lunch on your own.
• 130 - 300 p.m. General questions and
  discussions with all the vendors.
• 300 - 330 p.m. Break.
• 330- 430 p.m. Discussion of "the SAWG
  assessment for readiness" by Federal attendees
  only. Vendors will be excused.

6
Background

• 1. Introduction to Web Services(7-30)
• 2. Architecture Infrastructure Committee(31)
• 3. AIC Components Subcommittee(32-33)
• 4. Emerging Components Conference Series(34-37)
• 5. XML Web Services Working Group(38-44)
• 6. Component Registry and Repository Template for
  XML Web Services Pilot Projects(45-46)
• 7. Solution Architects Working Group
  (SAWG)(47-49)
• 8. Appendix(52-60)

7
1. Introduction to Web Services

• Microsoft coined the term Web services in June
  2000, when the company introduced Web services as
  a key component of its .Net initiative, a broad
  new vision for embracing the Internet in the
  development, engineering and use of software.
• As others began to investigate Web services, it
  became clear that the technology could
  revolutionize (be the next stage in) distributed
  computing.
• Now nearly every major vendor is marketing Web
  services tools and applications and Web services
  are radically changing IT architectures and
  partner relationships.

8
1. Introduction to Web Services

• Web services encompass a set of related standards
  that can enable any two computers to communicate
  and exchange data via a network, such as the
  Internet.
• The primary standard used in Web services is the
  Extensible Markup Language (XML) developed by the
  World Wide Web Consortium (W3C).
• Developers use XML tags to describe individual
  pieces of data, forming XML documents, which are
  text-based and can be processed on any platform.

9
1. Introduction to Web Services

• XMLs portability and its rapid adoption
  throughout the industry made it the obvious
  choice for enabling cross-platform data
  communication in Web services.
• XML provides the foundation for many core Web
  services standards (SOAP, WSDL, and UDDI) and
  vocabularies (XML-based markup for a specific
  industry or purpose).
• Almost every type of business can benefit fro Web
  services such as expediting software development,
  integrating applications and databases, and
  automating transactions with suppliers, partners,
  and clients.

10
1. Introduction to Web Services

• SOAP (Simple Object Access Protocol) is an XML
  vocabulary that enables programs on separate
  computers to interact across a network.
• WSDL (Web Services Description Language) is
  another XML vocabulary that allows developers to
  describe Web services and their capabilities in a
  standardized format.
• UDDI (Universal Description, Discovery and
  Integration) is a framework that defines
  XML-based registries in which businesses can
  publish information about themselves and the
  services they offer.

11
1. Introduction to Web Services

• Structured Programming to Object Technology
• In the 1960s, many large software-development
  projects encountered severe difficulties and
  people began to realize that it was a far more
  complex activity than they had imagined.
• This lead to structured programming a
  disciplined approach to creating programs that
  are clear, demonstrably correct, and easy to
  modify, in the 1970s.
• However. It was not until object-oriented
  programming became widely used in the 1980s and
  1990s that the software-development process
  improved dramatically.

12
1. Introduction to Web Services

• Object technology is a packaging scheme that
  enables programmers to create meaningful software
  units
• Almost any noun can be reasonably represented as
  a software object (date, paycheck, invoice,
  audio, video, files, etc.).
• Object have properties (e.g. color) and perform
  actions (e.g. drawing).
• Groups of related objects are classes.
• A class is to an object as a blueprint is to a
  house.

13
1. Introduction to Web Services

• One of the key problems with procedural
  programming (e.g. Fortran, Pascal, Basic, and C)
  is that the software units created do not mirror
  real-world entities effectively and therefore are
  not particularly reusable.
• By contrast, object-oriented programming (C,
  Java, C, and Visual Basic .Net) allows for code
  to be organized and encapsulated by classes,
  which facilitates the reuse of software
  components.
• Developers can group classes into class
  libraries, then make the libraries available to
  developers working on other projects.
• Web services take advantage of object-oriented
  programming by enabling developers to build
  applications from existing software components in
  a modular approach.
• This is about transforming a network (e.g. the
  Internet) into an enormous library of
  programmatic components available to developers
  to produce significant productivity gains.

14
1. Introduction to Web Services

• When developers create substantial applications,
  often it is more efficient, or even necessary,
  for different task to be performed on different
  computers, called N-tier applications
• A three-tier application might have a user
  interface on one computer, business-logic
  processing on a second and a database on a third
  all interacting as the application runs.
• For distributed applications to function
  correctly, application components (e.g.
  programming objects) executing on different
  computers throughout a network must be able to
  communicate.

15
1. Introduction to Web Services

• Unfortunately, interoperability (the ability to
  communicate and share data with software from
  different vendors and platforms) is limited among
  conventional proprietary technologies (e.g.
  CORBA, DCOM. RMI, DSOM).
• Web services improve distributed computing
  interoperability by using open (non-proprietary)
  standards that can enable (theoretically) any two
  software components to communicate and are easier
  to debug because they are text-based, rather than
  binary , communication protocols.

16
1. Introduction to Web Services

• Web services provide capabilities similar to
  those of EDI (Electronic Data Interchange), but
  are simpler and less expensive to implement.
• Web services are more conducive to implementing
  loosely coupled systems (e.g. systems in which
  developers can alter a programming component
  without modifying other components to reflect the
  original change).
• Web services can be configured to work with EDI
  systems, allowing organizations to use the two
  technologies together or to phase out EDI while
  adopting Web services.

17
1. Introduction to Web Services

• Web services advantages
• Use open, text-based standards, which enable
  components written in different languages and for
  different platforms to communicate.
• Promote a modular approach to programming, so
  multiple organizations can communicate with the
  same Web service.
• Comparatively easy and inexpensive to implement,
  because they employ an existing infrastructure
  and because most applications can be repackaged
  as Web services.
• Significantly reduce the costs of enterprise
  application (EAI) integration and B2B
  communications.
• Implemented incrementally, rather than all at
  once which lessens the cost and reduces the
  organizational disruption from an abrupt switch
  in technologies.
• The Web Services Interoperability Organization
  (WS-I) consisting of over 100 vendors promotes
  interoperability.

18
1. Introduction to Web Services

• Web services challenges
• The standards that drive Web services are still
  in draft form (always will be in refinement).
• Some vendors want to retain their intellectual
  property rights to certain Web services
  standards.
• Web services need standard security procedures (a
  common problem to all of distributed computing).
• The leading registry, based on the UDDI
  specification, has some key limitations, and
  alternative discovery methods are provided by
  ebXML and WS-Inspection.
• Web services need Quality of Service (QoS)
  support from Web Services Registries, Brokerages,
  and Network Providers.

19
1. Introduction to Web Services

• Web services
• Software programs that use XML to exchange
  information with other software via common
  Internet protocols
• Scalable (e.g. multiplying two numbers together
  to an entire customer-relationship management
  system)
• Programmable (encapsulates a task)
• Based on XML (open, text-based standard)
• Self-describing (metadata for access and use)
• Discoverable (search and locate in registries)

20
1. Introduction to Web Services

• Web services
• An additional Web tool better than screen
  scraping.
• Processing HTML pages with applications designed
  to locate certain data or patterns of content.
• The new distributed computing environment.
• A standard method for enabling communication
  between applications middle tiers over a
  network.
• Different application can use the same data.
• A much higher level of data integration both
  within and between businesses, helping companies
  improve relationships with partners and
  customers.
• The next business model of the Internet.
• Could vastly improve collaborative software
  development and deployment as an Internet-based
  service.
• Solves many problems inherent in the previous
  distributed-computing technologies.

21
1. Introduction to Web Services

• 1. Client queries registry to locate service.
• 2. Registry refers client to WSDL document.
• 3. Client accesses WSDL document.
• 4. WSDL provides data to interact with Web
  service.
• 5. Client sends SOAP-message request.
• 6. Web service returns SOAP-message response.

WSDL Document
UDDI Registry
2
3
1
4
5
Client
Web Service
6
22
1. Introduction to Web Services

• IBM has created a model to depict Web services
  interactions which is referred to as a
  service-oriented architecture comprising
  relationships among three entities
• A Web service provider
• A Web service requestor and a
• A Web service broker.
• Note IBMs service-oriented architecture is a
  generic model describing service collaboration,
  not specific to Web services.
• See http//www-106.ibm.com/developerworks/webservi
  ces/

23
1. Introduction to Web Services
Service provider
Bind
Publish
Service requestor
Service broker
Find
Service-oriented architecture representation
(Courtesy of IBM Corporation)
24
1. Introduction to Web Services

• Stages of Web services Development and
  Deployment
• Creation Design, development, documentation,
  testing, and distribution.
• Publication Web service hosting and
  maintenance.
• Promotion Directory services, value-added
  services and accreditation.

25
1. Introduction to Web Services
Service requestors
Service providers
Web Services Network Security Reliability QoS Bil
ling
Web services networks act as intermediaries in
Web services interactions.
26
1. Introduction to Web Services

• UDDI (Universal Description, Discovery and
  Integration)
• A framework that defines XML-based registries in
  which businesses can publish information about
  themselves and the services they offer.
• The key to the ultimate success of Web services,
  but has some key limitations, and alternative
  discovery methods are provided by ebXML and
  WS-Inspection.
• Registries are repositories that contain
  documents that describe business data and also
  provide search capabilities and programmatic
  access to remote applications.

27
1. Introduction to Web Services
UDDI Registry
Links to WSDL documents
Publish
Search
SOAP messages
Service provider business application
Service consumer business application
See UDDI XML Schema at http//www.uddi.org/schema/
uddi_v2.xsd
28
1. Introduction to Web Services

• UDDI (Universal Description, Discovery and
  Integration) (continued)
• Direct and indirect discovery
• Direct is maintained by the service provider
  (advantage - accurate and current).
• Indirect is maintained by a third party
  (advantage - interact without committing).
• The UDDI Business Registry (UBR)
• Register once, publish everywhere replication.
• Only register with your custodian to avoid
  duplication.
• Structured like the telephone book.
• Mainly supports indirect, but can be direct.

29
1. Introduction to Web Services

• UDDI (Universal Description, Discovery and
  Integration) (continued)
• UBR has five components
• Business information
• Business-service information
• Binding information
• Service specification information
• Publisher-assertion information
• Organization adopting private registries more
  quickly than public registries (Gartner Group-75
  by 2005).

30
1. Introduction to Web Services

• UDDI (Universal Description, Discovery and
  Integration) (continued)
• Four varieties of private UBRs
• E-marketplace
• Portal
• Partner catalog
• Internal enterprise application integration
• Different technologies for different situations.
• E.g. UDDI and ebXML can be used as complimentary
  services.
• Software vendors must incorporate support for
  these technologies into enterprise software and
  must provide Web services application-development
  tools that hide low-level programming details.
• E.g. Microsoft Server 2003 and Tamino 4.1 with
  UDDI and WebDAV.

31
1. Introduction to Web Services

• Acronyms
• UDDI
• WSDL
• SOAP
• HTTP, SMTP, FTP
• Programming (DOM, SAX)
• Schema (DTD, XSD)
• XML

• Practical Examples
• Phone Book
• Contract
• Envelope
• Mailperson
• Speech
• Vocabulary
• Alphabet

32
2. Architecture Infrastructure Committee

• Leadership
• John Gilligan, USAF CIO, Chair.
• Norman Lorentz, OMB CTO, Advisor.
• Three Subcommittees
• Governance Policy guidance and assistance in
  design and implementation of the Enterprise
  Architecture discipline and practice.
• Robert Haycock, OMB, and John Przysucha, DOE.
• Components Identify, mature and facilitate
  use/reuse of Component-based Architectures.
• Reynolds Cahoon, CIO, NARA, and Robert Haycock,
  OMB.
• Emerging Technology Identify technologies with
  the potential to improve the value and quality of
  the FEA.
• Dawn Meyerriecks, CTO, DISA, and Mark Day, DCIO,
  EPA.

33
3. AIC Components Subcommittee

• Vision Interoperable, shareable, re-usable
  Enterprise Architecture Components that support
  the Presidents Management Agenda principles of
  customer-focused, results-oriented, and
  market-based Government.
• Mission Foster the identification, maturation,
  use, and re-use of Enterprise Architecture
  Components and component-based Enterprise
  Architectures in Government.
• Goal Facilitate cross-agency development and
  implementation of Enterprise Architecture
  Components.
• Definition An Enterprise Architecture component
  is defined as a self-contained business process
  or service with predefined functionality that may
  be exposed through a business or technology
  interface.

34
3. AIC Components Subcommittee

• FY 2003 Task Plan
• Task 1. Develop a Components-Based Architecture
  White Paper.
• Lead Harry Feely, Department of Education.
• Task 2. Develop a Components Registry/Repository
  Concept Paper.
• Lead Tim Bass, Air Force (consultant).
• Task 3. Develop a Solution Development Life Cycle
  (SDLC).
• Leads John McManus (NASA) and Daud Santosa
  (USPTO).
• Task 4. Develop and Market a Quick Win.
• Lead David Holyoke, SSA.

35
4. Emerging Components Conference Series

• Date June 26, 2003
• Location Small Business Administration,
  Washington, D.C.
• Purpose To Explore the Potential and Realities
  of Accelerating the Emergence of Components
  Needed for Federal Enterprise Development by
  Tapping the Multiplicative Benefits from Small
  Business Innovation Research (SBIR) Aligned with
  Federal Enterprise Architecture Component Needs.
• Question How can we organize around proven
  catalytic programs like the SBIR to stimulate
  incubator and marketplace mechanisms needed for
  rapid and responsive federal enterprise
  components development?

36
4. Emerging Components Conference Series

• General Purpose
• The Plenary and Framing the Principles Sessions
  would be recorded so in subsequent quarterly
  conferences/workshops the new participants could
  easily get up to speed on this subject and the
  majority of the time would be spent on the
  marketplace for components to populate the
  Components Registry and Repository.
• Mapping to the Governance Subcommittee Work Plan
• Goal 3/Task 3. Develop Joint Component
  Directory/Repository Pilot
• This would support populating this Joint
  Component Directory/Repository Pilot with
  re-usable components.

37
4. Emerging Components Conference Series

• Mapping to the Components Subcommittee Work Plan
• Task 1. Develop a Components-based Architecture
  White Paper
• Ren Cahoon has been invited and accepted to
  present the status of this.
• Task 2. Develop a Components Registry/Repository
  Concept Paper
• Ren Cahoon has also been invited and accepted to
  present the status of this.
• Task 3. Develop a Solution Development Life Cycle
  (SDLC).
• Daud Santosa been invited and accepted to present
  the status of this.
• Task 4. Develop and Market a Quick Win
• The candidate Quick Wins we have discussed have
  been invited to participate in this by completing
  the Components Registry and Repository Template
  and summarizing it in the Lightning Round. Bob
  Haycock has been invited to introduce the FEA
  Components.

38
4. Emerging Components Conference Series

• Mapping to the Emerging Technology Subcommittee
  Work Plan
• Task 1. Lifecycle Process for Managing Adoption
  of Emerging Technology
• This is an implementation of the Lifecycle
  Process we are developing with the help of IAC
  and others.
• Task 2A. Universal Access Working Group
  Collaboration Expedition Workshops
• This working group is involved in the planning of
  this and will be supporting this concept starting
  with the July 15th Workshop.
• Task 2B. Extensible Markup Language (XML) Working
  Group XML Registry/Repository of Inherently
  Governmental Artifacts and Schema.
• The Components Registry and Repository Template
  XML Schema would be registered in the XML
  Registry.
• Task 2C. XML Web Services Working group E-Forms
  Project
• The Components Registry and Repository Template
  XML Schema would be part of this.
• XML Web Services Working Group Pilot Projects
  (12)
• The pilot projects would be contributing their
  Templates and participating in this.

39
5. XML Web Services Working Group

• Chartered by the Federal CIO Council under its
  Architecture and Infrastructure Committee
  (CIOC/AIC)
• Works with the CIOC/AIC, the OMB Solution
  Architects Working Group (SAWG), and the Industry
  Advisory Council (IAC) to produce incubator pilot
  projects in support of the e-Gov Initiatives that
  use XML Web Services to demonstrate increased
  accessibility and interoperability.
• See http//web-services.gov for definitions and
  purpose.
• Recent Press
• Working group tests tools for Web services,
  GCN,12/16/02 Vol. 21 No. 34.
• http//www.gcn.com/21_34/news/20656-1.html
• Let the building begin, GCN, 1/27/03, Vol. 22,
  No. 2.
• http//gcn.com/22_2/

40
5. XML Web Services Working Group

• Users never know what they want
• until they see what they get

41
5. XML Web Services Working Group

• Pilots
• Purpose To populate the Government-wide
  Components Registry and Repository with reusable
  (interoperable) components from successful
  pilots.
• An Enterprise Architecture Component is a
  self-contained business process or service with
  predetermined functionality that may be exposed
  through a business or technology interface.
• Three Step Process
• (1) Identify and Vet in the Working Group.
• (2) Produce the Pilot.
• (3) Operationalize the Successful Pilots.
• Funding Options
• (1) Vendor Resources.
• (2) Agency Resources.
• (3) Combination of (1) and (2).

42
5. XML Web Services Working Group

• Eforms for E-Gov" Pilot Team Questions and
  Answers
• Process
• Open Collaboration with Open Standards in Support
  of the E-Gov and Agency E-Forms Initiatives.
• XML Standards
• Schema, XForms, SVG, XHTML, XML-Signature, etc.
• Time Frame
• Initial Report (May or June) and Final Report
  (October).
• Presentations and Meetings
• FedWeb Conference Tutorial (May 5th - to be
  rescheduled) and Session (May 6th).
• Next on June 18th.
• Contacts
• Team Lead, Rick Rogers (rick_at_fenestra.com)
• Chair, Brand Niemann (niemann.brand_at_epa.gov)

43
5. XML Web Services Working Group

• E-Forms for E-Gov" Pilot Sub-Teams
• Accessibility
• Business Case
• Client Specifications
• Fixed Content Behavior
• Form Selection (six selected)
• Presentation
• Records-Keeping
• Schema (draft paper)
• Security (draft paper)
• Services
• See new Web Site and ListServ
• http//www.fenestra.com/eforms
• Recent news story
• http//www.gcn.com/vol1_no1/daily-updates/22014-1.
  html

44
5. XML Web Services Working Group

• Business Compliance One Stop Revised Business
  Case, April 20, 2003
• Regulatory Reform is just as important as tax
  reform for strengthening the economy
• Three Proposed Strategies for Reducing Regulatory
  Burden
• Make SBA the Advocate for Regulatory Burden
  Reduction.
• Implement E-Forms for Major Industries.
• Implement Compliance Assistance Tools.
• Common Elements of Each Alternative
• E-Forms (like an Intuits Turbo Tax).
• Customer Agent.
• Partnership.

Richard J. Varn, President, RJV Consulting, Des
Moines, Iowa.
45
5. XML Web Services Working Group
Simplified Use Case E-Forms

• Design-time
• Identify the data elements in the form(s),
  harmonize the elements (promoting reuse wherever
  possible) and create an XML Schema for each form
  (XML Collaborator).
• Store the XML Schema in an XML registry (XML
  Collaborator), so that others can access the
  information necessary to
• Create e-forms and paper forms (GIDS).
• Create mapping(s) to information systems, such as
  relational databases, object-oriented databases,
  and flat files (MetaBase Modeler).
• Store in native (Tamino Server) and/or relational
  databases.

• Runtime
• Present user with a form to be filled out. User
  populates the form and submits it (GIDS).
• Create XML from the submitted data (GIDS) that
  complies with the schema registered in the XML
  registry (XML Collaborator) and populate
  information systems with the data gathered from
  the user (MetaMatrix Server and/or Tamino Server).

46
6. Component Registry and Repository Template for
XML Web Services Pilot Projects

• Standard fields
• (1) Company background and capabilities including
  participation in standards organizations. Include
  URL(s) to Web site (s). This could be in the
  format of the UDDI Business Registry (UBR) White
  Pages (general information about a companys
  name, address, contact information and
  identifiers), Yellow Pages (divides the company
  into various categories based on the products or
  services the company offers), and Green Pages
  (technical information about a companys
  products, services and Web services).
• (2) E-Gov pilot architecture (where are the
  re-usable components?, where are the XML Web
  Services?, where are the possibilities for
  interoperability with other vendors in Phase 2?,
  etc.). Include URL(s) to diagrams.
• (3) Demonstration of the pilot. Narrative of what
  the pilot shows. Include URL(s) to instructions
  and functioning Web services.
• (4) Supporting documentation. Include URLs to XML
  artifacts (forms, XML Schema, WSDL, etc.) and
  other information to explain them.
• (5) Lessons learned and suggestions (optional).

47
6. Component Registry and Repository Template for
XML Web Services Pilot Projects

• General Instructions
• All four standard fields of the template need to
  be completed with narrative and URL links while
  fitting within a single standard page size and
  can be provided in word processing, PDF, HTML, or
  XML formats. Completed templates need to be
  submitted one week before the event date to be
  distributed for review by those doing the
  assessment of readiness, but can be revised for
  handout and posting to the vendors Web sites
  after that. The order of the verbal presentations
  will be based on a random drawing of those
  attending the event.
• Note This template will have an XML Schema soon
  based on an extension of the UDDI XML Schema.
• http//www.uddi.org/schema/uddi_v2.xsd

48
7. Solution Architects Working Group (SAWG)

• Background
• This was in response to Charlie Havekost's
  request for the SAWG to do an assessment of the
  readiness of XML Web Services for E-Gov
  Initiatives like E-Grants.
• E-Grants asked the "E-Forms for E-Gov" Pilot to
  do their SF424 XML Schema first and ASAP after
  the February 6th launch and then when we
  delivered it so rapidly Charlie was concerned as
  to whether or not any of the E-Forms vendors were
  actually ready to use it and asked the SAWG
  leadership to hold a discussion in the SAWG on
  how to deal with this and the XML Web Services WG
  was selected to do this by building off the
  vendor participation in "E-Forms for E-Gov" pilot
  and got 11 vendors to commit to doing this and
  presenting it within 30 days.
• We have had several meetings/conference calls
  with the vendors to answer their questions and
  provide the background materials they needed
  which have been posted to the Web site and
  ListServ for all to see and use.

49
E-Grants Single System Solution (1/29/03)
XForms Web Browser Interface
Applicant 3
Applicant 2
Applicant 1
..
Applicant N

Valid XML
XML Collaborator Design Collaboration And
Registration Support
E-Grants Trusted Broker
XML Repository Web Services
Valid XML
XML Repository Web Services
Agency N
Agency 1
Agency 2
Agency 3
..
Trusted Broker Embodies Standards, Benefits
Applicants and Agencies Facilitates
System-to-System Interfaces Builds applicant
knowledge of "core" data Helps identify
commonalities among agency-specific data
Annotations by WG Chair
50
7. Solution Architects Working Group (SAWG)

• Opportunity for Vendors Participating in the
  "E-Forms for E-Gov" Pilot to Pilot the Use of XML
  Web Services in E-Gov Initiatives (e.g. e-Grants,
  etc.) to Support an "Assessment of Readiness" by
  the Working Group for the Solutions Architects
  Working Group (SAWG) and the "QuickWin" Task of
  the Components Subcommittee of the AIC. All
  Vendors were invited to participate.
• 1. Microsoft - Susie Adams
• 2. Adobe - Melonie Warfel
• 3. Soltex - Matthew Garst
• 4. Digital Evolution - Al Lang
• 5. Sand Hill Systems - Krishna Srinivasan
• 6. SeeBeyond - Mike Sinisgalli
• 7. Object Builders - Joe Brophy
• 8. SiloSmashers - Ken Sall (observing)
• 9. Conclusive Technology - Matthew McKennirey
• 10. ITM Associates - Steve Katz
• 11. Pure Edge - Greg O'Connell

See Appendix for Questions and Answers on May 2nd
51
Agenda

• 830 - 9 a.m. Welcome, Introduction, and
  Background.
• 9 a.m. - 12 noon Individual vendor presentations
  using the template.
• Break from about 10-1015 a.m.
• 12 noon - 130 p.m. Lunch on your own.
• 130 - 300 p.m. General questions and
  discussions with all the vendors.
• 300 - 330 p.m. Break.
• 330- 430 p.m. Discussion of "the SAWG
  assessment for readiness" by Federal attendees
  only. Vendors will be excused.

52
Individual Vendor Presentations

• 1. Open GIS Consortium
• 2. Adobe
• 3. Conclusive Technology
• 4. Digital Evolution
• 5. MetaMatrix
• 6. Microsoft
• 7. Object Builders
• 8. Sand Hill Systems
• Note These vendors did not respond by the May
  26th template deadline
• Soltex (Not heard from)
• SeeBeyond (May submit for June 26th)
• ITM Associates (May submit for June 26th)
• Pure Edge (May submit for June 26th)
• AmberPoint (May submit for June 26th)

53
Appendix

• Questions and Answers on May 2nd
• Question Can a vendor (e.g. Speechworks
  International) join the conference call and
  participate in the pilot project at this stage.
• ANSWER While I cannot, nor would I, limit
  participation in the conference call by any
  vendor, we have stipulated that a vendor should
  be a participant in the basic "E-Forms for E-Gov"
  pilot in order to have the background and
  experience for this even more ambitious pilot.

See http//listserv.gsa.gov/cgi-bin/wa?A2ind0305
Lcioc-web-servicesFSP232
54
Appendix

• Questions and Answers on May 2nd (continued)
• Questions for Government e-Forms Team (from Mike
  Connor of Adobe) Rev1.0 5/1/03.
• 1. What specifically are you trying to evaluate /
  test from a technical and/or user standpoint?
• ANSWER Increased interoperability/reusability of
  multiple vendor solutions for E-Gov Initiatives
  through the implementation of XML Web Services.
• a. How would you rank those evaluation areas
  against each other
• i. User experience
• ii. Submission of data to registry
• iii. Creation of form from schema
• iv. Compliance with the ebXML Registry standard
• ANSWER It is an evaluation of the complete
  solution from "user experience/interface" to
  "back end data storage and reuse" using the XML
  Web Services "publish, find, and bind" paradigm
  with at least the data entry form interface with
  data validation against the XML Schema, the
  registration of the XML Schema as a reusable
  component, and an XML Web Services interface for
  linking/chaining to other Web Services.

55
Appendix

• Questions and Answers on May 2nd (continued)
• 2. Is dealing with the registry directly
  sufficient for this demo? ie.
• a. Extracting a schema and building a form around
  it
• b. Registering that form, its meta data and
  schema within the registry
• c. Submitting the
• i. Form,
• ii. Data,
• iii. Form and data back to the registry? Do they
  need to be signed? (assumes that once available
  the data could be used to kick off other process)
• iv. Does the form need to be archived in the
  registry?
• ANSWER See answer to 1.a. Once an E-Gov
  Initiative is selected to pilot, preferably one
  that requires forms for data collection and
  exchange, then an architecture is needed that
  provides for a content model (XML Schema), work
  flow processes, interoperability, reusability,
  etc. and then a strategy for piloting key aspects
  of that with XML Web Services, not the entire
  E-Gov Initiative because that would be doing the
  entire project, not piloting it. Some kind of
  "registry" functionality (ISO 11179, ebXML, UDDI,
  etc.) is an important part of this, but should
  not become the primary focus to the exclusion of
  other parts of the implementation of an XML Web
  Services-based solution. Digital signatures is an
  important, but more advanced aspect of the
  "E-Forms for E-Gov" pilot being worked on by the
  Sub-Teams in the "E-Forms for E-Gov" Pilot.

56
Appendix

• Questions and Answers on May 2nd (continued)
• 3. Can you provide us a minimum set of use case
  examples?
• ANSWER We have an E-Grants XML Schema, we have a
  cross-section of forms that are being selected,
  we have some basic architecture diagrams and work
  flow descriptions and experts, etc. that have
  been distributed and are available at
  http//web-services.gov. This is a key part of
  the challenge and fun of piloting - see the next
  answer.

57
Appendix

• Questions and Answers on May 2nd (continued)
• 4. Specifically from a technical or use case
  standpoint what do we not need to address?
• ANSWER I think the vendors need to use their
  best judgment as to what the essence of an E-Gov
  Initiative is to be piloted with XML Web Services
  and include what is reasonable to do within the
  limited time frame (30 days or less) available to
  support the "readiness assessment" sooner than
  later.

58
Appendix

• Questions and Answers on May 2nd (continued)
• 5. Do you have any guidelines for us in terms of
  the technology platform you would like us to use?
• a. what server technology?
• ANSWER Your choice as long as it supports the
  delivery of XML Web Services on the Internet.
• b. Is there any restriction on which
  implementation of an ebXML Registry we can use?
• ANSWER No, this is a lower priority detail at
  this stage, than being able to reuse the XML
  Schema, etc. through a basic registry.
• c. Registry browser - is there any restriction on
  registry client architecture we can use?
• ANSWER No. See previous answer.
• d. For the purposes of this demo is it adequate
  to deploy the registry browser to the "end user"
  machine?
• ANSWER Yes. See previous answer to b.
• e. Digital signature
• ANSWER See answer to question 2.
• f. Form and XML Schema (Is the main SF 424 form
  sufficient for this pilot?)
• ANSWER It will have to be, it you cannot
  generate a content model (XML Schema) yourself as
  part of the pilot.
• g. Is the use of a single form sufficient?
• ANSWER Probably not because of discussions in
  the "E-Forms for E-Gov" pilot. See Rick Rogers,
  Pilot Team Lead.
• h. Use of current, versus, beta software?
• ANSWER Your choice, but cannot do NDA's (see
  answer to question 8 below)

59
Appendix

• Questions and Answers on May 2nd (continued)
• 6. Do you anticipate additional requirements /
  use cases above the set you provided that you
  would like to see tested in the future? If so
  what are those?
• ANSWER The OMB Solutions Architects Working
  Group (SAWG), the Components Subcommittee, the
  E-Gov Initiative Program Managers, etc. could
  very well suggest that after seeing these pilots,
  but I cannot predict/speculate what those would
  be at this stage. I suggest keeping it simple at
  this stage.

60
Appendix

• Questions and Answers on May 2nd (continued)
• 7. Does the demo need to be made available for
  ongoing use by the team or is the demo /
  presentation sufficient?
• ANSWER These pilots should be available in some
  form after the initial presentations (end of
  May-early June) for use in related activities
  (e.g. the Components Technology Conference, June
  26th, etc.) that will be announced later.

61
Appendix

• Questions and Answers on May 2nd (continued)
• 8. At this point do you require any financial or
  pricing information and can that be provided
  confidentially?
• ANSWER We are not addressing/including financial
  or pricing information (public or confidential)
  at this stage of this pilot. We also cannot enter
  into Non-Disclosure Agreements (NDA).