UniZH HS2012 HPH2 SOA 21 09 2012

Dr.
Hans-Peter Hoidn
Executive Architect, IBM
Distinguished IT Architect (Opengroup)
Enterprise IT Architectures
SOA (Service Oriented Architecture)
2012 IBM Corporation
SOA Introduction
Agenda of this Session

Last Session:
Introduction of BPM (Business Process Management)
Focus on Capturing processes and automated execution
This Session
BPM needs to be augmented by integration to applications,
components, services, data bases etc.
SOA provides the mechanisms to do integration (Integration
Platform) such that both sides of an integration are independent
Methodology to structure distributed applications including
business processes as well as user interfaces
Positioning of SOA
Finance
& Ops
Invoice
Reconciliation
Teams
Customer
Service
BPM
Executive
Management
Account
Administration
Now focusing
on the Integration
Platform
SOA
Systems
What is SOA
SOA is an architectural style or approach whose goal is to achieve loose
coupling among interacting software agents
All functions (that need to be used by more than one system) are defined as
"services
Service providers agree to a defined, implementation-independent interface
with service clients
Services oriented architecture is the policies, practices and frameworks
that enable application functionality and IT services to be
provided and requested as a set of services
using a standards based form of interface.
Service Oriented Architecture

Moves IT Logic Out of Services
Information
Factory
Customers
Web Orders
Inventory
Shipments
Sales
Orders
Services defined as units of business logic separated from
Flow of control and routing

Data transformation and protocol transformation
SOA addressing IT as well as Business common shift
SOA is different things to different people
A set of services that a business wants to expose

to customers and clients
an architectural style which requires a
service provider, requestor and a service
description.
a set of architectural principles and patterns
which address characteristics such as
modularity, encapsulation, loose coupling,
separation of concerns, reuse, composable
and single implementation.
A programming model complete with standards,
tools, methods and technologies such as web
services.
8
Roles
Business
Architecture
Implementation
SOA Key Concepts
Key Models and Methods for SOA Enabling greater flexibility

in Enterprise IT Architectures
SOA Reference Architecture
SOA Lifecycle
Process
Services
Information
Services
Enterprise Service Bus

Partner
Services
Business App
Services
Access
Services
Management Services
Interaction
Services
Apps &
Info Assets
Development Services
Business Services
Infrastructure Services
The SOMA Method:

Service-Oriented Modeling and
Architecture
The SOA Solution Stack:

Layered solution view
Startup / Adoption
business processes
process choreography
operational systems Packaged

Application
10
Packaging and Provisioning
Composite Service
Atomic Service
Registry
Custom
Application
Governance
service components
Build/Assembly, Testing
Deployment
B2B Other
Data Architecture and Business Intelligence
Implementation
Portlet WSRP
services
atomic and composite
Service Provider
Realization
Decisions, Solution Templates &
Patterns,
Architecture, Technology Feasibility
JService
QoS Layer( Security, Management, and

Monitoring Infrastructure Service)
Specification
of Services, Components, and Flows
consumers
Integration (Enterprise Service Bus Approach)
Identification
of Candidate Services and Flows
Service Consumer
<< Input from: Business Analysis & Existing Assets>>
OO
Application
SOMA (Service Oriented Modeling and Architecture) provides

SOA Methodology
SOMA is about identification, specification, realization, implementation, and
deployment of services, components and flows
SOMA Method
SOA Solution Stack
Startup / Adoption
B2B Other
business processes
operational systems
Packaged
Application
Custom
Application
Governance
service components
Build/Assembly, Testing
Deployment
WSRP
Implementation
Portlet
services
Service Provider
Realization
Decisions, Solution Templates & Patterns,
Architecture, Technology Feasibility
JService
QoS Layer( Security, Management, and

Monitoring Infrastructure Service)
Specification
consumers
Identification
Service Consumer
<< Input from: Business Analysis & Existing Assets>>
OO
Application
Composite Service
Atomic Service
Registry
Packaging and Provisioning
11
SOA Layered View (Solution Stack)
JService
Portlet
WSRP
B2B
Other
Service Provider
12
service components
operational systems
Composite Service
Atomic Service
Registry
Packaged
Application
Custom
Application
OO
Application
services
QoS, Security, Management, and

