EPA Region 4 Implementing a ServiceOriented Architecture: Pilot Project Design and Initial Results

1
EPA Region 4 - Implementing a Service-Oriented
Architecture Pilot Project Design and Initial
Results

• Brand Niemann, Enterprise Architecture Team
  Office of Environmental Information
• U.S. Environmental Protection Agency
• October 1, 2004

2
Overview

• 1. Background (slides 3-7)
• 2. Best Practices for Implementing a
  Service-Oriented Architecture (slides 8-28)
• 3. Pilot Design and Initial Results (slides
  29-37)
• 4. Contact Information (slide 38)

3
1. Background

• Draft Region 4 Business and Technology
  Infrastructure Assessment, September 23, 2004,
• Incorporate regional requirements within the
  Agencys EA.
• Need for a data integration platform.
• 46 systems and 14 candidate new technologies.
• Opportunity to use EA tools (ETL, data mart, GIS,
  portal, analytic tools) to support Region 4
  championing Regional State of the Environment
  Report.
• Current field data collection and laboratory data
  systems limit data reuse, cause lost data, and
  inhibit data analysis.
• Web Services is one technical approach to
  accessing state and other Federal data sources.
• Need to provide greater expertise in advanced
  technologies and knowledge management.

See next slide for Region 4 definition.
4
1. Background
5
1. Background

• Some other ideas/issues
• Tomorrows Vision The Semantic Web (Molly
  Holzschlag, EPA Web Workgroup Training
  Conference, Keynote Address on Meeting the
  Standard - The Future of the Web, August 10,
  2004).
• The lack of a metadata repository and
  interoperability between Web Service node tools
  is hindering the build-out of the Exchange
  Network at the state-level (Kim Nelson, EA
  Conference Keynote, September 22, 2004).
• Harvest the EPA Science Forum 2004 content for
  input to the EA (John Sullivan, September 10,
  2004).
• http//www.epa.gov/ord/sceinceforum/2004/poster-or
  d-AtoM.htm
• Map the FEA BRM/TRM/SRM/DRM to the SOA for
  Semantic Web Services and use the Suggested
  Roadmap to Implementation (Brand Niemann, EA
  Conference Presentation, September 21, 2004).
• This is similar to the XML Web Services pilot
  done for the Region 3 and Chesapeake Bay Program
  during 2001-present (see http//web-services.gov/x
  mlpilot.htm) (see slide 6).
• Use the OASIS Web Services for Remote Portlets
  (WSRP) Standard and Application Scenarios (see
  slide 7).
