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.

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