Best Practices for Adopting Service-Oriented Architectures

Document Sample
Best Practices for Adopting Service-Oriented Architectures Powered By Docstoc
					   Best Practices for Adopting
  Service-Oriented Architectures
         Session 3-5, Tuesday, September 21, 2:15-3:30 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




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

                                                               2
                        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@dhs.gov
• Troy Holmes (Points 3-5)
   – Senior Project Manager-Software Engineer, Integrity Technology
     Partners
      • troy.holmes@prizum.com
• Jeff Simpson (Points 1 , 2, & 6)
   – BEA Systems, Principal Integration Architect, BEA Government
     Systems
      • jsimpson@bea.com
                                                                    3
     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.
                                                           4
                  Brief Tutorial
•   1. Some Recent Presentations
•   2. Origin of Service-Oriented Architecture
•   3. Web Services
•   4. The 4+1 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

                                                             5
 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
  Council‟s XML Web Services Working Group at the
  White House Conference Center, Mark Secrist, HP
  Federal Services, September 24, 2004.                      6
 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://componenttechnology.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).
                                                                   7
     1. Some Recent Presentations
     Grid and Web Services Standards - Marc Brooks, MITRE




 Started far
  apart in                                            WS-I Compliant
applications
                Have been                              Technology
      &         converging                                Stack
technology                                   WSRF




           Convergence of Core Technology Standards allows
          Common base for Business and Technology Services
                                                                8
   1. Some Recent Presentations
      Emerging XML Stack Architecture for the Semantic
         Web + Grid + Agents - Leo Obrst, MITRE
• Semantic Brokers                              Agents, Brokers, Policies

• Intelligent Agents
                                         Intelligent Domain Services, Applications
• Advanced Applications
• Use, Intent: Pragmatics
• Trust: Proof + Security + Identity        Use, Intent           Pragmatic Web
• Reasoning/Proof Methods                     Trust              Security/Identity

• OWL, DAML+OIL: Ontologies              Reasoning/Proof         Inference Engine

• RDF Schema: Ontologies                 Higher Semantics              OWL

• RDF: Instances (assertions)               Semantics           RDF/RDF Schema
• XML Schema: Encodings of Data             Structure              XML Schema
  Elements & Descriptions, Data Types,
  Local Models                             Syntax: Data                XML

• XML: Base Documents
• Grid & Semantic Grid: New System                                                   9
                                          Sem-Grid Services        Water, LISP?
  Services, Intelligent QoS
 1. Some Recent Presentations
             Some 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.)
                                                 10
     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: IBM‟s service-oriented architecture is a
  generic model describing service collaboration,
  not specific to Web services.
  – See http://www-106.ibm.com/developerworks/webservices/

                                                             11
      2. Origin of Service-Oriented
                         Architecture
                               Service
                               provider

               Publish                          Bind




          Service                                      Service
          broker                Find                   requestor


Service-oriented architecture representation (Courtesy of IBM Corporation)



                                                                             12
                3. Web Services
• A Service-Oriented Architecture (SOA) means
  that the architecture is described and organized
  to support Web Service‟s 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.
                                                      13
                    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).



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

                                                            15
              3. Web Services
• Acronyms:             • Practical Examples:
  – UDDI                  –   Phone Book
  – WSDL                  –   Contract
  – SOAP                  –   Envelope
  – HTTP, SMTP, FTP       –   Mailperson
  – Programming (DOM,     –   Speech
    SAX)
  – Schema (DTD, XSD)     – Vocabulary
  – XML                   – Alphabet


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


                                                  17
                      3. Web Services
                                                      Service requestors
Service providers




                            Web Services Network:
                                  Security
                                 Reliability
                                    QoS
                                   Billing




                    Web services networks act as intermediaries
                    in Web services interactions.
                                                                           18
     4. The 4+1 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 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.




                                                                   19
     4. The 4+1 View Model of Software
    Architecture Applied to Web Services
• 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).

                                                        20
 4. The 4+1 View Model of Software
Architecture Applied to Web Services
  End User                            Programmers
  Functional Requirements             Software Management

                                       Implementation
   Logical (design)
                                       (Development or
   View
                                       Component) View


                      Use-Case View

       Process                         Deployment
       View                            (Physical) View


 SOA Architects                       System Engineering
 JIT Integration of Web Services      Platforms

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

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

                                                                             23
        5. Suggested Roadmap to
             Implementation
• Best Practice Example of a Service Taxonomy-driven
  Enterprise Architecture and Communities of Practice:
   – World Bank‟s Business Function Models, Denise Bedford,
     KM.Gov Meeting, May 26, 2004:
      • The World Bank‟s 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!



                                                                                 24
                   5. Suggested Roadmap to
                        Implementation
                                          Enterprise Ontology and
                                          Web Services Registry

       Dynamic                            Semantic Web
                          Web Services
       Resources                          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         Interoperable   Interoperable
Dragan Sretenovic.
                          Syntax          Semantics
                                                                    25
        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.

                                                                                26
6. Pilot Best Practices Dynamic Knowledge
 Repositories with Semantic Web Services




              http://web-services.gov   27
6. Pilot Best Practices Dynamic Knowledge
 Repositories with Semantic Web Services




                                        28
6. Pilot Best Practices Dynamic Knowledge
 Repositories with Semantic Web Services




                                        29
  7. Seven Fallacies of SOA from ZapThink
• Fallacy #1: There‟s 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), it‟s easy to accept that SOA is inevitable.
    See http://www.zapthink.com/report.html?id=ZAPFLASH-08052004   30
         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).

                                                               31
          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@epa.gov.
• Interagency Working Group on Sustainable Development Indicators:
   – http://www.sdi.gov.
• CIO Council‟s Architecture & Infrastructure Committee and
  Emerging Technology Subcommittee:
   – http://web-services.gov.
   – http://componenttechnology.org.
• CIO Council‟s Best Practices Committee (Knowledge Management
  Working Group) and Semantic (Web Services) Interoperability
  Community of Practice:
   – http://km.gov and http://web-services.gov


                                                                    32