0
Service-Oriented Architecture
and its Implications for
Software Life Cycle Activities


Grace A. Lewis
Software Engineerin...
Agenda

SOA: Basic Concepts
Pillars of Service-Oriented Systems Development
Implications of SOA for Software Life Cycle Ac...
What is SOA?

Service-oriented architecture is a way of designing, developing, deploying
and managing systems, in which
  ...
Services

Services are reusable components that represent
business tasks.
    •   Customer lookup
    •   Credit card vali...
SOA Infrastructure

Set of technologies that bind service consumers to services
    •   Products, standards and protocols ...
Service Consumers

Clients for the functionality provided by the services
    •   End-user applications
    •   Internal s...
Services and Cost-Efficiency

       Order Processing   Invoicing Application   CRM Application
         Application
     ...
Services and Agility

                                                                                    The new
    Orde...
Services and Adaptability

      Order Processing
                                                                        ...
Services and Legacy Leverage

                                      Order
                                    Processing
 ...
Components of a Service-Oriented System

                      End User                          Internal         External...
Three Basic Operations to Support Service-
Oriented Systems
Service Discovery
   •   Services repositories are queried for...
An Example of SOA Implementation: WS* Web
Services
WS* Web Services is one
mechanism for implementing a                Orc...
So What Is Different?

There is nothing conceptually new, but it has brought together existing
technologies and good pract...
So What is the Challenge? Creating Good
Services!
Represent reusable tasks
Have (or may have) multiple consumers
Permit co...
Agenda

SOA: Basic Concepts
Pillars of Service-Oriented Systems Development
Implications of SOA for Software Life Cycle Ac...
Pillars of Service-Oriented Systems Development


                                     SOA-Based Systems
                 ...
Different Business Needs and Goals Drive
Different SOA Strategies

   Business Needs and Goals                         SOA...
Linkage of Business Processes to Services

1. Business processes to support business goals are identified.
2. Candidate se...
Disciplined SOA Adoption

                 Introduction
              Address Specific Pain

                Proof of Conc...
SOA Governance

SOA governance provides a set of policies, rules, and enforcement
mechanisms for developing, using, and ev...
Examples of Governance Elements


                                            People                                      ...
Match of Technologies to the Problem
Domain
Need a realistic understanding on what technologies can do in the
specific pro...
T-CheckSM

                                                                                 Context
Experiment, situated i...
Service-Oriented Systems Require a Different




                                                                         ...
Agenda

SOA: Basic Concepts
Pillars of Service-Oriented Systems Development
Implications of SOA for Software Life Cycle Ac...
General Process Implications

Processes must reflect the required strategic approach
Processes must be iterative
    •   S...
Some Implications for Requirements
Activities
Require an business process management (BPM) focus
Must deal with a larger n...
Some Implications for Architecture and
Design Activities
The responsibilities of each system component need to be clearly
...
Some Implications for Development Activities

Development environments need to be similar/same as
production environments—...
Some Implications for Testing Activities

