Service-Oriented Architecture and its Implications for ...
Upcoming SlideShare
Loading in...5
×
 

Service-Oriented Architecture and its Implications for ...

on

  • 1,016 views

 

Statistics

Views

Total Views
1,016
Views on SlideShare
1,016
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Service-Oriented Architecture and its Implications for ... Service-Oriented Architecture and its Implications for ... Presentation Transcript

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