Академический Документы
Профессиональный Документы
Культура Документы
Architecture
Mark Bailey
Senior System Consultant
Security, Government, & Infrastructure
mark.bailey@intergraph.com
Agenda
SOA Defined
SOA Principles
Applying SOA
Page 2
Current Environment
Page 3
Application Centric
Page 4
Application Centric
Business scope
Narrow Consumers
Limited Business Processes
Finance
Integration
Supply
Architecture
bound to
EAI vendor
Redundancy
Manufacturing
Distribution
Overlapped resources
Overlapped providers
Business functionality is
duplicated in each
application that requires it.
Page 5
Page 6
Service Centric
Business scope
Service
Service
Supply
Service Architecture
Service
Shared
Services
Service
Manufacturing
Distribution
source:TietoEnator AB,
Kurts Bilder
Page 7
source:IBM
Page 8
Why SOA?
To enable Flexible, Federated Business Processes
Enabling a virtual federation of
participants to collaborate in an
end-to-end business process
Enabling alternative
implementations
Enabling reuse of
Services
Service
Identification
Service
Ticket Collection
Service
Ordering
Ticket Sales
Service
Service
Service
Inventory
Logistics
Service
Service
Service
Service
Availability
Manufacturing
Page 9
Service to Customers
Enterprise
Smart Clients
Stores POS
Mobile
3rd Party Agents
Portal
Internal Systems
source:TietoEnator AB,
Kurts Bilder
2008, Intergraph Corporation
Why SOA?
Enable Structural Improvement
Process Z
ERP X
Standardizing capabilities
e.g. Single Customer
Details Service
Reducing impact
of change
ERP Z
Partner A
Information Consistency
Policy Consistency
Service
Consolidation/
Selection
process
CRM
System 2
Process Y
Encapsulating
implementation
complexity
CRM
System 1
Product
System
Page 11
SOA Defined
Services
Servicesare
areautonomous,
autonomous,discrete
discreteand
andreusable
reusableunits
unitsofofbusiness
businessfunctionality
functionality
exposing
its
capabilities
in
a
form
of
contracts.
exposing its capabilities in a form of contracts.
Services
Servicescan
canbe
beindependently
independentlyevolved,
evolved, moved,
moved, scaled
scaledeven
even ininruntime.
runtime.
2008, Intergraph Corporation
Page 12
A collection of services
Governed by architectural
patterns and policies
services
type
t
en
id
at
fi ic
type
n
io
an
gr
y
rit
a
ul
type
d
en
p
de
c
en
source:TietoEnator AB,
Kurts Bilder
Page 13
Page 14
for architecture
Page 15
Page 16
in distributed communications
EAI
Project-ware
SOA
source:Sam Gentile
Page 17
Example Layers
Presentation
& workflow
1.
Flexible composition.
2.
Reuse.
3.
4.
5.
Separation of Concerns.
6.
Composed Services
Basic Services
Underlying
API
according to:TietoEnator
AB, Kurts Bilder
Page 18
Basic 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, faades, and functionality-adding services).
Encapsulate business specific workflows or orchestrated services.
Page 19
Service Types
Page 20
SOA Principles
Loose Coupling
Abstraction
Reusability
Autonomy
Statelessness
Discoverability
Composability
Page 21
Services within the same service inventory are in compliance with the same
contract design standards."
Page 22
Loose Coupling
Page 23
Abstraction
Page 24
Reusability
Page 25
Autonomy
Primary benefits
Increased reliability
Behavioral predictability
Page 26
Statelessness
Goals
Increase service scalability
Support design of agnostic logic and improve service reuse
Page 27
Discoverability
Page 28
Composability
Page 29
Goal: Establish SOA organization governance (SOA Board) that governs SOA
efforts and breaks down capabilities into non-overlapping services
Page 30
Policies
Codification of laws, regulations, corporate guidelines and best practices
Must address all stages of the service lifecycle (technology selection, design,
development practices, 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 case review, 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 crossfunctional representatives
2008, Intergraph Corporation
Page 31
Applying SOA
Governance
Page 32
Service Orientation
Reuse
Sharing of Responsibilities
Increased complexity!
Page 33
Page 34
SOA seeks to bridge the gap between business and technology promoting
business agility (its all about managing change)
SOA
Is complex
Requires governance
Requires executive management buy-in
Requires commitment with resources (people and $$)
Page 35