SOA Service Implementation Architecture And Automation Unit Specification

3,133 views

Published on

The Service Implementation Architecture and Automation Units Specifications provide the transition from the logical Business Service Architecture and Service Specifications to the implementation of Services in software. This presentation provides an overview of how in the CBDI-SAE approach Automation Units are identified, modeled and specified, and advise on how they are documented in the Service Implementation Architecture.

Published in: Technology, Business

SOA Service Implementation Architecture And Automation Unit Specification

  1. 1. Sales Process Service www.cbdiforum.com «Business Process Orchestration» Sales Process Orders Customers Service Service «component» Sales Component Products Service SOA Best Practice «aggregator» Products Address Service «component» Service Address Service Manufacturing Inventory Service Implementation System Service System Service «wrapper» «wrapper» Architecture and Automation Manufacturing Inventory System System Unit Specification By Lawrence Wilkes Independent Guidance for Service Architecture and Engineering
  2. 2. Introduction  This presentation provides an overview of our approach to modeling the Service Implementation Architecture and identifying and specifying Automation Units.....  Further detail and guidance (e.g. Specific techniques) is provided in the CBDI Journal report and the CBDI-SAE Knowledgebase  In addition, the Knowledgebase contains the following resources  Automation Unit Description Template  Automation Unit Specification Template  Detailed Process, Task, Technique and Artifact guidance  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  3. 3. SO Process Context <<discipline>> <<discipline>> <<discipline>> Service Oriented Service Service Architecture Provisioning Implementation & Design <<process unit>> Evolve Service Portfolio Plan <<process unit>> <<process unit>> <<process unit>> <<process unit>> Produce Service Produce Service Produce Service Produce Automation Specification Implementation Specification Unit Specification Architecture Architecture <<deliverable>> <<deliverable>> Service Service Specification Specification Architecture <<deliverable>> Service <<deliverable>> Implementation Automation Unit Architecture Specification <<deliverable>> From a process perspective, the Service Implementation <<deliverable>> Software Architecture is a deliverable from the Service Oriented Internal Architecture Executables Architecture and Design discipline, and the Automation Unit Specification is a deliverable from Service Provisioning. Together with the Service Specification, these will be key inputs to the Service Implementation activity.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  4. 4. SO Process Context Service Oriented Service Provisioning Service Implementation Architecture & Design Key Service Automation Unit Internal Architecture Deliverable Implementation Specification Architecture Scope Overall Structure of Individual Automation Individual Automation Unit Automation Units Unit Level Logical Architecture Logical Specification Platform specific software design. Technical Interface & Component structure Mapping Mapping of logical Mapping of logical Mapping Service Operations Services to logical Service operations to to Technical Realizations (e.g. Automation Units logical Automation Units the Technical Operations) Dependency Service-level Service Operation-level Technical Operation dependency dependency dependency Non-Service Non-Service dependencies dependencies The Service Implementation Architecture defines the overall logical structure of Automation Units and the Services they provide and require, whilst the Automation Unit specification is a logical specification of an individual Automation Unit. Finally, the internal architecture details the platform specific design of an Individual Automation Unit.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  5. 5. Example Automation Unit Types – Implementation Patterns Automation Unit Description Types «Component» An encapsulated component, whose logic and data can only be accessed via the service's operations. «Quasi-Component» Not fully encapsulated, but it still amounts to a single "logical" deployment unit not fitting into any of the other stereotype categories «Script» Automation Units using an interpreted script rather than a compiled language can be highlighted with a special stereotype. You could treat BPEL as a script, or you may prefer to use the more specific stereotype «BPEL» «External» Where a service is supplied by an external vendor who also hosts the service, and there is no knowledge of how the service is implemented, then a notional Automation Unit can be included in the Architecture. «Package» Where an Automation Unit is supplied by an external vendor, and there is no knowledge of how the service is implemented, then a notional Automation Unit can be included in the Architecture. What is an Automation Unit? An Automation Unit describes the implementation of one or more Services. It consists of a collection of Deployable Artifacts, such as the executables or scripts that together provide the implementation for a service. It is a logical construct that enables the service architecture to map between the high- level service specification architecture and the physical implementation of the services.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  6. 6. Example Automation Unit Types – Design Patterns Automation Unit Description Types «Facade» or Aggregate data from several services «Aggregator» «Wrapper» Provide access to some functionality within an existing system, making it available to SOA consumers as a service. A wrapper would mainly call the legacy system's API -- or its methods or transactions or whatever -- and convert them into operations of services (as documented in a Service Specification). «Broker» or «Router» The Automation Unit acts as a broker or router switching requests to one of several alternative implementations based on business rules. Rather than use a term like Component, for which some readers will assume a specific meaning, we use Automation Unit as a more general term that covers the many different ways in which the Service might be implemented. The table on this and the previous slide shows two properties that can be used to label an Automation Unit. The Implementation Pattern shows how the Automation Unit is physically implemented, whilst the Design Pattern shows the general function of the Automation Unit.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  7. 7. Automation Unit Patterns - Mapping Services to Automation Units Several Services, One AU, One Service, One AU, One Component One Component Orders Customers Orders Customers Service Service Service Service «component» «component» «component» Orders Customers Sales Service Service Component Many services, One AU, Unknown Components Orders Customers Inventory Payments Service Service Service Service «package» Ecommerce System The key task of the architect is to decide how the Service Specification Architecture will be mapped to different units of software that will implement each service. In its simplest form, each Service is realized in the Service Implementation Architecture by a single Automation Unit, and that Automation Unit is implemented by a single component. However, when identifying Automation Units, architects may decide to build or acquire one software component that offers several services, where those services have high affinity. Though this might impact flexibility, implementation concerns may outweigh that.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  8. 8. Automation Unit as a Unit of Integrity n Services, n Components, One AU Orders Customers Service Service «automationUnit» Sales «component» «component» Unit of Integrity Aka Component Orders Customers Service Service Cluster AKA Quasi- Sales component Database «legacy» Breaks the Integrity Order Management System Other factors may affect mapping decisions. For example: To better manage deployment, versioning, testing or security, architects may decide to cluster Automation Units into single “unit of integrity” and not publish the Services which only have dependencies within that unit.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  9. 9. Service Implementation Architecture Concepts in UML and SoaML Concept UML SoaML Automation are represented by UML UML classes or Components Units classes Stereotypes are stereotyped as Participants. used to indicate the type of Automation unit Associations UML associations UML associations are stereotyped as ServiceChannels Services UML interface icon UML Ports, stereotyped as ServicePoints provided and typed by ServiceInterfaces. These are the small blue boxes in the diagram. Services UML „socket‟ icon stereotyped as a RequestPoint, and required typed by the ServiceInterface of the Service required or a “compatible” ServiceInterface the small red box on the Participant. The Service Implementation Architecture is a model that describes the Automation Units used to implement services, and their inter-dependencies. This can be modeled using UML or SoaML. The CBDI-SAE UML Profile provides the necessary stereotypes to model the Service Implementation Architecture. Various SoaML profiles are also available for download, including one that CBDI has built for Sparx Systems Enterprise Architect.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  10. 10. Modeling the Service Implementation Architecture ServicePoints UML Interface :Orders Service Orders «Participant» Service Orders Service Stereotyped UML «component» Class Stereotyped UML Orders Service Class :Products Service UML socket RequestPoints <<ServiceChannel>> Products Service :Products Service ServiceChannels «Participant» «component» Products Service Products Service UML SoaML  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  11. 11. Service Implementation Architecture Example Sales Process Service Note that in this example the integrity of the Service Specification Architecture is maintained. Though the Orders «Business Process Service and Customers Service are both provided by the same Orchestration» Automation Unit in the form of the Sales Component, the Sales Process individual Services and their dependencies in the Service Specification Architecture still remain. Orders Customers Service Service Service Specification Architecture «component» Process Sales Process Service Services Sales Component Orders Service Customers Products Core Service Service Address Business Products Services «aggregator» Service Service Products «component» Address Service Utility Service Address Services Service Manufacturing Inventory Manufacturing Inventory System Service System Service Underlying Systems Service Systems Service Services «wrapper» «wrapper» The Service Implementation Architecture is based Manufacturing Inventory on the Service Specification Architecture, but also System System takes into account any constraints  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  12. 12. Adding Further Implementation Detail Several components, one data storage service Customers Sometimes the opposite will occur, in Orders Service Service that additional Services are added to the Service Implementation Architecture that are not modeled in the Service «component» «component» Specification Architecture. For example Customers it may be decided that Orders Service Orders Service Service and Customers Service components should both use a Sales Database Component which itself provides a « implementation only » Sales Data Sales Data Service. The Sales Data Service Service would not normally be added to the Service Specification Architecture «component» as it is considered an implementation- Sales Database only dependency, and in this example the dependency has been labelled as such.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  13. 13. Adding Further Implementation Detail Application «application» Wrapper eCommerce System Orders Service Automation Units can also be used to depict any distinct collection of software, such as an existing system, even if it does not directly offer services. «wrapper» This shows an example of an existing Order Order Processing System that is behind a wrapper used System to implement the Orders Service. Finally, an Automation Unit can also be used to represent the solution or application that consumes <<existingsystem>> Services. In this case the eCommerce System. Order Processing System Orders File  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  14. 14. Modeling the Internal Architecture Using Service Component Architecture (SCA) An alternative notation that has Properties been developed specifically with SOA in mind is Service Component Architecture (SCA) Service Sales Composite Products Orders component X Service A Service Orders Y component Address C Sales Q Service Database Customers component Reference B Z Service Customers Component Composite <composite name=“SalesComposite" ...> <component name=“Orders"> ... </component> <service name=“OrdersService” promote=“Orders/A” <binding.ws/> <service/> <reference name=“ProductsService” promote=“Orders/X”/> </composite> A benefit of SCA is that it enables the architecture to be documented in XML  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  15. 15. Automation Unit Lifecycle Like any other artifact, the Automation Unit also has a life cycle State Deliverables Comments Planned Service Implementation Essentially a to-be Architecture AU Description Specified AU Specification Requirement – ideal specification Actual – Delivered specification Designed AU Internal Architecture Include any design constraints, e.g must use Technical Interface Provisioned AU Implementation External provisioning decisions may (Software Executables, etc) pre-determine Automation Unit packaging As -delivered Retired AU Implementation Retirement of the AU is not necessarily (Software Executables, etc) in line with the life cycle of the Service  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  16. 16. Specifying Implementation Detail Automation Unit Internal Architecture Specification Orders Customers Orders Customers Service Service Service Service «component» <<component>> Sales Sales Component Component «component» «component» Products Address Service Orders Customers Service Service Service Rather than overloading the Service Implementation Architecture diagram with the Sales internal architecture of each Automation Unit, it DataService may be decided to document these individually as «component» the internal architecture of an individual Automation Unit. Whereas a single box Sales representing the Sales Component may be Database sufficient in the Service Implementation Architecture, the internal architecture can be modeled elsewhere to show the Automation Units Products Address and Services within it. Service Service  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  17. 17. Policies  We would expect organizations to define policies that more tightly scope the permitted Automation Unit types that can be used in their organization and the associated documentation they require. Policies should cover  Permitted types of implementation and design patterns  Documentation requirement by type  Documentation requirement by provisioner/implementer relationship. That is  Internal implementation  Acquired implementation  Outsourced/Offshored Implementation  Modeling and specification standards  Mapping and Packaging policies  Permitted Service to Automation Unit packaging patterns  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  18. 18. Links and Resources  CBDI-SAE UML Profile for SOA  http://www.cbdiforum.com/public/uml_profile.php  CBDI SoaML UML Profile  http://cbdi.wikispaces.com/SoaML  Automation Unit Specification  http://cbdi.wikispaces.com/Automation+Unit+Specification  Service Implementation Architecture  http://cbdi.wikispaces.com/Service+Implementation+Architecture  Original CBDI Journal Report  http://www.cbdiforum.com/secure/interact/2009- 06/servic_implementation_architecture_and_automation_unit_spe cification.php  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  19. 19. www.cbdiforum.com Independent Guidance for Service Architecture and Engineering www.everware-cbdi.com  2009 Everware-CBDI Inc This material may not be copied or reused without express permission

×