Monitoring Infrastructure Service
business processes
Service Consumer
consumers
IBM SOA Foundation Reference Model

Strategy and Planning Services
Business-driven Enterprise Architecture and Standards
Business Services and Events
Interaction
Services
Enables collaboration between
people, processes & information
Information
Services
Orchestrate and automate

business processes
Manages diverse data and

content in a unified manner
Partner
Services
Connect with trading partners
Integrated
environment for
design and
creation of
solution assets
Process
Services
Business
Application
Services
Build on a robust, scaleable, and

secure services environment
Management
Services
Development
Services
Supports the specification of enterprise business

solutions through business architecture
Access
Services
Facilitate interactions with
existing information and
application assets
Asset and Registry Services
Manage and
secure services,
applications &
resources
Optimizes throughput, availability and utilization
Lifecycle Services
13
The SOA Lifecycle (to be addressed in detail in Governance)

Discover Services
Construct & Test Services /
UIs
Compose Services
Orchestrate Processes
Gather & Model

Requirements
Model & Simulate
Model SW
Architecture
Financial Transparency
Business/IT Alignment
Process Control
14
Integrate People
Integrate Processes
Manage and integrate
Information
Manage
Applications
& Services
Manage Identity &
Compliance
Monitor Business
Metrics
Identification and Specification of

Services (SOMA)
15
Top-Down (Ideal) Approach for SOA Start with Business Design
Step 1: Break down your business into components
Business
Components
(CBM)
Decide what is strategically important, and what is just

operations in the value chain domains
Analyze the different KPIs attached to these components
Prioritize and scope your transformation projects
Step 2: Define a Service Model

Service
Modeling
(SOMA)
Identify your services based on your business components

Specify the services and components accordingly
Make SOA realization decisions based on architectural
decisions
Step 3: Implement a Service Model
SOA
Realization
Develop a service-oriented architecture to support the

Componentized Business
Implement service based scoping policy for projects
Implement appropriate governance mechanism
Business-Aligned IT Architecture
16
Example: Business Context Diagram for Business Process

Open Account (Solution Viewpoint)
Account Manager (HQ)
Customer
CSR (Store)
Account Open
Request
n
ou
c
Ac
eF
or
m
s
De
ci
si
on
Account Open
Request
New Account
Request
ts
es
u
eq
tR
Portal
Real-time
Collaboration
re: Account History
Account
On-Boarding
Forms
Account History
17
Credit Scoring
Partner
Account Owner (HQ)

Business Process Reality and Plans Streamline Business

Process Derive Requirements
To Be Process Model
Process
Step
As Is Process Model
18
Gap
Overlapping
Example: Use Case for JKEs Open Account
19
SOA Modeling Constructs
Business Processes
(Flows)
Services
Atomic and Composite
Service Components
<<Object>>
<<Object>>
<<Object>>
SOMA was created to specifically address modeling of all three constructs.

20
Introducing SOMA (Service Oriented Modeling and Architecture)

SOMA is a business-driven modeling and design method
SOMA provides in-depth guidance on how to move from the business
models to the IT models required by SOA
SOMA adds new service-oriented aspects and techniques in
intelligent ways to enable an SOA with services directly traceable to
business goals and requirements
21
At the heart of SOMA is identification, specification, realization and

implementation of services, components and flows
Governance
Startup
Solution Template, Method Adoption
Identification
Specification
Realization
Decisions, Templates, Patterns, Feasibility
Design is separated in Identification

and Specification
Realization are mainly decisions on
how to implement, buy, or use
existing assets
Implementation
Deployment
Implementation and Deployment as

classical Software Engineering
Close
Monitoring & Management
22
SOMA defines What we do and How we do it

