conceptual reference soa search symposium soa workshop
TRANSCRIPT
Conceptual Reference SOASEARCH Symposium SOA WorkshopWashington, DCMarch 12, 2006
Scott CameChief Enterprise ArchitectWashington Department of Information Services
[email protected](360) 902-3519
What to expect At the end, you should:
Understand some common requirements that drive an information sharing architecture
Understand what differentiates SOA as an information sharing architecture
Understand what first steps you could take towards pursuing an SOA
Architecture Requirements How should decisions be made?
Planning decisions Investment decisions System design decisions
Decision-making tools Principles Environmental Trends Business Drivers
Principles Decisions about system integration should:
Minimize the dependencies between integrated information systems (“loose coupling”)
Favor technologies that leverage open industry standards
Promote the treatment of integration interfaces as sharable enterprise assets
Recognize the need for common integration infrastructure and a commitment to an integration platform
Environmental Trends Decisions about system integration should
reflect the following trends: Open standards for integration are stabilizing The market for integration infrastructure remains
diverse, with many viable players
Business Drivers Decisions about system integration should
reflect the following drivers: Solutions will evolve over time Common solutions where we can, unique solutions
within common business processes where we must External partners with diverse platforms Maintain information in one place, and propagate
where necessary Secure integration across security perimeter
Conceptual Reference Architecture A reference architecture establishes key
concepts, relationships, and high-level components to support integration
Identifies specific areas where we need more work, but demonstrates how everything fits together to satisfy requirements
Solution Design Guidelines Favor solution designs that:
Separate user interface from business logic and persistence logic (separate software interfaces)
Integrate with other systems across an interface (not directly)
Integrate (inbound and outbound) using open-standard technologies
Capabilities and Services
Services Service Consumers
Real-World EffectsCapabilitiesproduce
provide access to
use
seek
providersystems
can
impl
emen
t
consumersystems
act as
Interfaces and Interaction
Service Interfaces
Services
Visibility
Interaction
prov
ide
acce
ss to
are the means of
depends on
is described by
are composed of
Repository
define semantics of
hosts
assi
sts
hosts
Service Models
Information Model
Behavior Model
PreviousSlide
Service Interaction Profiles
Service Interaction Profile Guidelines
Service Interaction Profiles
Service Interaction Requirements
Message Exchange Patterns
Service Interfaces
Interface Description
Requirements
guid
e de
sign
and
desc
riptio
n of
Message Definition Mechanisms
govern content of
require support forde
fine
inte
rope
rabl
eim
plem
enta
tions
of
PreviousSlide
Policies, Contracts, Agreements
Service Interfaces
Services
prov
ide
acce
ss to
Policies and Contracts
constrain use of orexpected result of using
can
be d
escr
ibed
by
Agreementscan be specified in
PreviousSlides
Execution Context
Service Interaction Profiles
Service Interaction Requirements
Execution Context
Policies and Contracts
can be implemented by
can constrain
esta
blis
h so
me
requ
irem
ents
for
PreviousSlides
Brief interlude: What SOA is not SOA is not web services
Web services is a technique for implementing an SOA (a particularly good one, at that)
SOA is not a particular kind of execution context There is no one platform, tool, or type of
infrastructure that “is” SOA
Service-Capability Hierarchy
Services Service Consumers
Real-World EffectsCapabilities
Orchestration Mechanisms
TransformersRoutersOrchestrations
are types of
produce
provide access to
use
seek
com
pose
act as
providersystems
standardizeimplementation
of
can
impl
emen
t
consumersystems
act as
Business Process Models define
Enterprise Integration Patterns
iden
tify
com
mon
type
s of
PreviousSlides
Service-Capability HierarchyA
pplic
atio
n
Laye
rS
ervi
ces
Laye
rB
usin
ess
P
roce
ss
Lay
er
.NET J2EE Legacy
orchestration service layer
business service layer
application service layer
Audience Participation
An everyday example of accessing capabilities through services…
Governance Issues Principles/Guidelines needed for:
Service design Service modeling System design (capabilities)
Decisions needed: Which service interaction profiles? Quality assurance Change management Investments in execution context and repository
Steps towards an SOA Confirm architectural requirements Determine profile(s) Establish service design and modeling guidelines
(including domain vocabularies) Identify execution context and registry/repository
requirements, then make investments Model business processes and identify services Pilot business process implementation (could be
point-to-point to start) Explore orchestration mechanisms and intermediaries