Principles of Service Oriented Architecture

Principles of Service Oriented Architecture

اسلاید 1: © 2008 Intergraph CorporationPrinciples of Service Oriented ArchitectureMark BaileySenior System ConsultantSecurity, Government, & Infrastructuremark.bailey@intergraph.com

اسلاید 2: AgendaMotivation for Service Oriented Architecture (SOA)SOA DefinedSOA PrinciplesApplying SOA

اسلاید 3: Current Environment

اسلاید 4: Application Centric

اسلاید 5: Application CentricFinanceDistributionManufacturingSupplyNarrow Consumers Limited Business ProcessesOverlapped resources Overlapped providersBusiness scopeIntegrationArchitectureBusiness functionality is duplicated in each application that requires it.EAI ‘leverage’ application silos with the drawback of data and function redundancy. bound to EAI vendorRedundancy

اسلاید 6: Goal - Service Centric

اسلاید 7: Service ArchitectureServiceServiceServiceServiceFinanceDistributionManufacturingSupplyService virtualizes how that capability is performed, and where and by whom the resources are provided, enabling multiple providers and consumers to participate together in shared business activities.Multiple Service Consumers Multiple Business ProcessesMultiple Discrete Resources Multiple Service Providerssource:TietoEnator AB, Kurts BilderBusiness scopeSOA structures the business and its systems as a set of capabilities that are offeredas Services, organized into a Service ArchitectureSharedServicesService Centric

اسلاید 8: Before SOA – After SOAsource:IBM

اسلاید 9: Why SOA? To enable Flexible, Federated Business Processes Enabling a virtual federation of participants to collaborate in anend-to-end business processEnabling alternative implementationsEnabling reuse of ServicesEnabling virtualization of business resources Enabling aggregation from multiple providersIdentificationTicket SalesTicket CollectionInventoryLogisticsManufacturingAvailabilityServiceServiceServiceServiceServiceServiceServiceServiceServiceServiceOrderingsource:TietoEnator AB, Kurts Bilder

اسلاید 10: Why SOA? To enable Business Process Optimization and the Real Time Enterprise (RTE)Seamless End to End ProcessInternal SystemsSOA Pattern: Standardized Service provided by multiple suppliersService from Multiple SuppliersSOA Patterns: Single, Multi-Channel Service for consistencyBPM Expressed in terms of Services Provided/ConsumedEnterprisesource:TietoEnator AB, Kurts BilderSmart ClientsStores POSMobile3rd Party AgentsPortalService to Customers

اسلاید 11: Why SOA? Enable Structural ImprovementERP XProcess ZPartner AProcess YServiceStandardizing capabilitiesInformation ConsistencyPolicy Consistencye.g. Single Customer Details ServiceConsolidation/ Selection processReducing impact of changeEncapsulating implementation complexityERP ZCRM System 2CRM System 1Product SystemPolicy Rationalization and EvolutionResource Virtualizatione.g. Multiple Sources of Customer Details

اسلاید 12: SOA DefinedSOA is a software architecture model in which business functionality are logically grouped and encapsulated into self contained,distinct and reusable units called services thatrepresent 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 functionality Services are autonomous, discrete and reusable units of business functionality exposing its capabilities in a form of contracts. Services can be independently evolved, moved, scaled even in runtime.

اسلاید 13: What is Service Architecture?A collection of servicesclassified into typesarranged into layersGoverned by architectural patterns and policiesservicesidentificationgranularitydependencytypetypetypesource:TietoEnator AB, Kurts Bilder

اسلاید 14: Big (outer) vs. Little (inner) SOA

اسلاید 15: SOA is an evolutionary stepfor architecture

اسلاید 16: SOA is an evolutionary stepin reusability and communication

اسلاید 17: SOA is an evolutionary stepProject-wareSOAEAIin distributed communicationssource:Sam Gentile

اسلاید 18: Service Architecture Organized by LayersReasons for LayeringFlexible composition. Reuse. Functional standardization in lower levelsCustomization in higher layersSeparation of Concerns. Policies may vary by LayerExample LayersPresentation & workflowComposed ServicesBasic ServicesUnderlying APIaccording to:TietoEnator AB, Kurts Bilder

اسلاید 19: Major service typesBasic Services: Data-centric and logic-centric services Encapsulate data behavior and data model and ensures data consistency (only on one backend). Basic services are stateless services with high degree of reusability.Represent fundamental SOA maturity level and usually are build on top existing legacy API (underlying services) Composed Services : expose harmonized access to inconsistent basic services technology (gateways, adapters, façades, and functionality-adding services). Encapsulate business specific workflows or orchestrated services.