What we do ?
How we do it?
Governance
Identification
of candidate services and
flows, leverageable
existing assets
Specification
of services to be exposed,
flows, and components
(for realization of
functionality)
Input from: Business Analysis & Existing Asstes
Domain
Decomposition
Goal-Service
Modeling
Component
Flow
Specification
Subsystem
Analysis
Information
Specification
Component
Specification
Realization
captures realization
decisions, selects
solution templates,
details SOA Solution Ref.
Arch.
Service Flow
Specification
Service
Specification
23
Message &
Event
Specification
Realization Decisions
Solution Template
& Pattern
Selection
Technical
Feasibility
Exploration
Detail SOA
Solution
Architecture
Solution Template
Construction
Generation
Assembly
Integration
Unit Testing
Integration Testing
User Acceptance
Testing
Implementation
incl. construction/
generation, assembly,
testing, deployment,
monitoring and
management
Existing Asset
Analysis
Deployment (Packaging/Provisioning)
Identifies Services
Domain Decomposition
(Top-down Analysis)
Process Decomposition
Governance
Startup
Selection of Solution Templates, Method Adoption
Identification
Functional Area Analysis

Information Analysis,
Modeling, and Planning
Domain
Decomposition
Component Flow
Specification
Specification
Rule and Policy Analysis

Variation-Oriented Analysis
Existing Asset Analysis
(Bottom-up Analysis)
Service Litmus Tests
Service
Specification
Service Flow
Specification
Message & Event
Specification
Realization
Implementation
Goal-Service Modeling
Additionally, Service
Refactoring and
Rationalization
Subsystem
Analysis
Component
Specification
Information
Specification
Existing Asset
Analysis
Goal-Service
Modeling
Deployment
Solution Template
& Pattern
Selection and
Instantiation
Technical Feasibility
Exploration
Detail SOA Solution

Architecture
Construction
Generation
Assembly
Integration
Build/Assembly
Unit Testing
Integration Testing
User Acceptance
Testing
Testing
Close
Governance
Id Services, Components, and Flows
Exposure Decisions,
including Exposure Scope
24
Service Identification Through 3 main Complimentary

Techniques
Top-down
Analysis
Domain
Decomposition
Goal Service
Modelling
Business
Rules
Service
Candidates
Existing Asset
Analysis
25
Business Use
Cases
Variation
Oriented
Analysis
Data Analysis
Bottom-up
Analysis
Service Design via SOMA Service Identification

p
p
JK Enterprises Process Decomposition
Functional
Area
Process
Sub Process
Domain
Decomposition
Techniques:
Process Modeling Tools

Design of KPIs/Metrics
Services Identified
Open Account
Account Activation
Account Verification
26
Goal Service Modeling

Techniques
Requirements Planning
Tools
Design of KPIs/Metrics
Services Identified
Determine Applicant
Eligibility
Address Verification
Existing Asset
Analysis
Techniques
Asset Analysis Tools

Interviews/Documentation
Services Identified
Account Inquiry (CICS 2.2)

AR Setup (CICS 2.2)
Account Setup (CICS 3.1)
Create Account (SAP)
JK Enterprises Service Exposure Decisions
Example: Domain Decomposition Business Process Modeling

for JKEs Open Account
0.Open Account
1.1
Account
Inquiry
1.2
Account
Verification
1.2.1
Determine
Eligibility
27
1.2.2
Address
Verification
1.3
Account
Activation
1.3.1
AR Setup
1.3.2
Account
Setup
1.3.3
Create
Account
SOMA Specification uses comprehensive techniques to specify

Services, Flows, and Service Components that Realize Services
Information Specification
Data Model, Message Model,
Business Glossary
Existing Asset Analysis Fine

Grained
Governance
Startup
Identification
Determine the technical viability

of existing applications and
approaches to realize services
Service Specification
Elaborates the Service Model,
for example, service
dependencies, service
composition and flow, rules and
policies, event specification,
service operation, service
message specification, QoS
requirements, design decisions,
and so on
Component Flow
Specification
Subsystem
Analysis
Component
Specification
Information
Specification
Existing Asset
Analysis
Goal-Service
Modeling
Specification
Service Flow
Specification
Service
Specification
Message & Event

Specification
Realization
Implementation
Subsystem Analysis
Partitions subsystems into
service components that will be
responsible for service
realization
Domain
Decomposition
Deployment
Solution Template
& Pattern
Selection and
Instantiation
Exploration
Detail SOA Solution

Architecture
Construction
Generation
Assembly Integration
Build/Assembly
Unit Testing
Integration Testing
User Acceptance
Testing
Testing
Close
Governance
Component Specification
Details component modeling,
flow, information architecture,
messages
28
Service Litmus Tests Are Gating Criteria Used to Determine If a

