Best Practices for Adopting ServiceOriented Architectures

1
Best Practices for Adopting Service-Oriented
Architectures

• Session 3-5, Tuesday, September 21, 215-330
  p.m.
• Enterprise Architecture Conference
• September 20-22, 2004
• Ronald Reagan Building and International Trade
  Center, Washington, DC
• Moderator, Brand Niemann, US Environmental
  Protection Agency

2
Logistics and Agenda

• Logistics
• Please submit questions on note cards provided by
  the session facilitator and hold verbal questions
  until the last part.
• Please see the Background Information provided by
  the Moderator in the Proceedings.
• Agenda
• Introduction of Panelists.
• Statements of What Attendees Will Learn.
• Panelist Presentations on Statements.
• Open Discussion Questions Answers.

3
Panelists

• Bill McElhaney (Points 3-5) (See next slide)
• Director, Technology Architecture and Systems
  Integration, Office of Information Resources
  Management, Bureau of Immigration and Customs
  Enforcement Bureau, U.S. Department of Homeland
  Security
• william.mcelhaney_at_dhs.gov
• Troy Holmes (Points 3-5)
• Senior Project Manager-Software Engineer,
  Integrity Technology Partners
• troy.holmes_at_prizum.com
• Jeff Simpson (Points 1 , 2, 6)
• BEA Systems, Principal Integration Architect, BEA
  Government Systems
• jsimpson_at_bea.com

4
What Attendees Will Learn

• 1. Best practices for the implementation of
  service-oriented architectures (SOA) and web
  services.
• 2. Considerations for adopting an SOA as part of
  an organizational integration strategy.
• 3. How an SOA approach can be used as a model for
  making disparate applications more open and
  accessible to broader user groups.
• 4. How agencies are integrating stovepipe systems
  to work together in more effective, secure
  environments.
• 5. How to design a roadmap to consolidate and
  rationalize diverse constituent portals,
  websites, and web services with a common
  architecture, security framework, and user
  interface.
• 6. Practical suggestions for using resources from
  legacy systems with newer applications.

5
Brief Tutorial

• 1. Some Recent Presentations
• 2. Origin of Service-Oriented Architecture
• 3. Web Services
• 4. The 41 View Model of Software Architecture
  Applied to Web Services
• 5. Suggested Roadmap to Implementation
• 6. Pilot Best Practices Dynamic Knowledge
  Repositories with Semantic Web Services
• 7. Seven Fallacies of SOA from Zap Think
• 8. Some Other Pilots
• 9. Contact Information

6
1. Some Recent Presentations

• SOA Concepts, the FEA, and Reuse Best Practices,
  Brent Carlson, LogicLibrary, Federal Architects
  Council, June 16, 2004.
• SOA Holds the Key to Agility, Jason Bloomberg and
  Ronald Schmelzer, ZapThink, Enterprise
  Architecture Summit, June 6-8, 2004.
• (Mark) Forman calls for new approach to the
  Federal Enterprise Architecture, GCN, May 20,
  2004 (Remarks at the Web Services SOA in
  Government IT Conference.)
• Service-Oriented Architecture What Next?, David
  Chappell, Chappell Associates, Federal
  Architects Council, April 8, 2004.
• Web Services Best Practices Workshop for the CIO
  Councils XML Web Services Working Group at the
  White House Conference Center, Mark Secrist, HP
  Federal Services, September 24, 2004.

7
1. Some Recent Presentations(Continued)

• Service-Oriented Architecture and Grid Computing,
  Marc Brooks, MITRE, Third Quarterly Emerging
  Technology Components Conference An Emerging
  Public-Private Partnership at FOSE 2004, Emerging
  Technology Subcommittee, Architecture
  Infrastructure Committee, CIO Council, June 3,
  2004. (See next slide and http//componenttechnolo
  gy.org)
• Emergence of a Distributed Services Grid
  Realizing Multiplicative Returns when eGovernment
  Service Components Align in a Services-Oriented
  Architecture, Fourth Quarterly Emerging
  Technology Components Conference An Emerging
  Public-Private Partnership at MITRE (Also see
  componenttechnology.org)
• Global Justice Information Sharing Initiative
  Service-Oriented Architecture Subcommittee, Brand
  Niemann and Susan Turnbull, November 10, 2003
  (See http//web-services.gov).
• Implementing Component-Based Government
  Enterprise Architecture with Semantic Web
  Services, Brand Niemann, Enterprise Architecture
  Conference, September 10-13, 2003 (See
  http//web-services.gov).

8
1. Some Recent PresentationsGrid and Web
Services Standards - Marc Brooks, MITRE
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
9
1. Some Recent Presentations Emerging XML Stack
Architecture for the Semantic Web Grid Agents
- Leo Obrst, MITRE

• Semantic Brokers
• Intelligent Agents
• Advanced Applications
• Use, Intent Pragmatics
• Trust Proof Security Identity
• Reasoning/Proof Methods
• OWL, DAMLOIL Ontologies
• RDF Schema Ontologies
• RDF Instances (assertions)
• XML Schema Encodings of Data Elements
  Descriptions, Data Types, Local Models
• XML Base Documents
• Grid Semantic Grid New System Services,
  Intelligent QoS

Agents, Brokers, Policies
Intelligent Domain Services, Applications
Sem-Grid Services
Water, LISP?
10
1. Some Recent PresentationsSome Strategic
Direction Recommendations-Brand Niemann, US EPA

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

11
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. Origin of Service-Oriented Architecture
Service provider
Bind
Publish
Service requestor
Service broker
Find
Service-oriented architecture representation
(Courtesy of IBM Corporation)
13
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
3. Web Services

• The SOA has four key functional components
• Service Implementation
• Build from scratch, provide a wrapper, or create
  a new service interface for an existing Web
  Service.
• Publication
• Author the WSDL document, publish the WSDL on a
  Web Server, and publish the existence of your
  WSDL in a Web Services registry using a standard
  specification (UDDI).
• Discovery
• Search the registry, get the URL, and download
  the WSDL file.
• Invocation
• Author a client (SOAP) using the WSDL and make
  the request (SOAP message) and get the response
  (SOAP message).

15
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
16
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

17
3. 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.

18
3. Web Services
Service requestors
Service providers
Web Services Network Security Reliability QoS Bil
ling
Web services networks act as intermediaries in
Web services interactions.
19
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.

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

21
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
22
5. Suggested Roadmap to Implementation

• Best Practices for Adopting Service-Oriented
  Architectures Dynamic Knowledge Repositories
  (DKR), Best Practices in Categorizing Government
  Information Forum, July 8, 2004
• (1) Service Taxonomy-driven Enterprise
  Architecture and Communities of Practice
• Organizes similar functions and expertise (see
  slide 24).
• (2) Federated Repository
• Supports (1) in collaboration on and reuse of
  services components (see slide 25).
• (3) Semantic Interoperability
• Improves content of (2) to moves towards highest
  level of interoperability (see slide 26).

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

24
5. Suggested Roadmap to Implementation

• Best Practice Example of a Service
  Taxonomy-driven Enterprise Architecture and
  Communities of Practice
• 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!

25
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
26
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.

27
6. Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
http//web-services.gov
28
6. Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
29
6. Pilot Best Practices Dynamic Knowledge
Repositories with Semantic Web Services
30
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
31
8. Some Other Pilots

• Recall the SOA Roadmap (slides 22-23)
• (1) Service Taxonomy-driven Enterprise
  Architecture and Communities of Practice
• 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).

32
9. 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