اسلاید 20: Service Types

اسلاید 21: SOA PrinciplesStandardized Service ContractsLoose CouplingAbstractionReusabilityAutonomyStatelessnessDiscoverabilityComposability

اسلاید 22: Standardized Service Contracts“Services within the same service inventory are in compliance with the same contract design standards. Services use service contract toExpress their purposeExpress their capabilitiesUse formal, standardized service contractsFocus on the areas of Functional expressionData representationPolicySource: Thomas Erl

اسلاید 23: Loose Coupling“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment. Create specific types of relationships within and outside of service boundaries with a constant emphasis on reducing (“loosening”) dependencies betweenService contractService implementationService consumersSource: Thomas Erl

اسلاید 24: Abstraction“Service contracts only contain essential information and information about services is limited to what is published in service contracts”Avoid the proliferation of unnecessary service information, meta-data.Hide as much of the underlying details of a service as possible.Enables and preserves the loosely coupled relationshipsPlays a significant role in the positioning and design of service compositionsSource: Thomas Erl

اسلاید 25: Reusability“Services contain and express agnostic logic and can be positioned as reusable enterprise resources. Reusable services have the following characteristics:Defined by an agnostic functional contextLogic is highly genericHas a generic and extensible contractCan be accessed concurrentlySource: Thomas Erl

اسلاید 26: AutonomyServices exercise a high level of control over their underlying runtime execution environment. Represents the ability of a service to carry out its logic independently of outside influencesTo achieve this, services must be more isolatedPrimary benefitsIncreased reliabilityBehavioral predictabilitySource: Thomas Erl

اسلاید 27: StatelessnessServices minimize resource consumption by deferring the management of state information when necessary. Incorporate state management deferral extensions within a service designGoalsIncrease service scalabilitySupport design of agnostic logic and improve service reuseSource: Thomas Erl

اسلاید 28: DiscoverabilityServices are supplemented with communicative meta data by which they can be effectively discovered and interpreted. Service contracts contain appropriate meta data for discovery which also communicates purpose and capabilities to humansStore meta data in a service registry or profile documentsSource: Thomas Erl

اسلاید 29: ComposabilityServices are effective composition participants, regardless of the size and complexity of the composition. Ensures services are able to participate in multiple compositions to solve multiple larger problemsRelated to Reusability principleService execution should efficient in that individual processing should be highly tunedFlexible service contracts to allow different types of data exchange requirements for similar functionsSource: Thomas Erl

اسلاید 30: Applying SOA - GovernanceGoal: Establish SOA organization governance (SOA Board) that governs SOA efforts and breaks down capabilities into non-overlapping servicesGovernance is a program that makes sure people do what is ‘right’In conjunction with software, governance controls the development and operation of software

اسلاید 31: Applying SOA - GovernancePolicies Codification of laws, regulations, corporate guidelines and best practicesMust address all stages of the service lifecycle (technology selection, design, development practices, configuration management, release management, runtime management, etc.)ProcessesEnforce policiesSystem-driven processes (code check-in, code builds, unit tests)Human-driven process (requests, design reviews, code reviews, threat assessment, test case review, release engineering, service registration, etc.)MetricsMeasurements of service reuse, compliancy with policy, etc.OrganizationGovernance program should be run by SOA Board, which should have cross-functional representatives

اسلاید 32: Applying SOA – Governance

اسلاید 33: Business functionality has to be made available as services. Service contracts must be fixedImplemented services must be designed with reuse in mind. This creates some overhead.Potential service users must be involved in the design process and will have influence on the service design Applying SOA - ChallengesService OrientationReuseSharing of ResponsibilitiesIncreased complexity!

اسلاید 34: (Source: Enterprise SOA: Service Oriented Architecture Best Practices by Dirk Krafzig, Karl Banke, and Dirk Slama, Prentice Hall 2004)Applying SOA – Renovation Roadmap

اسلاید 35: Conclusion and SummaryIf done correct, SOA is “not just another architectural fad”SOA seeks to bridge the gap between business and technology promoting business agility (its all about managing change)SOAIs complexRequires governanceRequires executive management buy-inRequires commitment with resources (people and $$)

اسلاید 36: © 2008 Intergraph CorporationPrinciples of Service Oriented ArchitectureMark BaileySenior System ConsultantSecurity, Government, & Infrastructuremark.bailey@intergraph.com