Candidate Service Should Be Exposed
Candidate Services
Service
Service
Service
Service
Service Litmus Tests

1. Business Alignment
2. Composability
3. Consolidation (Redundancy
Elimination)
4. Technical Feasibility
5. [Externalized Service
Description]
6. Project Defined/Customer
Specific SLTs
Exposed Services
29
Service
Service
JK Enterprises Service Exposure Decisions
Example: JK Enterprises Service Exposure Decisions

0.Open Account
1.1
Account
Inquiry
1.2
Account
Verification
1.2.1
Determine
Eligibility
1.2.2
Address
Verification
1.3
Account
Activation
1.3.1
AR Setup
1.3.2
Account
Setup
1.3.3
Create
Account
Legend
= Service to be exposed
30
Service
Model
Service
Identification
Service Portfolio
Service Hierarchy
Service Exposure
Service Dependencies
Service Composition & Flow
Service
Specification
Service Operations
Service Messages
Service Non-Functional Requirements
State Management Decisions
Solution Templates
Service
Realisation
Mapping to Reference Architecture
Assemble
Service
Implementation
Deploy
Manage
31
SOMA Realization (Includes SOA Solution Stack Instantiation)

Select and instantiate
Governance
Solution Templates and
Startup
Patterns
Identification
Component Flow
Specification
Exploration
Examine approaches to
Domain
Decomposition
Subsystem
Analysis
Specification
Component
Specification
Information
Specification
Existing Asset
Analysis
Goal-Service
Modeling
Service Flow
Specification
Service
Specification
Message & Event

Specification
handle client
requirements
Realization
Examine legacy
application
Implementation
Solution Template
& Pattern
Selection and
Instantiation
Exploration
Detail SOA Solution

Architecture
Construction
Generation
Assembly Integration
Build/Assembly
Unit Testing
Integration Testing
User Acceptance
Testing
Testing
specific considerations
Detail SOA Solution

Stack
Deployment
Close
Governance
Consider alternatives
Select the alternative
Provide justification
32
Iterative SOA Solution Design Process

As SOMA is applied during an engagement, we incrementally
populate an architectural overview (dashboard view) of the SOA
Solution
DataPower
Portal1
F
A
A
cmp1
s2 s1
s1
s1
s3
s4
WSRR
Customer Portal
s1 s1s1
XI
FAA
cs1
P
D
MsgBroker
P
D
P
D
SAP CRM
WAS
Cust DB
Customer Order Entry
GetCustInfo
33
SOA Layered View Details
34
Layer 1: Operational Systems (Leverage Existing Investment)

Operational Systems
(Applications & Data)
ISV
OO
Application
Custom
Application
SAP
Outlook
Custom Apps
Examples for
illustration: specifics
are not in the scope
of the reference
model.
Supporting Middleware
MQ
DB2
Recognizes the value of existing IT investment

Use of existing legacy applications (e.g. COBOL application) and / or
packages (e.g. SAP)
Some SOA Related Activities:

Asset Inventory
Refactor existing applications to unlock business value
35
Layer 2: Service Components

Service Components
XML via HTTP.
Package
X
Application B
WS
Client
Service
A
Service
Component
A
Application
Y
The Service Component Layer:

Enables IT flexibility by strengthening the decoupling in the system.
Decoupling is achieved by hiding volatile implementation details from
consumers.
Often employs container based technologies like EJBs
Each Service Component:

Provides an enforcement point for service realization
Offers a facade behind which IT is free to do what they want/need to do
36
Layer 3: Services (Decouple Business and IT)
Services
The Services Layer forms the basis for the decoupling of Business and
IT.
Captures the functional contract (incl. QoS Quality of Service) for each
standalone business function or each task in a business process
The assumption is that (within an SOA) IT responsibility is to

realize/manage service implementations that faithfully conform to the
set of services in the service model.
This layer contains all the exposed services in the SOA
Each service is a contract between the consumer(s) and the provider(s)
37
Layer 4: Business Processes

(Business process alignment of IT)
Business Process
Composition; choreography;
business state machines
This layer contains operational IT artifacts that implement business

processes as a choreography of services
The set of services that are composed is restricted to those services
that are defined in Layer 3
The choice of technology depends on a set of realization decisions that
must be made when establishing a physical Reference Model for a given
SOA
38
Layer 5: The Consumer Layer

