SOA Solution Architecture and Design Patterns

SOA Solution Architecture and Design Patterns
Presented By:
Paul C. Brown
This document (including, without limitation, any product roadmap or statement of direction data) illustrates the planned testing, release and availability dates for TIBCO products and services. It is for informational purposes only
and its contents are subject to change without notice. Copyright 2000-2013 TIBCO Software Inc. All rights reserved. TIBCO Confidential & Proprietary Information.
SAFE HARBOR DISCLOSURE

During the course of this presenta1on TIBCO or its representa1ves may make forward-looking statements
regarding future events, TIBCOs future results or our future nancial performance. These statements are
based on managements current expecta1ons. Although we believe that the expecta1ons reected in the
forward looking statements contained in this presenta1on are reasonable, these expecta1ons or any of the
forward looking statements could be prove to be incorrect and actual results or nancial performance could
dier materially from those stated herein.

We refer you to the reports that TIBCO les from 1me to 1me with the Securi1es and Exchange Commission
for a discussion of important factors that could cause actual results or nancial performance to dier
materially from those contained in any forward-looking statement made in connec1on with this
presenta1on. TIBCO does not undertake to update any forward-looking statement that may be made from
1me to 1me or on its behalf.
Objectives
Describe the best practices for
architecting solutions
Explain the distinguishing
characteristics of a service
Identify appropriate solution design
patterns
3

Topics
Architecting Your Solution

Services
A

Design Patterns
4

Nouveau Health Care

Health care insurance provider
Benefits plan
Sells health care insurance policies
Relationship management for:

Members
Companies (employers providing health care benefits)
Providers
Claims Processing Center for other insurers

Partners process some types of claims
Vision
Dental Care
Todays focus: Payment Manager (a service)
Three Essential Architecture Views1

Architecture Pattern The Structure of the solution
Participants and communications channels
Process Model The Work Process

Includes business information/artifact model
Process-Pattern Mapping How the Solution Works
Architecture
: Process
Model
: Architecture
Pattern
: Process-Pattern Mapping
Assignment of work responsibilities
1. Bass et. al., Software Architecture in Practice, 2nd Edition, Addison Wesley
Nouveau Payments Architecture Pattern
7

Nouveau Business Processes

Validate membership
Manage payments
Process claims
Monitor claims processing
Process Claim Payment Manager
9

Payment Manager Process Coordination

Deferred payment
Delegation with confirmation
Settle Deferred payment

Immediate payment
Synchronous interaction
service consumer
activity prior to
claim payment
Payment Manager
immediate request : Pay

Claim Request
payClaim
pay all
(Claim Payment Interface::)
providers
activity after
claim payment
completed payment report :

Pay Claim Response
Immediate Payment Mapping
11

Deferred Payment Mapping
12

Settlement Process Mapping
13

Payment Manager Domain Model
14

High Availability Deployment Pattern
Benefits
>90% Reduced rework
25% Faster time to market
More flexible architecture
Architects must be leaders!
16

Topics

Services
A

Design Patterns
17

The Service Pattern

Service: Reusable unit of functionality with standardized (abstracted) interfaces
Service
Consumer
Native semantics
for operation and
data
Native technology
for operation and
data
Using
Component
Service
Interface
Some level of
standardization
Technology of access
Data semantics
Operation semantics
Service
Wrapper
Native
Interface
Provider of
Functionality
Traditional Object/
Component
Approach
Native
Interface
Provider of
Functionality
Service
Benefits of Services
Reuse
Avoids cost of replicating functionality
Faster time to market for projects
Isolation of service consumer

Service provider design can evolve without impact
Service provider can be replaced without impact
Flexibility
Platform independence - provide functionality anywhere and access it from anywhere
Where Do Services Make Sense?

When there is functionality that is either used in more than one place or is
provided in more than one place, particularly when those places are different
applications
When counting clients and providers, take future plans into account
Topics

Services
A

Design Patterns
21

Message Exchange Patterns

Example Participants:
Newspaper publisher of news
News source information for newspaper to publish
Customer (news subscriber, non-subscribers)
News Source
Newspaper
Customer
Four Use Cases (Processes):
News source delivering a tip (in-only)

Customer subscribing to paper (in-out)
Newspaper sending paper electronically (out-only)
Newspaper sending offer that requires a response (out-in)
Request-Driven Interactions
Event recognition and action decision are performed by the same party

party A
party B
Party A:
a)
b)
recognize that some

condition (event) has
Recognizes a condition (event)

Decides what action to take
occurred
decide what
action is
work request
Party B
a)
required
Performs the work upon request
perform work
wait for work

result
work result
continue...
Event-Driven Interactions
Event recognition and action decision are performed by different parties