System testing of a service consumer requires all services (or test
instances of...
Some Implications for Maintenance Activities

Impact analysis affects a larger number of users
   • Internal and external ...
Less Control

Requires giving up full control—not easy
    •   Tradeoff is agility
Anticipate objections and understand va...
Agenda

SOA: Basic Concepts
Pillars of Service-Oriented Systems Development
Implications of SOA for Software Life Cycle Ac...
Conclusions 1

SOA is an approach to software development where
   •   Services provide reusable functionality with well-d...
Conclusions 2

SOA is not just a buzzword
   •   Currently the best option available for loosely coupled systems integrati...
2008-2009 Course Dates for Migrating Legacy
Components to SOA Environments


                     2008
October 15-16      ...
References

SMART: The Service Migration and Reuse Technique
    •   SMART: Analyzing the Reuse Potential of Legacy Compon...
Upcoming SlideShare
Loading in...5
×

Service-Oriented Architecture and its Implications for ...

814

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
814
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Service-Oriented Architecture and its Implications for ..."

  1. 1. Service-Oriented Architecture and its Implications for Software Life Cycle Activities Grace A. Lewis Software Engineering Institute Integration of Software-Intensive Systems (ISIS) Initiative © 2008 Carnegie Mellon University
  2. 2. Agenda SOA: Basic Concepts Pillars of Service-Oriented Systems Development Implications of SOA for Software Life Cycle Activities Conclusions SOA: Basic Concepts Version 1.7.1 2 © 2008 Carnegie Mellon University
  3. 3. What is SOA? Service-oriented architecture is a way of designing, developing, deploying and managing systems, in which • Services provide reusable business functionality. • Service consumers are built using functionality from available services. • Service interface definitions are first-class artifacts. • An SOA infrastructure enables discovery, composition, and invocation of services. • Protocols are predominantly, but not exclusively, message-based document exchanges. SOA: Basic Concepts Version 1.7.1 3 © 2008 Carnegie Mellon University
  4. 4. Services Services are reusable components that represent business tasks. • Customer lookup • Credit card validation • Weather • Hotel reservation Services can be • Globally distributed across organizations • Reconfigured into new business processes Service interface definitions are well-defined first- class artifacts (ideally) available in a service repository. SOA: Basic Concepts Version 1.7.1 4 © 2008 Carnegie Mellon University
  5. 5. SOA Infrastructure Set of technologies that bind service consumers to services • Products, standards and protocols that support communication — Typically message-based document exchanges o Web Services (HTTP, SOAP, WSDL) o Message-oriented middleware (i.e. IBM Websphere MQ) o Publish/subscribe (i.e. Java Messaging Service — JMS) o CORBA … • Infrastructure services available to service providers and/or service consumers — Security, discovery, data transformation, … • Development, deployment and management tools and guidelines SOA: Basic Concepts Version 1.7.1 5 © 2008 Carnegie Mellon University
  6. 6. Service Consumers Clients for the functionality provided by the services • End-user applications • Internal systems • External systems • Composite services Consumers programmatically bind to services. SOA: Basic Concepts Version 1.7.1 6 © 2008 Carnegie Mellon University
  7. 7. Services and Cost-Efficiency Order Processing Invoicing Application CRM Application Application Customer Lookup - 2 Customer Lookup - 1 Customer Lookup - 3 A service with equivalent functionality can be Customer implemented, and Lookup Service used by all three applications. SOA: Basic Concepts Version 1.7.1 7 © 2008 Carnegie Mellon University
  8. 8. Services and Agility The new Order Processing Course Management application can Application Application use available services. New services can be used by other applications as well. Customer Credit Item Inventory Room Lookup Check Lookup Check Availability Service Service Service Service Service SOA: Basic Concepts Version 1.7.1 8 © 2008 Carnegie Mellon University
  9. 9. Services and Adaptability Order Processing The SOA Application Infrastructure provides a standard communication mechanism between consumers and services. SOA Infrastructure Changes in services have potentially no impact on existing service consumers. Customer Credit Item Inventory Lookup Check Lookup Check Service Service Service Service SOA: Basic Concepts Version 1.7.1 9 © 2008 Carnegie Mellon University
  10. 10. Services and Legacy Leverage Order Processing Application Consumers access the services in a standard way. Legacy platform SOA Infrastructure diversity and complexity is transparent to Inventory It is the consumers. Customer Credit Item Lookup Check Lookup Check service’s task Service Service Service Service to invoke the legacy system. Customer Management Manufacturing System System SOA: Basic Concepts Version 1.7.1 10 © 2008 Carnegie Mellon University
  11. 11. Components of a Service-Oriented System End User Internal External Portal Application System Consumer Service Consumers SOA Infrastructure Internet Development Security Tools Discovery Infrastructure Service Service Service Service A B C D Service Interfaces Enterprise Legacy or New External Information System Service Code System Service Internal Users Implementation SOA: Basic Concepts Version 1.7.1 11 © 2008 Carnegie Mellon University
  12. 12. Three Basic Operations to Support Service- Oriented Systems Service Discovery • Services repositories are queried for services with desired characteristics. Service Composition • Applications/service consumers are built by integrating functionality provided by services. Service Invocation • Services are invoked and service code is executed. SOA: Basic Concepts Version 1.7.1 12 © 2008 Carnegie Mellon University
  13. 13. An Example of SOA Implementation: WS* Web Services WS* Web Services is one mechanism for implementing a Orchestration and service-oriented system. Choreography WSCL, WSCI, BPEL, • Service interfaces are WS-Coordination BPML, BPSS described using Web Quality of Service Discovery Management Services Description Transactions UDDI Security Language (WSDL). Description WSDL • Data is transmitted using SOAP over HTTP. Base Message Format Stack SOAP • UDDI is optionally used as Encoding the directory service. XML Transport Because it is the most common HTTP mechanism, Web Services is Adapted from “XML and Web Services Unleashed”, SAMS Publishing often equated to SOA. SOA: Basic Concepts Version 1.7.1 13 © 2008 Carnegie Mellon University
  14. 14. So What Is Different? There is nothing conceptually new, but it has brought together existing technologies and good practices in a way that works. • More aligned with business — Services represent coarse-grained business tasks • Backed by industry • Standards-based • Greater degree of rigor in interface specifications • Truly loosely-coupled — No need to install specific components — Platform-independent o What is behind the interface is invisible to the consumer SOA: Basic Concepts Version 1.7.1 14 © 2008 Carnegie Mellon University
  15. 15. So What is the Challenge? Creating Good Services! Represent reusable tasks Have (or may have) multiple consumers Permit consumers to bind to services programmatically Correspond to functionality of a stateless nature • Service has no knowledge of previous visits Enable service inputs and outputs that do not require the construction of very complex consumers Are of a request-response nature • Although SOA 2.0 supports events SOA: Basic Concepts Version 1.7.1 15 © 2008 Carnegie Mellon University
  16. 16. Agenda SOA: Basic Concepts Pillars of Service-Oriented Systems Development Implications of SOA for Software Life Cycle Activities Conclusions Pillars Version 1.7.1 16 © 2008 Carnegie Mellon University
  17. 17. Pillars of Service-Oriented Systems Development SOA-Based Systems Development Strategic SOA Technology Change of Alignment Governance Evaluation Mindset High-level mission and SOA governance Contextual technology Development is different business goals need to provides a set of evaluation allows early from traditional systems dictate the focus of the policies, rules, and insight into technologies development—loose strategy of SOA enforcement within the context in coupling between adoption and mechanisms for which they will be used. consumers and implementation. developing, using, and providers, multiple evolving SOA assets ownership, shared and for analysis of their semantics, etc. business value. SOA Design Principles Pillars Version 1.7.1 17 © 2008 Carnegie Mellon University
  18. 18. Different Business Needs and Goals Drive Different SOA Strategies Business Needs and Goals SOA Strategy Increase information available to • Intuitive portals business customers • Creation of services related to customer information Integrate business partners • Heterogeneous interoperability • Back office integration • Identification of business rules Improve business processes • Identification of key processes • Elimination of redundancy • Consistency between processes • Services that access legacy systems Pillars: Strategic Alignment Version 1.7.1 18 © 2008 Carnegie Mellon University
  19. 19. Linkage of Business Processes to Services 1. Business processes to support business goals are identified. 2. Candidate services are identified. • Top-Down — Shared steps between business processes are identified as service candidates. • Bottom-Up — Legacy system inventory is performed. — Systems with functionality to support business processes are identified as migration candidates. 3. Services are selected based on relationship to business goals. Pillars: Strategic Alignment Version 1.7.1 19 © 2008 Carnegie Mellon University
  20. 20. Disciplined SOA Adoption Introduction Address Specific Pain Proof of Concept Spreading Single Application Process Integration Establish Technology Platform Exploitation Multiple Applications (1BU) Process Flexibility Leverage Service Sharing Plateau Multiple Applications (Across BUs) Continuous Adaptation and Evolution Enterprise SOA Infrastructure Virtual Enterprise Adapted from “Meeting the Challenges of SOA Adoption,” keynote by Roy Schulte at the SOA In Action Virtual Conference, November 2006. Pillars: Strategic Alignment Version 1.7.1 20 © 2008 Carnegie Mellon University
  21. 21. SOA Governance SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using, and evolving SOA assets and for analysis of their business value. It provides the who, that what and the how decisions business, engineering and operations are made in order to support a SOA strategy. • Policies and procedures • Roles and responsibilities • Design-time governance • Runtime governance Source: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein Governance Pillars: SOA & Gary So. Version 1.7.1 21 © 2008 Carnegie Mellon University
  22. 22. Examples of Governance Elements People Engineering Roles & Responsibilities Information Business Service and Process Owners Data Ownership Architecture Data Standards Reference Architectures Financial Portfolio Data Quality Architectural Standards Service Funding Model Projects Blueprints & Patterns Service Usage Fees Business Services Platform Funding Applications Technology Strategic SOA Platform Projects Enforcement Platform Decisions Service Ownership Shared Infrastructure Services Service Lifecycle Shared Artifacts Operations Capacity Planning Enforcement Service Levels Enforcement Policies Operations Metrics Collection Governance elements adapted from a presentation by Dr Mohamad Afshar from Oracle Corporation and Ben Moreland from The Hartford at the Business Transformation Conference 2007 Pillars: SOA Governance Version 1.7.1 22 © 2008 Carnegie Mellon University
  23. 23. Match of Technologies to the Problem Domain Need a realistic understanding on what technologies can do in the specific problem domain How to understand and keep up with the “alphabet soup”? • XML, SOAP, WSDL, UDDI, WS-Security? How to determine which standards and technologies to implement in specific situations? How to build systems that are resilient to changes in standards and commercial products that implement them? How to determine if selected technologies will meet QoS requirements? • Security • Availability • Performance All the above questions suggest a need for contextual experimentation. Pillars: Technology Evaluation Version 1.7.1 23 © 2008 Carnegie Mellon University
  24. 24. T-CheckSM Context Experiment, situated in a specific context, with the goal of providing a “technology Develop sanity check” Hypotheses The approach Develop Criteria 1. Formulate hypotheses about the technology 2. Examine these hypotheses against very Design and Implement Solution specific criteria through experimentation Extremely efficient Evaluate Solution Against Criteria • Focus on implementing the simplest experiment to validate technology claims [Hypotheses Sustained] [Hypotheses Refuted] Pillars: Technology Evaluation Version 1.7.1 24 © 2008 Carnegie Mellon University
  25. 25. Service-Oriented Systems Require a Different Change of Mindset Development Approach Traditional Systems Service-Oriented Systems Development Development Tight coupling between system Loose coupling between service components consumers and services Semantics shared explicitly at Semantics shared without much design time communication between developers of consumers and services —In the future, even at runtime Known set of users and usage Potentially unknown set of users and patterns usage patterns System components owned by Systems components potentially the same organization owned by multiple organizations Pillars: Change of Mindset Version 1.7.1 25 © 2008 Carnegie Mellon University
  26. 26. Agenda SOA: Basic Concepts Pillars of Service-Oriented Systems Development Implications of SOA for Software Life Cycle Activities Conclusions SOA and the Software Life Cycle Version 1.7.1 26 © 2008 Carnegie Mellon University
  27. 27. General Process Implications Processes must reflect the required strategic approach Processes must be iterative • Short iterations to respond to business needs SOA governance must be embedded across the full life cycle • Emphasis on problematic areas • Automation where possible Processes must be targeted • Processes targeted at service provider types: internal services vs. external services • Processes targeted at system component provider: service, consumer or infrastructure Technology evaluation must become an integral process component SOA and the Software Life Cycle Version 1.7.1 27 © 2008 Carnegie Mellon University
  28. 28. Some Implications for Requirements Activities Require an business process management (BPM) focus Must deal with a larger number of stakeholders First step is to look at the inventory of business processes and services • Negotiation and adaptation to increase reuse • May cause refactoring of services • A high quality registry makes the process easier In the case of service providers, these need to work with potential requirements • In the same way COTS products vendors work SOA and the Software Life Cycle Version 1.7.1 28 © 2008 Carnegie Mellon University
  29. 29. Some Implications for Architecture and Design Activities The responsibilities of each system component need to be clearly defined—consumers, services and infrastructure • Security, transaction management, data transformations, etc. Constant technology evaluation Evaluation of expected quality of service (QoS) • Tradeoff analysis • Contextual experimentation • Implications of external consumers and services Decisions must promote reuse SOA and the Software Life Cycle Version 1.7.1 29 © 2008 Carnegie Mellon University
  30. 30. Some Implications for Development Activities Development environments need to be similar/same as production environments—as in any distributed system environment • In some cases, the simulation of the production environment might be necessary The emergent characteristics of many SOA technologies cause instability in development activities Require the establishment of processes for the implementation of service interfaces and infrastructure components • Traditional processes apply to service implementation SOA and the Software Life Cycle Version 1.7.1 30 © 2008 Carnegie Mellon University
  31. 31. Some Implications for Testing Activities System testing of a service consumer requires all services (or test instances of them) to be available • From a service consumer perspective, the service is a black box Requires greater and more diverse exception handling • For example, what happens if the service is not available? Regression tests have to evaluate against all consumer requirements and service-level agreements (SLAs) SOA and the Software Life Cycle Version 1.7.1 31 © 2008 Carnegie Mellon University
  32. 32. Some Implications for Maintenance Activities Impact analysis affects a larger number of users • Internal and external users • Service users and users of the systems that implement the services Configuration management becomes more complicated • What artifacts are placed under configuration management? Consumers? Services? Infrastructure? Greater coordination of release cycles (if possible) • Between services and consumers • Between infrastructure and services/consumers SOA and the Software Life Cycle Version 1.7.1 32 © 2008 Carnegie Mellon University
  33. 33. Less Control Requires giving up full control—not easy • Tradeoff is agility Anticipate objections and understand validity • Security • Performance • Control Greatest challenges come from • Single organization may not own the complete system • Services used in unknown ways by (potentially) unknown users Education and training on new mindset is needed. SOA and the Software Life Cycle Version 1.7.1 33 © 2008 Carnegie Mellon University
  34. 34. Agenda SOA: Basic Concepts Pillars of Service-Oriented Systems Development Implications of SOA for Software Life Cycle Activities Conclusions Conclusions Version 1.7.1 34 © 2008 Carnegie Mellon University
  35. 35. Conclusions 1 SOA is an approach to software development where • Services provide reusable functionality with well-defined interfaces. • An SOA infrastructure enables discovery, composition, and invocation of services. • Service consumers are built using functionality from available services. SOA is real • Many successful case studies, mainly in commercial enterprises • Main goal for adoption of SOA is internal integration and business process improvement • Main adoption barriers are lack of governance and finding people with the right skills Conclusions Version 1.7.1 35 © 2008 Carnegie Mellon University
  36. 36. Conclusions 2 SOA is not just a buzzword • Currently the best option available for loosely coupled systems integration and leverage of legacy systems • The technologies to implement SOA will change over time, but the concepts are here to stay — SOA is much broader than its most popular instantiation (Web Services) Development of service-oriented systems is about more than just technologies and standards • It is a way of developing systems • It requires a change of mindset • It requires alignment with business goals and processes to be of value Conclusions Version 1.7.1 36 © 2008 Carnegie Mellon University
  37. 37. 2008-2009 Course Dates for Migrating Legacy Components to SOA Environments 2008 October 15-16 SEI DC 2009 January 28-29 SEI Pittsburgh April 16-17 SEI Pittsburgh July 29-30 SEI DC September 10-11 SEI Europe October 28-29 SEI Pittsburgh Course Dates Version 1.7.1 37 © 2008 Carnegie Mellon University
  38. 38. References SMART: The Service Migration and Reuse Technique • SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment: http://www.sei.cmu.edu/publications/documents/08.reports/08tn008.html T-Checks • Process: http://www.sei.cmu.edu/publications/documents/05.reports/05tn025.html • Applications: — Web Services and Security: Single Sign-On: http://www.sei.cmu.edu/publications/documents/08.reports/08tn026.html — Open Grid Services Architecture: http://www.sei.cmu.edu/publications/documents/07.reports/07tn016.html — Web Services: http://www.sei.cmu.edu/publications/documents/06.reports/06tn021.html — OWL-S (OWL Web Ontology Language for Services): http://www.sei.cmu.edu/publications/documents/06.reports/06tn018.html — MDA (Model-Driven Architecture): http://www.sei.cmu.edu/publications/documents/05.reports/05tn022.html References Version 1.7.1 38 © 2008 Carnegie Mellon University
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×