Transcription
Service-Oriented Architectureand its Implications forSoftware Life Cycle ActivitiesGrace A. LewisSoftware Engineering InstituteIntegration of Software-Intensive Systems (ISIS) Initiative 2008 Carnegie Mellon University
AgendaSOA: Basic ConceptsPillars of Service-Oriented Systems DevelopmentImplications of SOA for Software Life Cycle ActivitiesConclusionsSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University2
What is SOA?Service-oriented architecture is a way of designing, developing, deployingand 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 ofservices. Protocols are predominantly, but not exclusively, message-based documentexchanges.SOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University3
ServicesServices are reusable components that representbusiness tasks. Customer lookup Credit card validation Weather Hotel reservationServices can be Globally distributed across organizations Reconfigured into new business processesService interface definitions are well-defined firstclass artifacts (ideally) available in a servicerepository.SOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University4
SOA InfrastructureSet of technologies that bind service consumers to services Products, standards and protocols that support communication— oWeb Services (HTTP, SOAP, WSDL)oMessage-oriented middleware (i.e. IBM Websphere MQ)oPublish/subscribe (i.e. Java Messaging Service — JMS)oCORBA Infrastructure services available to service providers and/orservice consumers— Typically message-based document exchangesSecurity, discovery, data transformation, Development, deployment and management tools and guidelinesSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University5
Service ConsumersClients for the functionality provided by the services End-user applications Internal systems External systems Composite servicesConsumers programmatically bind to services.SOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University6
Services and Cost-EfficiencyOrder ProcessingApplicationInvoicing ApplicationCRM ApplicationCustomerLookup - 2CustomerLookup - 1CustomerLookup - 3CustomerLookupServiceA service withequivalentfunctionality can beimplemented, andused by all threeapplications.SOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University7
Services and AgilityOrder ProcessingApplicationThe newapplication canuse availableservices.Course ManagementApplicationNew services canbe used by otherapplications ServiceSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University8
Services and AdaptabilityOrder ProcessingApplicationThe SOAInfrastructureprovides a standardcommunicationmechanismbetween consumersand services.SOA InfrastructureChanges in serviceshave potentially noimpact on existingservice temLookupServiceInventoryCheckServiceSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University9
Services and Legacy versity andcomplexity istransparent toconsumers.Consumers accessthe services in astandard way.SOA oryCheckServiceIt is theservice’s taskto invoke thelegacysystem.Manufacturing SystemSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University10
Components of a Service-Oriented SystemEnd rService ConsumersSOA DService InterfacesEnterpriseInformation SystemLegacy or NewService CodeExternalSystemInternal UsersServiceImplementationSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University11
Three Basic Operations to Support ServiceOriented SystemsService Discovery Services repositories are queried for services with desired characteristics.Service Composition Applications/service consumers are built by integrating functionalityprovided by services.Service Invocation Services are invoked and service code is executed.SOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University12
An Example of SOA Implementation: WS* WebServicesWS* Web Services is onemechanism for implementing aservice-oriented system. UDDI is optionally used asthe directory service.Because it is the most commonmechanism, Web Services isoften equated to SOA.UDDIDescriptionWSDLBaseStackMessage FormatManagementData is transmitted usingSOAP over HTTP.DiscoveryTransactionsService interfaces aredescribed using WebServices DescriptionLanguage (WSDL).Quality of Service WSCL, WSCI, BPEL,WS-CoordinationBPML, BPSSSecurity Orchestration andChoreographySOAPEncodingXMLTransportHTTPAdapted from “XML and Web Services Unleashed”, SAMS PublishingSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University13
So What Is Different?There is nothing conceptually new, but it has brought together existingtechnologies 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-independentoWhat is behind the interface is invisible to the consumerSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University14
So What is the Challenge? Creating GoodServices!Represent reusable tasksHave (or may have) multiple consumersPermit consumers to bind to services programmaticallyCorrespond to functionality of a stateless nature Service has no knowledge of previous visitsEnable service inputs and outputs that do not require the construction ofvery complex consumersAre of a request-response nature Although SOA 2.0 supports eventsSOA: Basic ConceptsVersion 1.7.1 2008 Carnegie Mellon University15
AgendaSOA: Basic ConceptsPillars of Service-Oriented Systems DevelopmentImplications of SOA for Software Life Cycle ActivitiesConclusionsPillarsVersion 1.7.1 2008 Carnegie Mellon University16
Pillars of Service-Oriented Systems DevelopmentSOA-Based echnologyEvaluationChange ofMindsetHigh-level mission andbusiness goals need todictate the focus of thestrategy of SOAadoption andimplementation.SOA governanceprovides a set ofpolicies, rules, andenforcementmechanisms fordeveloping, using, andevolving SOA assetsand for analysis of theirbusiness value.Contextual technologyevaluation allows earlyinsight into technologieswithin the context inwhich they will be used.Development is differentfrom traditional systemsdevelopment—loosecoupling betweenconsumers andproviders, multipleownership, sharedsemantics, etc.SOA Design PrinciplesPillarsVersion 1.7.1 2008 Carnegie Mellon University17
Different Business Needs and Goals DriveDifferent SOA StrategiesBusiness Needs and GoalsSOA StrategyIncrease information available tobusiness customers Integrate business partners Improve business processesIntuitive portalsCreation of services related to customerinformationHeterogeneous interoperabilityBack office integrationIdentification of business rules Identification of key processesElimination of redundancyConsistency between processes Services that access legacy systems Pillars: Strategic AlignmentVersion 1.7.1 2008 Carnegie Mellon University18
Linkage of Business Processes to Services1. Business processes to support business goals are identified.2. Candidate services are identified. Top-Down— Shared steps between business processes are identified asservice candidates.Bottom-Up—Legacy system inventory is performed.—Systems with functionality to support business processes areidentified as migration candidates.3. Services are selected based on relationship to business goals.Pillars: Strategic AlignmentVersion 1.7.1 2008 Carnegie Mellon University19
Disciplined SOA AdoptionIntroductionAddress Specific PainProof of ConceptSingle ApplicationSpreadingProcess IntegrationEstablish TechnologyPlatformMultiple Applications(1BU)ExploitationProcess FlexibilityLeverage ServiceSharingMultiple Applications(Across BUs)PlateauContinuous Adaptationand EvolutionEnterprise SOAInfrastructureVirtual EnterpriseAdapted from “Meeting the Challenges of SOA Adoption,” keynote by Roy Schulte at the SOA In Action Virtual Conference,November 2006.Pillars: Strategic AlignmentVersion 1.7.1 2008 Carnegie Mellon University20
SOA GovernanceSOA governance provides a set of policies, rules, and enforcementmechanisms for developing, using, and evolving SOA assets and foranalysis 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 governancePillars: SOA GovernanceSource: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein& Gary So.Version 1.7.1 2008 Carnegie Mellon University21
Examples of Governance ElementsEngineeringPeopleRoles & ResponsibilitiesService and Process OwnersBusinessFinancialPortfolioService Funding ModelService Usage FeesPlatform FundingProjectsBusiness ServicesApplicationsInformationData OwnershipData StandardsData QualityReference ArchitecturesArchitectural StandardsBlueprints & PatternsTechnologyStrategic SOA PlatformEnforcement Platform DecisionsShared Infrastructure ServicesProjectsService OwnershipService LifecycleShared ArtifactsArchitectureOperationsCapacity PlanningEnforcement Service LevelsEnforcement PoliciesMetrics CollectionOperationsGovernance elements adapted from a presentation by Dr Mohamad Afshar from Oracle Corporation and Ben Moreland from The Hartford at theBusiness Transformation Conference 2007Pillars: SOA GovernanceVersion 1.7.1 2008 Carnegie Mellon University22
Match of Technologies to the ProblemDomainNeed a realistic understanding on what technologies can do in thespecific problem domainHow to understand and keep up with the “alphabet soup”? XML, SOAP, WSDL, UDDI, WS-Security?How to determine which standards and technologies to implement inspecific situations?How to build systems that are resilient to changes in standards andcommercial products that implement them?How to determine if selected technologies will meet QoS requirements? SecurityAvailabilityPerformanceAll the above questions suggest a need for contextual experimentation.Pillars: Technology EvaluationVersion 1.7.1 2008 Carnegie Mellon University23
T-CheckSMExperiment, situated in a specific context,with the goal of providing a “technologysanity check”The approachContextDevelopHypothesesDevelopCriteria1. Formulate hypotheses about the technology2. Examine these hypotheses against veryspecific criteria through experimentationExtremely efficient Focus on implementing the simplestexperiment to validate technology claimsDesign andImplement SolutionEvaluate SolutionAgainst Criteria[Hypotheses Sustained][Hypotheses Refuted]Pillars: Technology EvaluationVersion 1.7.1 2008 Carnegie Mellon University24
Traditional SystemsDevelopmentChange ofMindsetService-Oriented Systems Require a DifferentDevelopment ApproachService-Oriented SystemsDevelopmentTight coupling between systemcomponentsLoose coupling between serviceconsumers and servicesSemantics shared explicitly atdesign timeSemantics shared without muchcommunication between developersof consumers and services—In the future, even at runtimeKnown set of users and usagepatternsPotentially unknown set of users andusage patternsSystem components owned bythe same organizationSystems components potentiallyowned by multiple organizationsPillars: Change of MindsetVersion 1.7.1 2008 Carnegie Mellon University25
AgendaSOA: Basic ConceptsPillars of Service-Oriented Systems DevelopmentImplications of SOA for Software Life Cycle ActivitiesConclusionsSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University26
General Process ImplicationsProcesses must reflect the required strategic approachProcesses must be iterative Short iterations to respond to business needsSOA governance must be embedded across the full life cycle Emphasis on problematic areas Automation where possibleProcesses must be targeted Processes targeted at service provider types: internal services vs. externalservices Processes targeted at system component provider: service, consumer orinfrastructureTechnology evaluation must become an integral process componentSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University27
Some Implications for RequirementsActivitiesRequire an business process management (BPM) focusMust deal with a larger number of stakeholdersFirst step is to look at the inventory of business processesand services Negotiation and adaptation to increase reuse May cause refactoring of services A high quality registry makes the process easierIn the case of service providers, these need to work withpotential requirements In the same way COTS products vendors workSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University28
Some Implications for Architecture andDesign ActivitiesThe responsibilities of each system component need to be clearlydefined—consumers, services and infrastructure Security, transaction management, data transformations, etc.Constant technology evaluationEvaluation of expected quality of service (QoS) Tradeoff analysis Contextual experimentation Implications of external consumers and servicesDecisions must promote reuseSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University29
Some Implications for Development ActivitiesDevelopment environments need to be similar/same asproduction environments—as in any distributed systemenvironment In some cases, the simulation of the productionenvironment might be necessaryThe emergent characteristics of many SOA technologiescause instability in development activitiesRequire the establishment of processes for theimplementation of service interfaces and infrastructurecomponents Traditional processes apply to service implementationSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University30
Some Implications for Testing ActivitiesSystem testing of a service consumer requires all services (or testinstances of them) to be available From a service consumer perspective, the service is a black boxRequires 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 andservice-level agreements (SLAs)SOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University31
Some Implications for Maintenance ActivitiesImpact analysis affects a larger number of users Internal and external users Service users and users of the systems that implement the servicesConfiguration 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/consumersSOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University32
Less ControlRequires giving up full control—not easy Tradeoff is agilityAnticipate objections and understand validity Security Performance ControlGreatest challenges come from Single organization may not own the complete system Services used in unknown ways by (potentially) unknown usersEducation and training on new mindset is needed.SOA and the Software Life CycleVersion 1.7.1 2008 Carnegie Mellon University33
AgendaSOA: Basic ConceptsPillars of Service-Oriented Systems DevelopmentImplications of SOA for Software Life Cycle ActivitiesConclusionsConclusionsVersion 1.7.1 2008 Carnegie Mellon University34
Conclusions 1SOA is an approach to software development where Services provide reusable functionality with well-defined interfaces. An SOA infrastructure enables discovery, composition, and invocation ofservices. 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 processimprovement Main adoption barriers are lack of governance and finding people with theright skillsConclusionsVersion 1.7.1 2008 Carnegie Mellon University35
Conclusions 2SOA is not just a buzzword Currently the best option available for loosely coupled systems integrationand leverage of legacy systems The technologies to implement SOA will change over time, but the conceptsare here to stay—SOA is much broader than its most popular instantiation (WebServices)Development of service-oriented systems is about more than justtechnologies 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 valueConclusionsVersion 1.7.1 2008 Carnegie Mellon University36
2008-2009 Course Dates for Migrating LegacyComponents to SOA EnvironmentsOctober 15-16January 28-29April 16-17July 29-30September 10-11October 28-292008SEI DC2009SEI PittsburghSEI PittsburghSEI DCSEI EuropeSEI PittsburghCourse DatesVersion 1.7.1 2008 Carnegie Mellon University37
ReferencesSMART: The Service Migration and Reuse Technique SMART: Analyzing the Reuse Potential of Legacy Components in a Service-OrientedArchitecture cuments/08.reports/08tn008.htmlT-Checks Process: eports/05tn025.htmlApplications:— Web Services and Security: Single nts/08.reports/08tn026.html— Open Grid Services ocuments/07.reports/07tn016.html— Web ents/06.reports/06tn021.html— OWL-S (OWL Web Ontology Language for ments/06.reports/06tn018.html— MDA (Model-Driven documents/05.reports/05tn022.htmlReferencesVersion 1.7.1 2008 Carnegie Mellon University38
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-Bernstei
