Thomas Erl Introducing S O A Design Patterns

This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com

Founding Sponsors

Platinum Sponsors

Gold Sponsors Silver Sponsors

Introducing SOA Design Patterns

Thomas Erl, SOA Systems Inc.
Copyright © SOA Systems Inc. (www.soasystems.com)

Introducing SOA Design Patterns (Copyright © SOA Systems Inc. soaschool.com, soasystems.com) 1

About the Book Series

Five titles currently in
development for
release in 2009.

The Prentice Hall Service-Oriented Computing Series
is the top-selling SOA book series in the world.
www.soabooks.com

About the SOA Certified
Professional Program
Industry-recognized certification
program for the following
designations:
• Certified SOA Architect
• Certified SOA Analyst
• Certified SOA Consultant

For more information:
• www.soacp.com
• www.soaschool.com



SOA Types

• Service Architecture – The architecture of a single
service.
• Service Composition Architecture – The architecture
of services assembled into a service composition.
• Service Inventory Architecture – The architecture
that supports a collection of related services that are
independently standardized and governed.
• Service-Oriented Enterprise Architecture – The
architecture of the enterprise itself, to whatever
extent it is service-oriented.


Service
Architecture

Whereas it was not
always that common
to document a
separate architecture
for a component, it is
generally required for
service architectures,
especially for agnostic
services that need to
exist as independent
and highly self-
sufficient and self-
contained software
programs. Copyright © SOA Systems Inc. (www.soasystems.com)


Service Composition
Architecture
In much the same
way as an application
architecture for a
distributed system
includes the individual
architecture
definitions of its
components, this form
of architecture
encompasses service
architectures of all
participating services.


Service
Composition
Architecture
A composition architecture
(especially one in which
services encapsulate
disparate legacy systems)
may also be compared to an
integration architecture.
This comparison is usually only
valid in scope, as the design
considerations emphasized
by service-orientation ensure
that the design of a service
composition is much different
than that of integrated
applications.


About Design Patterns

• The upcoming book “SOA Design Patterns” documents a
catalog of 85 design patterns.
• A design pattern can be considered a proven design
solution to a common design problem.
• Patterns can be viewed as building blocks that help you
assemble a service-oriented architecture and overcome
common design challenges.
• Some are compound patterns that are comprised of
multiple design patterns.
• Each pattern relates to one or more SOA types.


Enterprise Inventory Service Façade Compensating Service Trans.
Domain Inventory Exception Shielding Service Callback

Service Architecture Patterns
Logic Centralization Redundant Implementation Service Instance Routing
Service Normalization Service Data Replication Composition Autonomy
Service Layers Partial State Deferral Agnostic Sub-Controller
Canonical Schema Legacy Wrapper Direct Authentication
Canonical Protocol Decoupled Contract Brokered Authentication
Process Abstraction Contract Centralization Message Screening
Entity Abstraction Contract Denormalization Trusted Subsystem
Utility Abstraction Concurrent Contracts Data Confidentiality
Process Centralization Validation Abstraction Data Origin Authentication
Schema Centralization Service Refactoring Data Model Transformation
Policy Centralization Service Decomposition Data Format Transformation
Rules Centralization Decomposed Capability Protocol Bridging
Dual Protocols Proxy Capability
www.soapatterns.com
Canonical Resources Distributed Capability
State Repository Capability Composition
Stateful Services Capability Recomposition
Inventory Endpoint Service Messaging
Cross-Domain Utility Layer Messaging Metadata
Canonical Expression Service Agent
Metadata Centralization Intermediate Routing
Functional Decomposition Asynchronous Queuing
Service Encapsulation Reliable Messaging
Agnostic Context Event-Driven Messaging
Non-Agnostic Context Atomic Service Transaction
Agnostic Capability Copyright © Messaging (www.soasystems.com)
State SOA Systems Inc. November 2008


Pattern Types
Service Inventory Design Patterns Service Composition Design Patterns
Logical Inventory Layer Patterns Capability Composition Patterns
Inventory Centralization Patterns Service Messaging Patterns
Inventory Implementation Patterns Composition Implementation Patterns
Inventory Governance Patterns Service Interaction Security Patterns
Transformation Patterns

Service Design Patterns Compound Design Patterns
Foundational Service Patterns
Service Implementation Patterns
Service Security Patterns
Service Contract Design Patterns
Legacy Encapsulation Patterns
Service Governance Patterns


Design patterns
have relationships Pattern
Design Relationships
with design principles,
architecture types,
and each other.



Domain Inventory Pattern

• A service inventory is ideally modeled and designed
on an enterprise-wide basis in order to establish an
inventory architecture wherein services can be
freely and repeatedly recomposed.
• However, in larger environments it can be
impractical or even unrealistic for one service
inventory blueprint to span the entire enterprise and
keep all services in constant alignment.
• Standardization and governance issues can raise
various concerns, most of which tend to be
organizational in nature.

Common

Service Inventory Scope
organizational
issues that
hinder efforts
to establish
a single,
enterprise-
wide service
inventory.



To address these
challenges, multiple
domain-specific service
inventories are created
for one enterprise.
The scope of each
represents a well-
defined enterprise
domain.



• Within domains, service inventories are
standardized and governed independently.

• The decision to design domain inventories is a
critical decision point as is the determination of
the domain inventory scope.

• Even though this approach can increase the ease
of SOA adoption, it will impose targeted
transformation requirements to enable any level of
cross-domain interoperability.



Compound Pattern:
Enterprise Service Bus (ESB)


Enterprise Service Bus (Base Model)

Intermediate Routing
A message undergoing
various processing steps
carried out by an ESB
in order to successfully
transform and deliver the
message contents to
their destination.

This diagram depicts a
combination of the
Broker, Intermediate
Routing, and
Asynchronous
Queuing patterns
co-existing to provide
a base ESB.


Compound Pattern:
Orchestration


Orchestration (Base Model)
Non-agnostic Orchestration
business process
logic is abstracted
and then physically
centralized into an
environment that
provides a native
state repository.
The logic is
executed and
managed via an
orchestration
engine which may
or may not support
industry standards,
such as WS-BPEL. Copyright © SOA Systems Inc. (www.soasystems.com)

1

Q&A

SOA Systems Inc. www.soasystems.com
SOA Training www.soaschool.com
SOA Certification www.soacp.com
SOA Books www.soabooks.com
SOA Magazine www.soamag.com
SOA Patterns www.soapatterns.org

Updates notify@soasystems.com
Contact info@soasystems.com


1

Thomas Erl Introducing S O A Design Patterns

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Thomas Erl Introducing S O A Design Patterns

Similar to Thomas Erl Introducing S O A Design Patterns (20)

More from SOA Symposium

More from SOA Symposium (20)

Recently uploaded

Recently uploaded (20)

Thomas Erl Introducing S O A Design Patterns