(Channel independent access to business processes )
Portal WSRP
Ajax
B2B
<other>
Consumers
This layer exists to recognize that the technology chosen to expose

Business Processes/Services must permit access from a wide set of
interaction channels.
It is important to populate this layer with the set of channels types that
are required in a solution.
39
Cross-cutting concerns/capabilities
6
Several concerns are not restricted to a single

layer in the Reference Model, these concerns
are captured in Layers 6-9
Governance
Data Architecture (meta-data & services) &

Business Intelligence
Quality of Service (Security, Management &

Monitoring Infrastructure Services)
Integration (Enterprise Service Bus)
These are not really layers but treating them as

such gives us the ability focus
discussions/decisions, for example What is
found where Governance intersects Services?
i.e. what are the Governance concerns specific
to Services?
Clearly there is interaction among these
layers also. For example, it is likely that most
data architectures will be subject to
governance
for illustration: this is not

saying that SOA requires an
ESB.
40
Example JK Enterprise a virtual company with an Open

Account Process
Sales Application
Regional Office
Sales Application
Central Office
Consumers
Open
Account
Business Process
Account
Activation
Account
Verification
Determine Applicant
Eligibility
Address
Verification
Account
Activation
Services
atomic
and
composite
Account
Inquiry
AR
Setup
Account
Setup
indirect
exposure
indirect
exposure
direct
exposure
Service
Components
EJB
Operational Systems
41
Create
Account
Message
Flow
Customer
(CICS 2.x)
Determine
Eligibility
Address
Verification
create from
scratch
third-party
reuse
EJB
SCA
Billing
(CICS 3.1)
GL
(SAP)
Designing BPM / SOA Application: Process Modeling

Optionale Schritte
entsprechend Diagnoseablauf
Funktionaler Sollprozess Entstrung CS Residential Customers - Diagnose

Channel
(IVR/ACD/CTI)
Diagnosemanagement
Unified GUI
Ticketing
CRM
Fieldforce
Management
Inventory
Outage Impact
Management
Korrelation
Messen und
Prfen
Device
Management
Material
Management
Kundenanruf
Anschlussidentifikation
Kundeninformation
Anschlusskennung
Diagnosestart
Anschlusskennung
Netzstrung ?
JA
Statistiksegement
Netzstrung
NEIN
Anzeige
Kundendaten
Kundendatenabfrage
Ticketrequest
Anzeige Ticket
Kundeninformation
Anzeige
Verrechnungssperre
Anschlusskennung
Kundendaten,
Verrechnungssperre
Anschlusskennung
Ticketerstellung
JA
Kunden-,
Verrechnungsdaten
Modeling
Anschlusskennung
Kundendaten
Verrechungssperre?
NEIN
Servicedatenabfrage
Anzeige
Mewerte
Initiale
Messungen
Anschlusskennung
Servicedaten
Technische Servicedaten
Merequest (Messung, Ressource)

Mewerte
Messungen,
Prfungen
Verarbeitung
Messwerte
Kundeninteraktion
Anzeige/
Eingabe
Kundeninteraktion
Anzeige
Mewerte
Spezifische
Messung
Anzeige
Konfigurations
daten
Abfrage
Konfiguration
1/1
42
Merequest (Messung, Ressource)

Mewerte
Abfragerequest (Resource, Service)
Konfigurationsdaten
Messungen,
Prfungen
Konfigurations
daten
Abfrage
Konfigurations
daten
Designing BPM / SOA Application: Layered View
Architecture
Integration of Legacy
43
Home Work: Exercise Layered View

Usually a diagram (or set) which is used as a basis for discussion
and explanation.
Assume you will create many iterations of this document.
Should contain processes, services, components, and operational
systems
44
Exercise SOA Solution Layer Perspective Add Missing

Components
45
Among the missing artifacts from this diagram, the Service

Components (service realization)
Also missing are To-Be supporting operational systems
SOA Reference Model
46
IBM SOA Foundation Reference Model

Strategy and Planning Services
Business-driven Enterprise Architecture and Standards
Interaction
Services
Enables collaboration between
people, processes & information
Information
Services
Orchestrate and automate

business processes
Manages diverse data and

