Transcription
Service OrientedArchitectureNuman SheikhAssistant ProfessorGIFT University1
DefinitionSERVICEWhat is a Service ?–––––––Lego block. Building BlockHas standard based interfaceLoosely coupledPlatform independentComposableDiscoverableVertical slicing2
What is a Service? A service is a reusable component that can beused as a building block to form larger, morecomplex business-application functionality. A service provides a discrete business functionthat operates on data. A service may be as simple asget me some person data,or as complex asprocess a disbursement.What is a Service? Its job is to ensure that the businessfunctionality is applied consistently, returnspredictable results, and operates within thequality of service required. From a theory point of view, it really doesn’tmatter how a service is implemented.3
What is a Service? Stateless– The service does not maintain state betweeninvocations. It takes the parameters provided,performs the defined function, and returns theexpected result. If a transaction is involved, thetransaction is committed and the data is saved tothe database.What is a Service? Only the service knows how it is implemented A requestor only knows– what the service is and– how to request it The consumer of the service is required to provide only thestated data on the interface definition, and to expect onlythe specified results on the interface definition. The service is capable of handling all processing (includingexception processing).4
Service Oriented ArchitectureDEFINITIONService Oriented Architecture There are three concepts that can be used by SOA– Architectural Concept– Business Solution Styles– Supporting Infrastructure/Environment5
What is SOA? SOA is Legoware. Made of Lego BlocksWhat is SOA? SOA is an architecture that a software system is divide into high flexibleand re-usable component unit called service and compose withinterconnection of these services. Applications built using an SOA style deliver functionality as services thatcan be used or reused when building applications or integrating within theenterprise or trading partners. The general concept of service in SOA is that service is a major unit ofsoftware component with business sense. These services have lowdependency and each can be implemented without platform dependencywhile the interfaces that the service provides must be standardized .6
SOA is NOT– Technical standard– A technologyIt is– Just architecture blue printArchitecture Architecture implies a consistent and coherent design approach.Essential principles include:– Consistency: The same challenges should be addressed in a uniformway.– Reliability: The structures created must be fit to purpose and meet thedemands for which they are designed.– Extensibility: A design must provide a framework that can beexpanded in ways both foreseen and unforeseen.– Scalability: The implementation must be capable of being scaled toaccommodate increasing load by adding hardware to the solution.7
Service Oriented Architecture:Architectural Concept Stateless Loose coupling between a– service (a stateless, self-contained business function)and its– provider (the physical assets that perform thefunction)Service Oriented Architecture:Architectural Concept Only the service knows how it is implemented A requestor only knows– what the service is and– how to request it The consumer of the service is required to provide only thestated data on the interface definition, and to expect onlythe specified results on the interface definition. The service is capable of handling all processing (includingexception processing).8
Service Oriented Architecture:Business Solution Styles Composite Application Development– User interaction drives the request for one or moreservices– Requests are usually synchronous in nature– Delivered via portal Flow Development– Business Process-Driven Architecture Workflow: a series of activities/functions completes a business transaction orprocess Typically long-running/asynchronous– Event-Driven An inside or outside event triggers other interested applicationsService Oriented Architecture:Infrastructure / Environment An SOA environment allows services to bedefined, developed and used by other services These services can be assembled into solutionsthrough business rules, interaction mechanismsand user interfaces Enables service discovery, policy definition andenforcement, quality of service, transactionmanagement, audit and usage metering9
Service Oriented ArchitectureWHY?Current Environment10
Application CentricCurrent EnvironmentBusiness scopeNarrow ConsumersLimited Business ProcessesFinanceApplicationApplicationbound toEAI ndancyDistributionManufacturingOverlapped resourcesOverlapped providersBusiness functionality isduplicated in eachapplication that requires it.Service CentricEAI ‘leverage’ application silos withthe drawback of data and functionredundancy.GoalBusiness scopeMultiple Service ConsumersMultiple Business ProcessesFinanceServiceServiceSupplyService ingDistributionMultiple Discrete ResourcesMultiple Service ProvidersSOA structures the business and its systemsas a set of capabilities that are offeredas Services, organized into a ServiceArchitectureService virtualizes how that capability isperformed, and where and by whom theresources are provided, enabling multipleproviders and consumers to participatetogether in shared business activities.source:TietoEnator AB,Kurts Bilder11
Before SOA – After SOAsource:IBMWhy SOA?To enable Flexible, Federated Business ProcessesEnabling a virtual federation ofparticipants to collaborate in anend-to-end business processEnabling alternativeimplementationsEnabling reuse ofServicesServiceIdentificationServiceTicket CollectionServiceOrderingTicket eServiceServiceServiceManufacturingEnabling virtualization of business resourcesAvailabilityEnabling aggregation from multipleproviderssource:TietoEnator AB,Kurts Bilder12
Why SOA? To enable Business Process Optimizationand the Real Time Enterprise (RTE)BPM Expressed interms of ServicesProvided/ConsumedSeamless End to End ProcessService to CustomersEnterpriseService from Multiple SuppliersSmart ClientsStores POSMobile3rd Party AgentsPortalInternal Systemssource:TietoEnator AB,Kurts BilderSOA Patterns: Single, Multi-ChannelService for consistencySOA Pattern: Standardized Serviceprovided by multiple suppliersWhy SOA?Enable Structural ImprovementProcess ZERP XStandardizing capabilitiese.g. Single CustomerDetails ServiceReducing impactof changeERP ZPartner AInformation ConsistencyPolicy MSystem 2Process YEncapsulatingimplementationcomplexityCRMSystem 1ProductSysteme.g. Multiple Sourcesof Customer DetailsPolicy Rationalization and EvolutionResource Virtualization13
Why Loose Coupling? A loosely-coupled architecture is seen as helping toreduce overall complexity and dependenciesSOA Defined SOA is a software architecture model– in which business functionality are logicallygrouped and encapsulated into self contained, distinct and reusable unitscalled services that represent a high level business concept can be distributed over a network can be reused to create new business applications contain contract with specification of the purpose, functionality,interfaces (coarse grained), constraints, usage» . of the business functionalityServices are autonomous, discrete and reusable units of business functionalityexposing its capabilities in a form of contracts.Services can be independently evolved, moved, scaled even in runtime.14
What is Service Architecture? A collection of services classified into types arranged into layers Governed by architecturalpatterns and policiesservicestypetypetypesource:TietoEnator AB,Kurts BilderBig (outer) vs. Little (inner) SOA15
SOA is an evolutionary stepfor architectureSOA is an evolutionary stepin reusability and communication16
SOA is an evolutionary stepin distributed communicationsEAIProject-wareSOAsource:Sam GentileService Architecture Organized byLayersReasons for Layering1. Flexible composition.2. Reuse.3. Functional standardization inlower levels4. Customization in higher layers5. Separation of Concerns.6. Policies may vary by LayerExample LayersPresentation& workflowComposed ServicesBasic ServicesUnderlyingAPIaccording to:TietoEnatorAB, Kurts Bilder17
Major service types Basic Services:– Data-centric and logic-centric services– Encapsulate data behavior and data model and ensures dataconsistency (only on one backend).– Basic services are stateless services with high degree ofreusability.– Represent fundamental SOA maturity level and usually are buildon top existing legacy API (underlying services) Composed Services :– expose harmonized access to inconsistent basic servicestechnology (gateways, adapters, façades, and functionalityadding services).– Encapsulate business specific workflows or orchestratedservices.Service TypesSOA Management & Securityservice mediation, routing, trustenablement. ESB, Service RegistryMulti channel applications: Mobile,Smart, Thin, Thick clients, Portals.In Sfra erst vi cru ectureBusiness centric services,orchestrated workflows.Intermediate services (gateways,facades )Data centric and logiccentric consistent services.Highly reusable, statelessserversFoundationService BlocksCore APIsBusinessCapabilitiesI/.InServicee OthrG/Te chI/CADeoG diaeMrraTe reaSh18
SOA Principles Standardized Service ContractsLoose sDiscoverabilityComposabilityStandardized Service Contracts “Services within the sameservice inventory are incompliance with the samecontract design standards." Services use servicecontract to– Express their purpose– Express their capabilities Use formal, standardizedservice contracts Focus on the areas of– Functional expression– Data representation– PolicySource: Thomas Erl19
Loose Coupling “Service contracts impose lowconsumer couplingrequirements and arethemselves decoupled fromtheir surroundingenvironment." Create specific types ofrelationships within andoutside of service boundarieswith a constant emphasis onreducing (“loosening”)dependencies between– Service contract– Service implementation– Service consumersSource: Thomas ErlAbstraction “Service contracts only contain essential informationand information about services is limited to what ispublished in service contracts” Avoid the proliferation of unnecessary serviceinformation, meta-data. Hide as much of the underlying details of a service aspossible.– Enables and preserves the loosely coupled relationships– Plays a significant role in the positioning and design ofservice compositionsSource: Thomas Erl20
Reusability “Services contain and express agnostic logicand can be positioned as reusable enterpriseresources." Reusable services have the followingcharacteristics:– Defined by an agnostic functional context– Logic is highly generic– Has a generic and extensible contract– Can be accessed concurrentlySource: Thomas ErlAutonomy "Services exercise a high level of control over theirunderlying runtime execution environment." Represents the ability of a service to carry out itslogic independently of outside influences To achieve this, services must be more isolated Primary benefits– Increased reliability– Behavioral predictabilitySource: Thomas Erl21
Statelessness "Services minimize resource consumption by deferringthe management of state information when necessary." Incorporate state management deferral extensionswithin a service design Goals– Increase service scalability– Support design of agnostic logic and improve service reuseSource: Thomas ErlDiscoverability "Services are supplementedwith communicative metadata by which they can beeffectively discovered andinterpreted." Service contracts containappropriate meta data fordiscovery which alsocommunicates purpose andcapabilities to humans Store meta data in a serviceregistry or profiledocumentsSource: Thomas Erl22
Composability "Services are effectivecomposition participants,regardless of the size andcomplexity of the composition." Ensures services are able toparticipate in multiplecompositions to solve multiplelarger problems Related to Reusability principle Service execution shouldefficient in that individualprocessing should be highlytuned Flexible service contracts toallow different types of dataexchange requirements forsimilar functionsSource: Thomas ErlSOA – Best Practices Encapsulate what Varies– A service that can change over time, or that could be ‘ripped andreplaced,’ should have an interface defined that remains constant Program to Interfaces, not Implementations– Services should provide interfaces that other services can call, ratherthan make direct calls to underlying component APIs. For example, it isbetter to make calls to a JMS implementation rather than direct MOMAPI requests. Depend on Abstractions, not Concrete Services– Create a StockQuote interface that includes generic fields required fora stock quote. Don’t allow your service to make direct calls to anexternal vendor like XMethods.23
SOA – Best Practices Strive for Loosely-Coupled Designs Between Servicesthat Interact– Today’s enterprise service provided by SAP could beprovided by Oracle tomorrow.– Define what is needed for billing information in aninterface, and maintain the interface, even if theimplementation changes behind it. Services should be Open for Extension, but Closed forModification– Look at adding functionality to a service through externalmeans, rather than constantly changing the inner code.SOA – Best Practices Favor Composition over Inheritance– Instead of changing an existing service, create a façadeinterface that calls multiple low-level services Principle of Least Knowledge (Talk Only to YourImmediate Friends)– When you design a service, limit the number of low-levelservices it interacts with, and the type of data sent tothese services.– Limit the coupling of overall systems.– When dealing with sensitive information, pass only thedata the other system needs, don’t just send all of thestate fields if the other system won’t use them.24
Applying SOA - Governance Governance is a programthat makes sure people dowhat is ‘right’ In conjunction withsoftware, governancecontrols the developmentand operation of software– Goal: Establish SOA organizationgovernance (SOA Board) that governsSOA efforts and breaks downcapabilities into non-overlappingservicesApplying SOA - Governance Policies– Codification of laws, regulations, corporate guidelines and best practices– Must address all stages of the service lifecycle (technology selection, design, developmentpractices, configuration management, release management, runtime management, etc.) Processes– Enforce policies– System-driven processes (code check-in, code builds, unit tests)– Human-driven process (requests, design reviews, code reviews, threat assessment, test casereview, release engineering, service registration, etc.) Metrics– Measurements of service reuse, compliancy with policy, etc.– Organization– Governance program should be run by SOA Board, which should have cross-functionalrepresentatives25
FoundationService BlocksApplying SOA –GovernanceCore APIsBusinessCapabilitiesI/.ere OthtechnicalviewInServicG/Te chI/CADeoG diaeMrraTe reaShsesservsi ceServiceDesignersBusiness e specificationmodelService implementationand deploymentmodelylic dsPo d a rsanSt d e lMo rnstePa tsi nBuSoftware and ITArchitectsApplying SOA - Challenges Business functionality has to be made available asservices. Service contracts must be fixedService OrientationImplemented services must be designed with reuse inReusemind. This creates some overhead.Sharing of ResponsibilitiesPotential service users must be involved in the designprocess and will have influence on the service designIncreased complexity!26
Applying SOA – Renovation Roadmap(Source: Enterprise SOA: Service Oriented Architecture Best Practicesby Dirk Krafzig, Karl Banke, and Dirk Slama, Prentice Hall 2004)Conclusion and Summary If done correct, SOA is “not just anotherarchitectural fad” SOA seeks to bridge the gap between businessand technology promoting business agility (its allabout managing change) SOA––––Is complexRequires governanceRequires executive management buy-inRequires commitment with resources (people and )27
8 Service Oriented Architecture: Architectural Concept Stateless Loose coupling between a –service (a stateless, self-contained business function) and its –provider (the physical assets that perform the function) Service Oriented Architecture: Architectural Concept Only the service knows how it