Party A
party A
party B
recognize that some
a)
b)
Recognizes a condition (event)

Announces the event
condition (event) has

occurred
Party B
announce the occurrence of
the event
event announcement
decide what
work should be
performed
a)
b)
c)
Listens for the event

Decides what work to perform
Performs the work
perform work
Accessing External Systems

API: preferably publicly supported
Very capable in the inbound (to the system) direction
Generally cannot support outbound direction
Database:
Schema must be well understood
Be careful not to bypass business logic
File
Many legacy apps have file-based interfaces
Command line operations
Protocol
Some applications have protocol interfaces
API tied to a transport same limitations
Event Recognition is a Key Challenge

Ability to recognize events is necessary to trigger work elsewhere
Most systems are not designed to identify events and take action
e.g. initiate communications
Key role for adapters
Database Interaction Patterns

Two options:
Direct JDBC access
Indirect via TIBCO ActiveMatrix Adapter for Database
Direct access
Initiated by component requiring access
Avoids need for adapter
TIBCO ActiveMatrix Adapter for Database

Interaction initiated by either party
Involves extra component (adapter) and its interface
Provides decoupling
Participant Coordination Patterns

One-way communications (fire and forget)
Request/Reply
Delegation
Request-reply returns a promise to do the work later
Delegation with Confirmation

Adds an asynchronous confirmation of work completion
Distributed Transactions
Process Orchestrator
Direct and monitor the overall process
Evaluating for Breakdown Detection

Consider
Loss of each individual participant, individual communication
Individual inputs and results that fail validation
Which participant is in a position to detect each problem?

What will the symptoms be?
Often several failures will result in the same symptoms
Loss of request, failure to perform work, loss of response may all result in the absence of a response
What actions should be taken by the participant detecting the breakdown?

Annunciate the problem
Take corrective action
Feedback Can Improve Breakdown Detection

Add feedback from the last participant
to the first
note
request service
successful
completion
Service Request
confirmation
First participant becomes overall

monitor
perform
service
Service Result
perform
third-party work
third-party result
Monitoring Can Improve Breakdown Detection

Monitor determines whether process is executing properly
Requires:
Event capture
Process model for comparison
SLAs to interpret absence of events
Motivation for TIBCO BusinessEvents
message 1
component A
message 2
component B
message 3
component C
component D
copy of message 1
copy of message 2
copy of message 3
process start event
process end event
Third Party Monitor
Summary
Three Essential solution architecture views
Process, architecture pattern, mapping
Architects in leadership roles can reduce solution time to market by 25%

Services require investment invest wisely!
Consider design patterns before detailed design
Breakdown detection should be a major consideration
32

Dont forget to take your survey!

Available after your session on.
TUCON Mobile App
TUCON Website (tucon.tibco.com)

SOA Solution Architecture and Design Patterns

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOA Solution Architecture and Design Patterns

Uploaded by

Copyright:

Available Formats

SOA Solution Architecture and Design Patterns

SAFE HARBOR DISCLOSURE

Architecting Your Solution

Nouveau Health Care

Relationship management for:

Claims Processing Center for other insurers

Todays focus: Payment Manager (a service)

Three Essential Architecture Views1

Process Model The Work Process

Process-Pattern Mapping How the Solution Works

Assignment of work responsibilities

Nouveau Payments Architecture Pattern

Nouveau Business Processes

Process Claim Payment Manager

Payment Manager Process Coordination

Settle Deferred payment

immediate request : Pay

(Claim Payment Interface::)

completed payment report :

Immediate Payment Mapping

Deferred Payment Mapping

Settlement Process Mapping

Payment Manager Domain Model

High Availability Deployment Pattern

Architecting Your Solution

The Service Pattern

Isolation of service consumer

Where Do Services Make Sense?

Architecting Your Solution

Message Exchange Patterns

Four Use Cases (Processes):

News source delivering a tip (in-only)

recognize that some

Recognizes a condition (event)

Performs the work upon request

wait for work

recognize that some

Recognizes a condition (event)

condition (event) has

Listens for the event

Accessing External Systems

Event Recognition is a Key Challenge

Key role for adapters

Database Interaction Patterns

TIBCO ActiveMatrix Adapter for Database

Participant Coordination Patterns

Delegation with Confirmation

Evaluating for Breakdown Detection

Which participant is in a position to detect each problem?

What actions should be taken by the participant detecting the breakdown?

Feedback Can Improve Breakdown Detection

First participant becomes overall

Monitoring Can Improve Breakdown Detection

Motivation for TIBCO BusinessEvents

process start event

process end event

Third Party Monitor

Architects in leadership roles can reduce solution time to market by 25%

Dont forget to take your survey!

You might also like