content in a unified manner
Partner
Services
Connect with trading partners
Integrated
environment for
design and
creation of
solution assets
Process
Services
Business
Application
Services
Build on a robust, scaleable, and

secure services environment
Management
Services
Development
Services
Supports the specification of enterprise business

solutions through business architecture
Access
Services
Facilitate interactions with
existing information and
application assets
Asset and Registry Services
Manage and
secure services,
applications &
resources
Optimizes throughput, availability and utilization
Lifecycle Services
47
Separation of Concerns: Example Open Account Process

The SOA Reference Architecture in Action
Business
Dashboard
Integrated
environment
for design
Approval
and creation
of solution
assets
Interaction Services
Process Services
Information Services
Enables collaboration
between
people,
Portal
processes & information
Orchestrate and
automate business
processes
Manages diverse
dataFederated
in a unified
Query
manner
Facilitates communication
Partner Services
Community
Connect
with trading
Manager
partners
ESB
between services
Business App Services

Build on a robust,
scaleable,
and secure
EJBs
services environment
Access Services
Apps &
Info Assets
Development
Services
Open
Account
IT Service
Management
Business-driven Enterprise
Architecture and Standards
CICS
DB
Facilitates interactions
Access
Siebelinformation
Access
with existing
Adapter assets DB
and application
Access
Manage
and secure
services,
applications
&
resources
Optimizes throughput,
availability and performance
48
IT Management
Console
ESB (Enterprise Service Bus)
49
ESB (Enterprise Service Bus) Definition and Purpose

An Enterprise Service Bus (ESB) is an architectural pattern defining a flexible
connectivity infrastructure for integrating applications and services.
The architecture pattern is a guiding principle to enable the integration and
federation of multiple service bus instantiations.
An ESB performs:
Routing messages between services
Converting transport protocols between requestor and service managing
multiple protocols
Transforming message content between requestor and service
Handling business events from disparate sources
50
ESB (Enterprise Service Bus) Service Virtualization

ESB acts as an intermediary (proxy) between requestor and
provider
ESB provides service virtualization of

Location and identity
Interaction protocol
Interface
Interactions are decoupled, supporting separation of concerns

51
Lines of maintainable code
ESB is todays technology

Direct Connectivity
(No middleware)
Connectivity,
mediation &
custom
adaptation
logic
Message Queuing /
CORBA
Enterprise
Application Integration
Enterprise
Service Bus
Connectivity logic
Mediation &
custom
adaptation logic
Connectivity and
mediation logic
Custom
adaptation logic
Application
Application
Application
All connectivity,
mediation and
custom logic
buried within the
application.
Removes the
connectivity
logic from the
application
Removes the
connectivity +
mediation logic
from the
application
Connectivity,
mediation & custom
adaptation logic
Application as
a service
Reduces
application to its
core business
functions
(i.e. a service)
Reduced development and maintenance; increased flexibility and reuse

52
ESB Pattern in Action Retail Scenario
Enterprise
App Server
Business Functions
SWO
Adapter
Adapter
ESB
Adapter
POS
JMS
Message Queuing
Store i
ESB
Mediations (routing)
App Server
SWO
SOAP/HTTP,
Other
SWO
53
POS
Services
SOAP/HTTP
Terminals POS
Standard SCA (Service Component Architecture)

for Common Invocation
Interface:
How to call this
component
Component
Uniform
Representation of
encapsulated
Implementation
Reference:
What this
components calls
Encapsulate components for reuse

All components (e.g., services, rules, human interactions) are
represented consistently and invoked identically
54
Standard SCA (Service Component Architecture) Component

Assembly
Business Rule:
Get Customer
Status
doOrder
Process:
Order
Human Task:
Approve Order
Interface Map
Convert to
DB2
55
Adapter for
Relational DB
DB2
SCA (Service Component Architecture) Example Part 1

Modules: Encapsulate and Reuse Functionality
Libraries: Share common definitions
Customer
Status
Business Rule:
Get Customer
Status
Module: Customer Status

Get Customer
Status
doOrder
Process:
Order
Approve
Order
Approve
Order
Human Task:
Approve Order
Module: Approve Order Manually
Module: Process Order
Store Order
BO:Order
IF: StoreOrder
Library: OrderLib
56
Store Order
Interface Map
Convert to
DB2
Adapter for
Relational DB
DB2
Module: Update Order Database