• Web Services is sharing programs on the Web and
  the Semantic Web is sharing information on the
  Web (Evren Sirin and James Hendler, Semantic Web
  and Web Services, Collaborative Expedition
  Workshop 35 at the NSF, September 14th, 2004.

6
1. Background
http//www.sdi.gov
7
1. Background
OASIS Web Services for Remote Portals Web Site
http//oasis-open.org/committees/wsrp
8
2. Best Practices for Implementing a
Service-Oriented Architecture

• 2.1 Some Recent Presentations (slides 9-10)
• 2.2 Origin of Service-Oriented Architecture
  (slides 11-12)
• 2.3 Web Services (slides 13-15)
• 2.4 The 41 View Model of Software Architecture
  Applied to Web Services (slides 16-18)
• 2.5 Suggested Roadmap to Implementation (slides
  19-22)
• 2.6 Pilot Best Practices Dynamic Knowledge
  Repositories with Semantic Web Services (slides
  23-26)
• 2.7 Seven Fallacies of SOA from Zap Think (slides
  27)
• 2.8 Some Other Pilots (slides 28)

Excerpts from EA Conference, Panel Presentation,
September 21st, at http//web-services.gov/eabran
d92104.ppt
9
2.1 Some Recent Presentations
Grid
GT1
GT2
OGSi
WS-I Compliant Technology Stack
Have been converging
WSRF
BPEL
WS-
WSDL, SOAP
XML
HTTP
Web
Convergence of Core Technology Standards allows
Common base for Business and Technology Services
Service-Oriented Architecture and Grid Computing,
Marc Brooks, MITRE, Third Quarterly Emerging
Technology Components Conference An Emerging
Public-Private Partnership at FOSE 2004, March
23-25, 2004, Emerging Technology Subcommittee,
Architecture Infrastructure Committee, CIO
Council. (See http//componenttechnology.org)
10
2.1 Some Recent Presentations

• Some Strategic Direction Recommendations
• Involve taxonomy (ontology) expertise in
  improving the FEA classification scheme
  (taxonomy) and its extension into the agencies.
  (This should also help the Line of Business Task
  Forces work.)
• Involve knowledge management expertise in
  building a comprehensive knowledge-base
  (repository) of enterprise architecture (OMB
  budget, solutions like Service-Oriented, Web
  Services, etc.)

Opening Presentation, Brand Niemann, US EPA,
Fourth Quarterly Emerging Technology Components
Conference An Emerging Public-Private
Partnership at MITRE, June 3, 2004, Emerging
Technology Subcommittee, Architecture
Infrastructure Committee, CIO Council. (See
http//componenttechnology.org)
11
2.2 Origin of Service-Oriented Architecture

• IBM has created a model to depict Web services
  interactions which is referred to as a
  service-oriented architecture comprising
  relationships among three entities (see next
  slide)
• 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/

12
2.2 Origin of Service-Oriented Architecture
Service provider
Bind
Publish
Service requestor
Service broker
Find
Service-oriented architecture representation
(Courtesy of IBM Corporation)
13
2.3 Web Services

• A Service-Oriented Architecture (SOA) means that
  the architecture is described and organized to
  support Web Services dynamic, automated
  description, publication, discovery, and use.
• The SOA organizes Web Services into three basic
  roles
• The service provider (publish)
• The service requestor find)
• The service registry (bind)
• The SOA is also responsible for describing how
  Web Services can be combined into larger services.

14
2.3 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
15
2.3 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

16
2.4 The 41 View Model of Software Architecture
Applied to Web Services

• 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.

17
2.4 The 41 View Model of Software Architecture
Applied to Web Services

• 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).

18
2.4 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
19
2.5 Suggested Roadmap to Implementation

• Best Practices for Adopting Service-Oriented
  Architectures Dynamic Knowledge Repositories
  (DKR)
• (1) Service Taxonomy-driven Enterprise
  Architecture and Communities of Practice (CoP)
• Organizes similar functions and expertise (see
  slide 21).
• (2) Federated Repository
• Supports (1) in collaboration on and reuse of
  services components (see slide 22).
• (3) Semantic Interoperability
• Improves content of (2) to moves towards highest
  level of interoperability (see slide 23).

Best Practices in Categorizing Government
Information Forum, July 8, 2004, at
http//web-services.gov/cgi70804.ppt
20
2.5. Suggested Roadmap to Implementation

• Best Practices for Adopting Service-Oriented
  Architectures - Some Recent Activities
• (1) Service Taxonomy-driven Enterprise
  Architecture and Communities of Practice (CoP)
• Joint Workshop on Multiple Taxonomies, April
  28th, and National Infrastructure for Community
  Statistics CoP Initiative and Pilot Project
  Presentation, June 21st.
• Coordinate the CoP Organization, Web Site Design,
  and Network Nodes (see http//www.sdi.gov).
• (2) Federated Repository
• Workshop on Software Component Development,
  Reuse, and Management, May 11th, and Federal
  Architects Council Meeting on SOA Concepts, the
  FEA, and Reuse Best Practices, June 16th.
• (3) Semantic Interoperability
• Joint Semantic Interoperability CoP/Ontolog Forum
  Meeting, July 7th, and Second Semantic
  Technologies for eGovenment Conference, September
  8-9th.

See http//colab.cim3.net/cgi-bin/wiki.pl?Expediti
onWorkshop And http//web-services.gov
21
2.5 Suggested Roadmap to Implementation

• Best Practice Example of a Service
  Taxonomy-driven Enterprise Architecture and
  Communities of Practice (CoP)
• World Banks Business Function Models, Denise
  Bedford, KM.Gov Meeting, May 26, 2004
• The World Banks is a narrow and deep hierarchy
• Level 1 General Business Area
• Level 2 Business Activity
• Level 3 Business Process
• Level 4 Task
• Note A service taxonomy is an inherent part of
  a business taxonomy and emerges at Level 3 and
  below. If you can keep business function and
  organizational unit as separate attributes, you
  can then see which organizational units may be
  offering the same kinds of services and this
  might help to form communities of practice across
  organizational units!

22
2.5 Suggested Roadmap to Implementation
Enterprise Ontology and Web Services Registry
Dynamic Resources
Semantic Web Services
Web Services
Static Resources
WWW
Semantic Web
Source Derived in part from two separate
presentations at the Web Services One Conference
2002 by Dieter Fensel and Dragan Sretenovic.
Interoperable Syntax
Interoperable Semantics
23
2.5 Suggested Roadmap to Implementation

• European Interoperability Framework in Be
  Enterprising, Jaap, Schekkerman, Founder,
  President and Thought Leader of the Institute for
  Enterprise Architecture Development (IFEAD), July
  3, 2004
• Organizational Interoperability
• Concerned with business goals, modeling business
  processes, and bring about collaboration between
  those wanting to exchange information but that
  may have different internal organizations and
  structures for their operations.
• Technical Interoperability
• Concerned with the technical issues of linking up
  computer systems and services.
• Semantic Interoperability
• Concerned with ensuring that the precise meaning
  of exchanged information is understandable by any
  other application not initially developed for
  this purpose.

24
2.6 Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
http//web-services.gov
25
2.6 Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
26
2.6 Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
27
2.7 Seven Fallacies of SOA from ZapThink

• Fallacy 1 Theres Nothing New Under the Sun,
  and SOA Is No Exception.
• Fallacy 2 SOA Is a Revolutionary Paradigm
  Shift.
• Fallacy 3 SOAs are All Hype, No Substance.
• Fallacy 4 SOA is a Panacea.
• Fallacy 5 The Overhead from SOA Leads to
  Unacceptably Poor Performance.
• Fallacy 6 A Bottom-Up Approach to SOA Is Good
  Enough.
• Fallacy 7 SOA is Optional.
• The ZapThink Take SOA is challenging and often
  quite risky so solid education, thorough
  preparation, and a careful approach are all
  important. With a value proposition as broad and
  strategic as that (an agile IT infrastructure),
  its easy to accept that SOA is inevitable.

See http//www.zapthink.com/report.html?idZAPFLAS
H-08052004
28
2.8 Some Other Pilots

• Recall the SOA Roadmap (slide 19)
• (1) Service Taxonomy-driven Enterprise
  Architecture and Communities of Practice (CoP)
• Broadstrokes IDSiGIS (GeoResponse-VoiceXML Web
  Services for Emergency Notifications and
  Alerting).
• (2) Federated Repository
• NobleStar (Flashline and Logic Library
  Repositories).
• (3) Semantic Interoperability
• ImageMatters (Semantic Mapping and Situation
  Awareness)
• Unicorn (Semantic Information Management-Children
  s Health Ontology).

29
3. Pilot Design and Initial Results

• 3.1 Web Site Content Service Taxonomy (slide 30)
• 3.2 Mapping of BRM/TRM/SRM to SOA (slide 31)
• 3.3 Mapping of DRM to an XML Profile (slide 32)
• 3.4 Repurposing of Selected Content Sources
  (slide 33)
• 3.5 Integrated Data Information Platform
  (slides 34)
• 3.6 Application of WSRP Technology (slides 35-36)
• 3.7 Some Next Steps (slide 37)

30
3.1 Web Site Content Service Taxonomy

• Press Releases
• Contact Database
• Strategic Plan
• Topics Issues
• Terminology
• State Agencies
• NGO Data Information Providers
• The Four Es (Enterprise Architecture,
  Environmental Indicators, Exchange Network,
  Emergency Operations) (see slide 33).

31
3.2 Mapping of BRM/TRM/SRM to SOA
BRM
SRM
TRM
Go to the Best Practices Dynamic Knowledge
Repository at http//web-services.gov to use the
FEA Reference Model taxonomies as Web Service
nodes.
32
3.3 Mapping of DRM to an XML Profile

• Proposal from Michael C. Daconta, Metadata
  Program Manager, U.S. Department of Homeland
  Security
• Some minor modifications to the wording, but most
  importantly, to the DRM structure in three areas,
  namely context, exchange and data element
  description.
• The formation of a joint SICoP/XML-CoP working
  group to create a DRM XML Profile.  Such a
  profile would go a long way to improving
  information sharing. I would be happy to
  spearhead the group.
• A schedule of presentations as follows
  Collaborative Expedition Workshop 36 on October
  19th, the AIC Monthly Meeting on October 21st,
  and the XML 2004 Keynote Address, November 16th.

Approved September 30th at the SICoP Management
Team Meeting and previously by the other CoPs
participating.
33
3.4 Repurposing of Selected Content Sources

• The Four Es (recall slide 30)
• Enterprise Architecture
• Region 4 Business and Technology Infrastructure
  Assessment
• Draft document from SRA to EPA, September 23,
  2004.
• Environmental Indicators
• Linking Environmental Trends to EPA Research,
  Region 4s 2004 Environmental Research Seminar,
  September 28-29, 2004
• http//www.epa.gov/region4
• Exchange Network
• National Neighborhood Indicators Partnership
  (NNIP) (Region 4 Cities Miami, Florida Atlanta,
  Georgia Louisville, Kentucky and Chattanooga,
  Tennessee)
• http//www.urban.org/nnip
• Emergency Operations
• Commercialization of EPAs 2002 CIO Council
  Showcase of Excellence Award Winning XML Voice
  XML Web Service
• http//GeoResponse.com

34
3.5 Integrated Data Information Platform
Content gives us the semantics
(taxonomy/ontology) the interoperability, Adam
Pease, SICoP Meeting at MITRE, May 19,
2004. Structure comes from the content
itself, The Large Document Problem, Lucian
Russell, Categorization of Government Information
WG Meeting, 5/10/04.
35
3.6 Application of WSRP Technology
http//portalstandards.oracle.com/portal/page?_pag
eid34,31863,34_31871_dadwsrp_schemaWSRP
36
3.6 Application of WSRP Technology
http//www.oracle.com/technology/products/ias/port
al/pdk_examples.html
37
3.7 Some Next Steps

• Presentations on DRM XML Profile and WSRP at the
  Collaborative Expedition Workshop 36 on October
  19th.
• Use Vivisimos Clustering Search Engine to refine
  the Region 4 Web content Service Taxonomy and
  repurpose selected Region 4 applications into XML
  Web Services.
• http//clusty.com/ and http//web-services.gov/
• Index selected Region 4 files, including email,
  on local hard drives (use the new FAST/NextPage
  Chrome).
• Provide Region 4 emergency operations test data
  set to the Georesponse.com pilot project. Also
  involve their partner (IDSIGIS) who has built the
  Tier II Manager for Web-based data submission in
  Maryland.
• See http//www.idsigis.com and http//www.govtech.
  net/news/story.print.php?id88688
• Implement the W3Cs Semantic Web for E-Government
  Suggestions
• Eric Miller, The Semantic Web A Web of Machine
  Processible Data, Second Semantic Technologies
  for eGovernment Conference, September 8-9, 2004
  (see http//web-services.gov/miller90804.ppt).
• Refine both the Region 4 Enterprise Architecture
  and Region 4 Information Architecture.

38
4. Contact Information

• U.S. Environmental Protection Agency, Office of
  Environmental Information (Office of the Chief
  Information Officer-CIO)
• Enterprise Architecture Team.
• Computer Scientist and Semantic XML Web Services
  Specialist.
• 202-566-1657, niemann.brand_at_epa.gov.
• Interagency Working Group on Sustainable
  Development Indicators
• http//www.sdi.gov.
• CIO Councils Architecture Infrastructure
  Committee and Emerging Technology Subcommittee
• http//web-services.gov.
• http//componenttechnology.org.
• CIO Councils Best Practices Committee (Knowledge
  Management Working Group) and Semantic (Web
  Services) Interoperability Community of Practice
• http//km.gov and http//web-services.gov