Conceptual Reference SOA SEARCH Symposium SOA Workshop

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