SCA (Service Component Architecture) Example Part 2

Store Order in SAP instead of DB2
No effect on common objects or consumers
Business Rule:
Get Customer
Status
Customer
Status
Module: Customer Status

Get Customer
Status
doOrder
Process:
Order
Approve
Order
Approve
Order
Human Task:
Approve Order
Module: Approve Order Manually
Module: Process Order
Store Order
BO:Order
IF: StoreOrder
Library: OrderLib
57
Store Order
Interface Map
Convert to
SAP
Adapter for
SAP
Module: Update Order SAP

Expanded View of the Enterprise Service Bus

Interaction,
Interaction,Process,
Process,Information,
Information,Partner,
Partner,Business
BusinessApp,
App,Access
AccessServices
Services
Business Logic

Interaction Patterns
Message
MessageFlows
Flows
Mediation Patterns
Message
MessageModels
Models
Transport
TransportProtocols
Protocols
Security
Management
Registry
IT Management Services
58
ESB Multi-protocol Exchange Intermediary decoupling

heterogeneous consumers and suppliers
Domain of interest Intranet Exchange
Tooling
WebSphere
(WAS/Portal)
SOAP/JMS
SOAP/JMS
SOAP/HTTP
SOAP/HTTP
.NET Client
WebSphere
provider
.NET provider
XML/HTTP
XML/HTTP
ESB
Some Client
XML/MQ
XML/MQ Client
Some provider
COBOL Copybook/MQ
CICS
Text/MQ
Text/MQ Client
59
Example of ESB use
Sales Application
Regional Office
Sales Application
Central Office
Consumers
Open
Account
Business Process
Account
Activation
Account
Verification
Determine Applicant
Eligibility
Address
Verification
Account
Activation
Services
atomic
and
composite
Account
Inquiry
AR
Setup
Account
Setup
indirect
exposure
indirect
exposure
direct
exposure
Service
Components
EJB
Operational Systems
60
Create
Account
Message
Flow
Customer
(CICS 2.x)
Determine
Eligibility
Address
Verification
create from
scratch
third-party
reuse
EJB
SCA
Billing
(CICS 3.1)
GL
(SAP)
Example A of ESB use: Multiple Channel Access to Backend

Service
Review Export and Import
Review Export and Import
Build mediation flows
Build mediation flows
Deploy Service Module
Deploy Service Module
Integration Developer
ESB
Account
System
Java Client Appl
Service
Export
SOAP/
HTTP
(ACT)
Service
Component
Eligibility
Mediation
High Value
Accounts
Service
Export
XML/
JMS
J2EE Appl
61
Transform Request/Response
Business Objects
Log Message Infos
Service Import
HQ
Eligibility
SOAP/
HTTP
Applicant
Eligibility
Service
J2EE Appl
Transform
Request/Response
(HVA)
Determine Eligibility Service Module
Example B of ESB Use: Create SAP Service

Websphere Integration Developer (WID)
Test Client
DeployAdapter
Adapter
Deploy
Discover
EnterpriseService
Service
Discover Enterprise
GenerateBAPI
BAPIBusiness
BusinessObjects
Objects
Generate
Deploy/TestService
ServiceImport
Import
Deploy/Test
Enterprise Service
Discovery
ESB
SAP
SAP Outbound
Business
Objects
WebSphere
SAP Adapter
Service Import
RFC/
BAPI
Create New
Customer Record
Create Account Service Module
62
Interaction Services
63
Interaction Services: Using Portal As the Front End of SOA
Presentation Services
64
MS Office &
Windows
Web
Browser
Rich
Clients
Mobile
Client
eForms
Xforms
What is an Interaction Service?

Portlets can be
Portlets
UI
A Service Consumer (1)
A Service Provider (3)
Portlets can
Initiate processes (1)
Act as a Participant in a process (3)
Communicate with each other
Service A
Service B
Service C
Service D
WMQ
SOAP/HTTP
SOAP/JMS
HTTPS
3
Reque
s
t/Resp
on
se
Coarse
d
Graine
Reque
s
1
rained
Fine G
Reque
s
t/Resp
on
se
rained
Fine G
Reque
s
t/Resp
on
se
Coarse
d
Graine
The Portal Framework Provides Service Aggregation

65
Information Services
66
Information Services in SOA Reference Architecture

Delivering actionable information to people and processes
Connect, enhance and deliver in-context information across diverse
operating systems, applications and legacy systems through reusable
services
The Information Services enables consistent views and maintenance of data
and content, providing a single view of the truth to people and processes
67
Information Services: Several Patterns
Account
Open
Process
Account
Open
Process
Account
Open
Process
Store/Retrieve
Application
Lookup
Customer
Store/Update
Customer
Account
Open
Process
Request
Documentation
XML
Account
Application
Database
68
Account
Data
Customer
Master
MDM
Account
Documents
Information
Service
Enablement
Integrated
information
services
Master
Data
Management
Content
Management
Information Services: Pattern Deliver Your Data

Virtualized Through Services
As-Is Environment
Data resides in disparate sources

Manual & redundant integration of
data by multiple consumers results
in high costs and
inconsistent/inaccurate data
Slow response time due to
inefficient real-time access
Solution Characteristics
On demand integration instead of

redundant data
Transparent & optimized access to
distributed, heterogeneous sources
Review
current
accounts
Federated Data
Service
SOA
context
(Reporting)
Application
traditional context
Data Virtualization Through

Data Federation Server
Metadata
Results
Real-time access to distributed

information, fast response time
Scalable approach for adding more
data sources
69
Legacy
Database
Legacy
Database
account data
Closing Remark
70
Just remember the future might bring more than you think
I think there is a world market
for maybe five computers.
Thomas Watson, chairman of IBM, 1943
Computers in the future may weigh

no more than 1.5 tons.
Popular Mechanics, 1949
There is no reason anyone would

want a computer in their home.
Ken Olsen, founder of DEC,1977
Prediction is difficult, especially

about the future
Niels Bohr, 1957
640K ought to be enough

for anybody.
Bill Gates, 1981
71
72

UniZH HS2012 HPH2 SOA 21 09 2012

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UniZH HS2012 HPH2 SOA 21 09 2012

Transféré par

Droits d'auteur :

Formats disponibles

Dr.

2012 IBM Corporation

2012 IBM Corporation

Agenda of this Session

2012 IBM Corporation

2012 IBM Corporation

2012 IBM Corporation

Service Oriented Architecture

Services defined as units of business logic separated from

Flow of control and routing

2012 IBM Corporation

SOA addressing IT as well as Business common shift

2012 IBM Corporation

SOA is different things to different people

A set of services that a business wants to expose

2012 IBM Corporation

SOA Key Concepts

2012 IBM Corporation

Key Models and Methods for SOA Enabling greater flexibility

Enterprise Service Bus

The SOMA Method:

The SOA Solution Stack:

operational systems Packaged

Packaging and Provisioning

QoS Layer( Security, Management, and

Integration (Enterprise Service Bus Approach)

<< Input from: Business Analysis & Existing Assets>>

2012 IBM Corporation

SOMA (Service Oriented Modeling and Architecture) provides

SOA Solution Stack

Data Architecture and Business Intelligence

QoS Layer( Security, Management, and

Integration (Enterprise Service Bus Approach)

<< Input from: Business Analysis & Existing Assets>>

Packaging and Provisioning

2012 IBM Corporation

SOA Layered View (Solution Stack)

Data Architecture and Business Intelligence

QoS, Security, Management, and

Integration (Enterprise Service Bus Approach)

2012 IBM Corporation

IBM SOA Foundation Reference Model

Business Services and Events

Orchestrate and automate

Manages diverse data and

Enterprise Service Bus

Build on a robust, scaleable, and

Supports the specification of enterprise business

Asset and Registry Services

2012 IBM Corporation

The SOA Lifecycle (to be addressed in detail in Governance)

Gather & Model

Identification and Specification of

2012 IBM Corporation

Top-Down (Ideal) Approach for SOA Start with Business Design

Step 1: Break down your business into components

Decide what is strategically important, and what is just

Step 2: Define a Service Model

Identify your services based on your business components

Step 3: Implement a Service Model

Develop a service-oriented architecture to support the

2012 IBM Corporation

Example: Business Context Diagram for Business Process