tucon 2006 fundamentals of tibco architecutre

TIBCO USER CONFERENCE / 2006

This document (including, without limitation, any product roadmap or statement of direction data) illustrates the planned testing, release and availability dates for TIBCO products andservices. This document is provided for informational purposes only and its contents are subject to change without notice. TIBCO makes no warranties, express or implied, in or relating to thisdocument or any information in it, including, without limitation, that this document, or any information in it, is error-free or meets any conditions of merchantability or fitness for a particularpurpose. This document may not be reproduced or transmitted in any form or by any means without our prior written permission.

TIBCO Architecture FundamentalsProgram Overview

April 11, 2006

Paul Asmar – Vice President, Global Architects

TIBCO USER CONFERENCE / 2004TIBCO USER CONFERENCE / 2006 2This 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.

� Implementing EnterpriseServices with TIBCO®

� Services Infrastructure

� Services Identification,Implementation andOrchestration

� Service Deployment

� Scalability/Fault Tolerance

� Lifecycle Management

� Architecture Discussion

� Architecture and ServicesOverview

� Architecture Challenges

� Leveraging the TIBCOArchitecture Method

� Enterprise SOA

� Tools Demonstration

Program Agenda


What Is an SOA?

� An architecture that enables IT to compose applications fromservices, and that promotes greater reuse and flexibility

� Benefits of SOA:

�� SimplifySimplify – Leverage assets, deliver new functionality more easily

�� OpenOpen – Reduce costs, risk and vendor lock-in

�� AccelerateAccelerate – Rollout new functionality faster (Agility)

� Enabling technologies for SOA:

� Services – Service development, deployment, management

� Events – Capture, process and deliver events

� Integration – Adapters and integration services

� Mediation – ESB

� Processes – Orchestration


Web Apps

• 3-tier (UI/logic/data)

• EAI (processes)

• Web servers

• Java/J2EE/JMS

’95-’01

Processes

MediationEvents

Client-Server

• 2-tier

• RPC, Messaging

’85-’95

Events

Big Iron

• Monolithic

Pre-1985

SOA

• “N-tier” services

• UDDI/SOAP/WSDL

• ESB Technology

’01-

Services

Processes

MediationEvents

Architecture Evolution: How We Got to SOAThrough Messaging and Integration


TIBCO’s View of SOA

Accelerate projects,initiatives, andgo-to-market cycles

Improveoperationalvisibility andresponsiveness

Automate andstreamlinebusinessprocesses



TIBCO Architecture FundamentalsPart 1: Architecture Discussion

April 11, 2006

Paul Brown – Principal Software Architect


Architecture Discussion:Objective and Topics

+ =+

� Describe fundamental principles for architecting TIBCOprojects and experience supporting tools and methods

� Architecture and Services Overview


� Leveraging the TIBCO Architecture Method

� Enterprise SOA



Architecture and Services Overview


� What Is Architecture?

� The Scope of Architecture

� The Business Process Connection

� Services



� Enterprise SOA



What Is Architecture?

�� Architecture is the characterization of the physical structureArchitecture is the characterization of the physical structureand the logical organization of a systemand the logical organization of a system

� Physical Structure — Components and their physical arrangement

� Software on machines, machines on networks

� Machines, networks, and minor components form the infrastructure

� Logical Organization — Component roles and responsibilities withrespect to the business process(es) the system is intended to support

� Who performs what work, when, and under what conditions?

� Who owns what information, how is it accessed and distributed?

� Who monitors, manages, and reports on the overall work process?


What Are We Designing?

�� A largeA large--scale systemscale system--ofof--systemssystems

� The major components are systems in their own right

� Each independently performs useful functions for the enterprise

� We are integrating these systems to improve the overall business

� The business processes (by definition) span multiple systems

� We have limited (if any) control over the major systems themselves

� Yet we are responsible for getting them to work together

� The only tool we have to work with is communications with those systems

� To move data

� To coordinate work

� To obtain status

� To monitor and manage the process


Architecture Has Broad Scope


� Business processes make design assumptions about what systemscan and should be doing: functions provided, interfaces needed,data and process management

� Inappropriate assumptions lead to ugly system designs and ungainlybusiness processes

� For best results, work process design should be a collaborative effortbetween business and technical people

� Focus on finding a good marriage between business needs andtechnical realities

� Achieve business goals

� Practical and cost effective from a technology perspective

� Make sure both sides are aware of “care and feeding” activities

� e.g., administering credentials/qualifications, maintainingreference data

Business Process Design ImpactsArchitecture


People Processes

Information Systems

TOTAL

ARCH I T ECT U

RE

A good architecture demands a clear understandingA good architecture demands a clear understandingof these relationships!of these relationships!

Business Processes andArchitecture Are Inseparable

� Business process defines the interplay between:

� The people using the system

� The systems themselves

� The information used in the workprocess components (traditional architecture)

� Architecture defines the roles of systemcomponents with respect to the workprocesses, information and people:

� Which components participate in which activities

� Which components manage which pieces of information

� Which components are involved in which human interactions


What Is the TIBCO Architect’s Job?

If you find that youIf you find that you ““cancan’’t get there from here,t get there from here,”” blow the whistle loudblow the whistle loudand early! Saving time and resources leaves more options open.and early! Saving time and resources leaves more options open.

Architecture BenefitMeter

None

Negative Positive

Doesn'tJustifyCost

HurtsBusinessProcess Good

� Design a system that:

� Supports the work processes

� Provides the expected benefit

� Can be delivered within theproject cost and scheduleguidelines

� Does this with acceptable risks in:

� Work process disruption

� Ability to achieve the benefit

� Ability to execute within cost and schedule guidelines


What the Architect Must Know aboutthe Business

� What is the Business Process and how will it change?

� e.g., Automate order entry so customers can enter their own orders

� What are the expected quantifiable benefits?

� Improve order processing productivity by 20% to support anticipated acquisitionswithout hiring additional personnel

� What are the cost and schedule constraints?

� The business requires the capability within 9 months at a cost not to exceed$450K in order to complete the planned acquisition

� How does the business process handle breakdowns?

� If the credit check service is unavailable, accept low-value orders withoutchecking and manually approve high-value orders

� What is the risk if the business process breaks down?

� If the productivity benefit falls below 10%, the company will operate at a loss; or ifthe system is not available 99.9% of the time the productivity benefit will be lost


Services

� What is a service?

� A commonly used unit of functionality

� e.g. Sales Order Management

� Packaged for consistent re-use

� Becomes a de-facto standard

� The goal is to save money!

� Standardize the function so that what the next project (process) needs isalready there

� Most functionality already exists

� In one system, but accessed many ways

� In multiple systems


Typical Service Architecture

UsingComponent

Provider ofFunctionality

NativeInterface

Traditional Object/ComponentApproach

� Native semantics foroperation and data

� Native technology foroperation and data

UsingComponent

Provider ofFunctionality

NativeInterface

Service Approach

Service

ServiceInterface

� Either Company orApplication-SpecificSemantics for theoperation depending onthe level of serviceabstraction.

� Company standardsemantics for data

� Company standardtechnology for operationand data

� Native semantics foroperation and data

� Native technology foroperation and data

� A service is a reusable unit of functionality with standardized interfaces

� A business service is a unit of business process functionality exposedas a service so that it is available to a wider audience


Business and Infrastructure Services Differ!

� Business Services encapsulate portions of business processes

� e.g. “Place Sales Order” or “Invoice Customer”

� The requirements come from the business community

� The users are future business processes

� Infrastructure Services encapsulate portions of system processes

� e.g. “Report error” or “Make Audit Entry”

� The requirements come from the technical community

� The users are future technical projects

Different organizations are involved!Different organizations are involved!


The Reusability Challenge

� How do we design for future usages?

� Today we enter orders in person, via paper, by phone, on-line, …

� What’s next – via Blackberry? Automatic re-order?

� Your CPG firm decides to sell branded clothing as a promotion!

� Orders now need sizes, colors, etc.

� Insight is required when conceptualizing a service

� What might change in the future?

� Evolutionary changes – organic growth

� Revolutionary changes – buying your biggest competitor, new markets

� How do these changes challenge existing functionality?

� Which alternatives are worth investing in?

Who can provide this insight in your organization?Who can provide this insight in your organization?


You Will Never Build a Perfect Service!

� Be happy if you get close enough that the changes areminor

� e.g. adding a field here or there

� Plan for service evolution

� Infrastructure must allow the simultaneous deployment of bothold and new service versions

� Service users can gradually convert to the new version


Architecture Challenges



� Traditional organizational structures

� Organizations and Services

� The Real Situation...

� Project roles

� Impact of component availability


� Enterprise SOA



People Processes

SystemsInformation

The Organizational Issue in theArchitecture Puzzle

� Architectural responsibilities are often organizationally fragmented

� Systems

� Technical Architects

� Network Architects

� Technology selection groups

� Information

� Data Architects

� Processes

� Business Analysts

� People

� Organizations doing the work

� Someone must be responsible for making sure these pieces work together


Organizations in 3-Tier Development

BusinessOwner

BusinessUser

User InterfaceDevelopers

Major SystemOwner

DatabaseAdministrator


Organizations in 2-System Integration

End-PointSystem

End-PointSystem

IntegrationComponents

Workflow


Organizations and Services


Workflow &Process

Automation

PartnerManagement

EnterpriseBackbone

BusinessPartner

BusinessPartner

Peoplesoft SAP Clarify Warehouse Logistics

Connectivity

Business ActivityMonitoring &

User Integration

SupportRep

Customer CustomerManager

Analyst

Op

erat

ion

s

Sta

nd

ard

s&

Sec

uri

ty

Traditional ITOrganizational

Boundaries

The Real Situation Looks More Like This…


Who Defines the Development Process?

Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper

Development

Integration Test QA Production

Business ProcessArchitecture

SystemArchitecture

Charter Requirements

Who manages the process? Who owns the risk?Who manages the process? Who owns the risk?


Key Project Roles

� The Management Team

� Business Executive Sponsor

� Ensures business cooperation - hasauthority over all business ownersinvolved

� Owns the budget for businessservices

� Responsible for the ROI frombusiness services

� IT Executive Sponsor

� Ensures IT cooperation - hasauthority over all IT organizationsinvolved

� Owns the budget for infrastructureservices

� The Project Team

� Project Manager

� Responsible for resources and schedule

� There may be more than one developmentproject!

� Services development

� Using system development

� Business Process Architect

� Responsible for determining if/how servicefits into business process

� Responsible for business ROI justification

� System Architect

� Responsible for determining how the servicewill be implemented

� Responsible for infrastructure ROIjustificationEach Role is Critical to Success!


People Get Things Done

Reques tor Perform er

1: Reques t

2: Prom ise

3: Re sult

4: Feedback

� Humans are tolerant of faults:

� One person asks another to perform work (the request)

� Performer assumes responsibility (the promise)

� Performer delivers the requested result

� Requestor evaluates result and provides feedback

� Either party can respond flexibly to breakdowns in the process


Systems Lack Human Flexibility

RequestingSystem

Requesting System Design andSupport Staff

PerformingSystem

Performing System Design andSupport Staff

1: Request

2: Promise

3: Result

4: Feedback

5: Designed-for Breakdown6: Designed-for Breakdown

� Systems only do what they have been designed to do

� Traditional integration employs only one-way communications

� Omitting the other communications gives up virtually all means ofdetecting breakdowns!


Traditional EAI

Service A

Source System Machine A Machine B Target System

InitiatingApplication Service B

TargetApplication

1

2

3 4

5

6 7

8

9

� Successive steps of information movement and processing may looklike a process…but traditional EAI does not treat it like a managedprocess

There is no breakdown detection in the overall process!There is no breakdown detection in the overall process!


Impact of Component Availability

� Component availability determines process availability

� High-availability components require timely breakdown recovery

99.0%90.4%34.9%Resulting Process Availability for a 10-step Process

99.9%99.0%90.0%Component Availability

8.77 hoursYearly

43 minutesMonthly

10 minutesWeekly

1.2 minutesDaily

Repair Time to Maintain 99.9%Component AvailabilityComponent Failure Frequency


Leveraging the TIBCO ArchitectureMethod




� Positioning architecture in the project lifecycle

� Making architecture development efficient

� When do questions get addressed?

� Enterprise SOA



Define Requirements

Synthesize Architecture

Design, Implement, and Test Components

Assemble and Test System

Deploy and Use System

Business Process Definitions & Other Requirements

Component Structure and Responsibilities

Unit-tested Components

Working System

KnowlegeGained

fromUsing

System

Specify Components

Component Specifications

Budget for Project

Business Benefit, Cost and Schedule Expecations

Positioning Architecture in theProject Life Cycle


Making Architecture Development Efficient

Gather and Analyze

Requirements:

Determine Business

Process Objectives,

Alternatives,

Constraints

Evaluate Business

Process

Alternatives, Identify

and Resolve

Business Risks

Evaluate Architectural

Alternatives, Identify and

Resolve Technical Risks

Assess Project

Feasibility, Plan

Next Phases

Review and Commit

to Next Iteration

Cumulative

Cost

Initial

Feasibility

Assessment

Project “GO”

Decision


TIBCO Architecture Method


Architecture SynthesisBusiness Process Synthesis

X(physical)

X(logical)

How

XWhere

XWhen

XWhy

XWhat

X(within the system)

X(internal or external

to the system)

Who(what participant)

Defined by the ArchitectureDefined by theBusiness Process

Defined by the Activityand Unit of Work

Question?

When Do Questions Get Addressed?


TIBCO Architecture Method Phases

� Define testing and operations guidelines

� Document architecture

Define Tests andDocument

� Evaluate performance capabilities

� Evaluate ability to accommodate both evolutionary and drastic changes

� Evaluate standards compliance

ArchitectureEvaluation

� Components, responsibilities, communication needs

� Network deployment topology

� Communications mechanisms

� Information management policies

� Component activity coordination

� Parallel processing

� Security

� Monitoring

ArchitectureSynthesis

� Use cases selected and prioritized

� Business activity models

Business ProcessAnalysis


Business Processes Identification andGrouping

� Identify business processes

� Group into use cases by common expected result

� Identify key scenarios for use cases

� We want to know the major business processes and variations

� Estimate business impact and risk, occurrence rates, determine requiredcompletion times

� To understand the volume or performance demand on the system

� Identify scenario complexity (system, human involvement)

� To understand which use cases place significant demands on resources

� Business Process Ranking

� Processes with the highest business risk, highest complexity, and mostdemanding performance requirements are ranked highest


Use Case Example: ATM Transaction

Bank Customer

Withdraw Cash

Make Deposit

Transfer Funds

Check Balance


Use common senseUse common sense -- ask about functions you know have toask about functions you know have tobe there somewhere (adding new system users, newbe there somewhere (adding new system users, new

business customers, etc.)business customers, etc.)

Uncover Supporting Use Cases


Business Process CharacteristicsUse Case Business

Process(Scenario)

PeakExecution

Rate

Variation inPeak Rate Over

Time

AllowedCompletion

Time

AverageExecution

Rate

Data VolumePer Execution

At teller 1/second Peaks at lunchhour

3 minutes 16,000/day

1KB

At ATM 32/ second Peaks duringmorning andeveningcommute

30 seconds 139,000/day

1KB

At teller 0.1/ second Peaks at lunchhour

3 minutes 1,600/ day 1KB

At ATM 1/ second Peaks duringmorning andeveningcommute

30 seconds 4,800/ day 1KB

1 every 4hours

Peak during firstfew weeks ofrollout

4hours

2/ month 1.5MB

5/ minute Uniform duringworking day,gap at lunch

2 minutes 333/ day 20KB

100/ hour Peaks at lunchhour

5 minutes 400/day 1 KBIssue ATM Card

WithdrawCash

MakeDeposit

Install ATM Machine

Service ATM Machine


Ranking Business Processes

Data Size(Bytes)

Data SizeRank

100 or less 11K 210K 3

100K 41MB or more 5

CouplingBetween

Participants

Triggering ofWork

Location ofProcess

Definition

Factors DrivingSystem

Complexity

ComplexityRank

Independentsystems, nointegration

Initiated by humaninteraction

External to thesystem.

- All inputs must beprovided by usersand output deliveredto users

1

- Data structuredefinitions and -communicationsmechanisms areshared

- Data movementmust be triggeredand coordinatedwith work.

- Coordinating workperformed in onecomponent withwork performed inothers.

- Detecting andreportingbreakdowns in theprocess

- Representing theprocess and itsvariations

- Assigning work toresources at run-time

- Definingprocesses at run-time.

Data integration Initiated byexternal eventssuch as humaninteraction orcommunications.Data movementdoes not triggerwork

External to thesystem.

2

Processintegration

Initiated byexternal eventsand/orcommunicationswith other systemcomponents

Processdefinition isimplicit in thepattern ofcommunicationsthat trigger workin components

3

Monitoredprocesses andworkflow

Initiated byexternal eventsand/orcommunicationswith other systemcomponents

Processdefinition isexplicitlyrepresented inthe monitor orworkflow engine

4

Peak Rate/Second

Peak RateRank

1 or less 110 2

100 31,000 4

10,000 or over 5

Risk to business if process is notsuccessfully executed

BusinessImpactRank

No measurable impact 1

Minor productivity loss, minor impacton ability to demonstrate regulatorycompliance, bottom line impact notdiscernable

2

Intermediate productivity loss, somemeasurable impact on ability to complywith regulations, some measurableimpact on bottom-line

3

Major productivity loss, inability tocomply with regulations, major impacton bottom-line

4

Catastrophic – unrecoverable businessfailure, loss of life

5


Business Process Ranking

Use Case BusinessProcess

(Scenario)

FrequencyRank

Data SizeRank

ComplexityRank

Risk Rank OverallRank

At teller 1 2 2 4 16At ATM 2 2 3 4 48At teller 1 2 2 4 16At ATM 1 2 3 4 24

1 5 2 3 301 3 2 4 24

Issue ATM Card 1 2 3 3 18

WithdrawCashMakeDepositInstall ATM MachineService ATM Machine


Selected Business Process Scenario

� Withdraw Cashfrom ATM

� Responsibilitiesfor processactivities aremodeled byplacementin swim lanes

� Swim lanesrepresent rolesof participants

Customer:Person

ATM System Bank

insert card and enter PIN

select "Withdraw Cash

enter amount

remove cash

remove card and receip

validate PIN

prompt for transaction

prompt for amoun

obtain disbursalauthorization

Dispense Cash

Success?

print receipt andreturn card

report funds delivered

grant disbursalauthorization

record withdrawaltransaction

(notification acknowledgement

(disbursal authorization)

(dispensing notification)

(card, receipt)

Yes(cash)

(disbursal request)(prompt for amount)

(prompt)

(removal notice)

(amount)

(selected transaction)

(card data, PIN)


Units of work and other deliverables areUnits of work and other deliverables areanother way to help define the scopeanother way to help define the scope

providesServicesThrough

transactsWi

0..*

0..*

is serviced by

provides service for

0..*

1..*

accepts accepted by

0..* 1..*

0..*

1

services has

1..* 1customer

1..* 1Account

Person Bank

Account

+accountNumber:Strin

ATM Card

+PIN:String

ATM System

Bank Server

Just one accountper ATM card?

Important Concepts and Relationships


Customer:Person

ATM Machine BankATM Server

insert card and enter PIN

select "Withdraw Cash

enter amount

remove cash

remove card and receip

validate PIN

prompt for transaction

prompt for amount

obtain disbursalauthorization

Dispense Cash

Success?

print receipt andreturn card

report funds delivered

grant disbursalauthorization

record withdrawaltransaction

Determine Bankand Forward

Determine Bankand Forward

(forwarded notificaton)

(notification acknowledgement)

(forwarded request)


(notification acknowledgemn


(dispensing notification)

(card, receipt)

Yes(cash)

(disbursal request)(prompt for amount)

(prompt)

(removal notice)

(amount)

(selected transaction)

(card data, PIN)

Extended Scenario Showing Architecture


� Initial topology design can be a simplified representation of theactual deployment topology

� Important thing is to identify LAN segments and WAN connections

ATM MahchinesATM_Machine

<<lanSegment>>ATM Machine Lan

<<lanSegment>>ATM System LAN

<<wanSegment>>ATM WAN

ATM Server:ATM_Server

<<lanSegment>>Bank LAN

<<wanSegment>>Bank WAN

Bank Servers:Bank_Server

0..*10..*

Proposed Topology


Architecture Evaluation

� The ability of the architecture to perform adequately

� The feasibility of implementing the architecture within thecost and schedule guidelines

� The ability of the architecture to evolve over time

� The ability of the architecture to accommodate unusualsituations

� Compliance with enterprise standards and architecture


Enterprise SOA




� Enterprise SOA

� Governance

� Mindset

� Organization

� Technical



Governance Is Essential

� For deciding what ought to be a service

� Ensuring ROI

� Limiting speculative service development

� For ensuring those with appropriate insight participate in specifyingthe service

� For ensuring information about services is appropriatelydisseminated to potential users

� For ensuring that services get used and not re-invented

� For coordinating service operation with dependent systems


Mindset Issues

� Services are not about technology

� Services are about cost-effectiveness

� Focus should be on what reusable functionality is needed

� Technology issues are secondary

� Every interface isn’t a service!

� Services involve overhead, both at design and run-time

� Granularity of work must outweigh the overhead

� Must demonstrate potential for reusability (commonality)

� Identify the multiple users of the service

� Make sure that the functionality is, indeed, the same!


Organizational Challenges

Who defines the service? Who pays for it?


Technical Challenges

Is it even possible to use the same service everywhere?Is it even possible to use the same service everywhere?


Technical Best Practices

� Standardize your service delivery mechanisms

� Do it thoughtfully - these will become your standards – mistakes will beexpensive to correct

� You may not get to a single standard!

� You get the ROI from minimizing the variations

� Include event notification as well as request/reply in your thinking!

� Use standards where applicable and appropriate

� Avoid rolling your own (re-inventing an existing wheel)

� Recognize that standards are not yet mature

� e.g. WS-Notification and WS-Eventing

� Modular WS- standards ease the evolution

� Cover the full CRUD cycle in every service!

� Design Create, Read, Update, and Delete for all entities

� Partial coverage almost always requires massive rework to complete, even in theinterface design


The Standards Don’t Cover it All!

� Many standards require infrastructure investments

� WS-Security, WS-Policy require a credentialing infrastructure

� UDDI standardizes the mechanics of accessing information aboutservices, but not the content

� Your own policies and practices must manage the content

� WSDL will not tell you the design intent of the service

� When you should or should not use the service

� You probably want to control and manage the actual access toservices

� Both for capacity planning and for access control purposes

� You need processes for this


Keys to Services Success

� Keep the big picture in focus

� It’s about ROI

� Make sure those with insight participate in servicedefinition and investment decisions

� Assign key responsibilities

� Business Process Architect, Systems Architect, Project Manager

� Provide the authority to make them effective

� Business Executive Sponsor, IT Executive Sponsor


Tools Demonstration

� Architecture and Services

� Organizational Challenges


� Enterprise SOA


� Load analysis


� Identify the scenarios that account for a majority of the work

� Synthesize the architecture for those scenarios

� Component activities, communications, topology

� Evaluate the peak loading

� Of the processes/machines

� Of the network segments

� Interpret the loading in terms of hardware requirements

� Machine sizing and configuration

� Network bandwidth

Load Analysis Technique and Tool Demo



TIBCO Architecture Fundamentals

April 11, 2006



Fundamentals of TIBCO ArchitecturePart 2: Implementing Enterprise Serviceswith TIBCO

April 11, 2006

Paul Asmar – Vice President, Global ArchitectsMedha Samant – Senior Global Architect


Implementing Enterprise Services with TIBCOObjective and Topics

� Formulate strategies for implementing TIBCO productssupporting the SOA vision


� Services Design, Implementation and Orchestration

� Services Deployment

� Scalability / Fault Tolerance



Services Lifecycle Management & Assurance

TIBCORepository

UDDIRegistry

Security &Policy

TIBCO Management & Monitor

Presentation Services

TIBCOPortal

Services

TIBCORich

Clients

NewService

ExistingService

Custom AppsJ2EE/.NET

Adapter

Packaged App TradingPartner

Services

Mainframe

WS WS

DataIntegration

ETL &JDBC

Adapter

TIBCO Integrated Services Environment (ISE)

Services Construction & Orchestration

TIBCO Integration Backbone & ESB

Event ServicesExceptionHandling

Audit &Logging

CrossReferencing

DataMediation

• XSLT

Intelligent

Routing• Subject

• Content

Core ESB Services

WebServices• SOAP

• WSDL

ServiceRuntime

Container� HTTP

� TIBCO EMS

� TIBCO Rendezvous

� MQSeries

� Any JMS

Multi-ProtocolMessage Translation

Transactions

� XA � JTA

Security

� SSL � WSS

TIBCO Integration Backbone & ESBReference Architecture


� Gartner coined the term “ESB”

� Definitions vary wildly

� A product (Gartner, Sonic, …)

� Technology that supports ED-SOA (TIBCO, Forrester)

� A pattern (IBM, who just launched 2 ESB products)

� Optionally contains content-based routing, multi-protocol support, registry,identity management, process orchestration (vendors, customers)

� What is consistent? ESB supports:

� JMS-based asynchronous messaging

� Support for Web services and registries

� Routing and standards based transformation

What Is an Enterprise Service Bus?


Services Infrastructure


� Messaging backbone

� Transport level monitoring and security

� WS Security

� Services Identification, Implementation and Orchestration


� Scalability and Fault Tolerance

� Change Management


TIBCO Enterprise Messaging Service

Pure Java clientlibrary for portability

C-based serverfor performance

Multiple servers may becombined for load-balancingand fault-tolerance

JMSClient

JMSClient

JMSClient

JMSClient

EMSServer

EMSServer

Store File

� Supports JMS specification v1.1

� Store-and-forward architecture

� Robust, highly-scalable performance

� Numerous TIBCO enhancements that retain compliancewith the specification


TIBCO EMS Features

� Security – Authorization and access control, SSL

� Administration

� Fault tolerant server pairs

� Server routing

� Bridging between destinations

� Flow control mechanisms

� C, C#, Java client APIs

� Rendezvous, SmartSockets bridging

� Integration with 3rd party naming services (JNDI)

� Integration with 3rd party application servers

� JBoss, WebSphere, WebLogic, etc.


EMS Server Routing

Server

App AppApp

Server

App AppApp

Route

� Provides load balancing and improved WAN performance

� Persistent messages are written to disk at each server

� Servers forward messages to peers only when there is client interest


EMS Routing Examples

A

B

C

D

� Topic messages can travel one hop or multiple hops(from the first server)

� Queue messages can travel only one hop to the homequeue, and one hop form the home queue


EMS Overlapping Zones Example

1-Hop Zone

1-HopZone

1-HopZone

EMSClient

EMSClient

EMSClient

EMSClient

EMSClient

EMSClient

MultiHop Zone

San Francisco

London

New York


EMS Destination Bridges

� Administratively controlled bridgingbetween client destinations

� Any combination of queues andtopics may be bridged

� Sample use cases:

� Unobtrusively loggingmessages to a database

� Monitoring messages sentto a load-balanced queue

�Bridge

TopicSubscriber

TopicSubscriber

SenderQueue

Receiver

Administrativeobservers

QueueReceiver

Load-balancedworkers


TIBCO Rendezvous®

� Distributed architecture

� Reliable UDP/PGM multicast, broadcast, unicast on the LAN

� TCP-connected software routers for WANs

RV App

RV lib

rvd

rvrd rvrd

RV App

RV lib

rvd

RV App

RV lib

RV App

RV lib

rvd

RV App

RV lib

Host A Host B Host C Host D

LAN LAN

WAN

rvd may beauto started

byapplications


TIBCO Rendezvous Features

� Different QoS

� Reliable

� Guaranteed

� 1-of-n delivery (distributed queues)

� Fault tolerant application groups

� WAN routing

� RVRD – RV Routing Daemon

� RVRD peer-to-peer data compression

� Daemon configuration via HTTP

� Routing daemon subject weights and path costs


TIBCO SmartSockets®

RTclientRTservers

RTclient

RTclient

RTclient

� Mature, stable provider-based publish subscribe

� Best-effort and guaranteed quality-of-service

� Real-time monitoring of infrastructure and applications

� Rich internet application support

� Key markets: Finance & Aerospace


Hybrid Messaging Architecture

JMSClient

JMSClient

JavaApplication

Server

JavaApplication

Server

MDB

EJBTIBCO Enterprise

Messaging Service

CClient

CClient

.NETClient

.NETClient

TIBCO Rendezvous

SmartSockets

TIBCOAdministrator

TIBCOAdministrator


Messaging Option Considerations

When a high fan-out is requiredWhen you want standards-basedintegration

When excessive auditing and tracing isNOT required

When you must integrate withapplications that already support JMS

When minimum administrationoverhead is required

When you must integrate with Javaapplications and/or J2EE app server

When the network structure is changingfast

When message security is a highpriority

TIBCORendezvous

TIBCO EnterpriseMessage Service


Efficient Messaging Design

� Solid and consistent destination naming scheme

� Messages should be self-describing

� Scaling and load-balancing should be considered as part of design

� Be careful about using out of box configuration

� Proper configuration and tuning is required to ensure reliability andperformance of the messaging subsystem

� Persistent messages should only be used when required

� Slow consumers can cause performance degradation in themessage layer

� Age out messages and use exception handler to deal with oldmessages

� EMS persistence is not a database


Services Infrastructure Tuning

� EMS Server

� Pre-allocate file storage

� Set max message memory

� Enable message swapping

� Adjust queue level pre-fetch

� Set ‘reserve_memory’ in case ofemergency

� Disable un-necessary messagetracing, console trace and log trace

� EMS Client

� Make use of EMS routing as per yournetwork layout

� Use ‘message bridging’ for slow topicconsumers

� Use features such as messagecompression, message expiry, whenappropriate

� Disable non-mandatory JMS headers

� Use flow control

� Avoid extensive use of messageselectors

� Choose delivery mode andacknowledgement modes wisely


Distributed Monitoring Architecture

HawkAgent

HawkAgent

AppsApps

TIBCO Messaging

AppLogfile

HawkAgent

HawkAgentHawk

Agent

HawkAgent

AppsApps

HawkAgent

HawkAgent

AppsApps

RuleBases

AMIJMX

Custom ConsoleEM AdvisorTIBCO AdminHawk Display

SNMP PublisherTivoli Adapter Event Service


TIBCO Administrator

� User Management

� Users

� Roles

� Authentication

� Resource Management

� Machines

� Applications

� Domains

� Application Management

� Configuration

� Deployment

� Monitoring


TIBCO Monitoring Domain

� Managed by a TIBCO Administration Server

� Responsible for maintaining server-based projects

� Multiple administration domains may exist on one server

� Each domain must have an associated master server

� Stores user and group information in the domain data store

� Can also sync with LDAP server for users and groups

� SunONE Directory Server, MS Active Directory, Novell eDirectory

� By default, all machines that belong to a domain are expectedto be on the same network subnet

� Can use RVRD if access across subnets is required


EMS Administration

� EMS Administration Utility

� Command-line interface

� TIBCO Administrator

� Web-based GUI

� Custom interface using API

� Provided by EMS (not the JMS spec)


Managing EMS with TIBCOAdministrator

� Use the Domain Utility to add servers

� View information on EMS Server:

� Queues / Topics

� Settings / Statistics

� Connections

� Producers, Consumers

� Routes, Durables

� Etc.

� Edit common server settings, manage queues, topics, and otherfunctionality


Monitoring EMS with TIBCO Hawk

� EMS ships with Hawk Microagent

� tibemsadmin.hma

� Provides methods for monitoring and managing EMS Server

� HawkController class for monitoring and managing

� HawkListener class for monitoring

� Example methods

� Get users, get connections

� Get topics, routes, queues

� Etc.


Using EMS for Hawk NetworkTransport

� Using the loopback address as the RV networkparameter isolates all RV traffic the local machine

� RV is now packaged with Hawk and does notrequire a separate installation

HawkConsole

Agent

EMStibemsd

HMA(AMI App)

rvd

RV Network127.0.0.1

Agent

HMA(AMI App)

rvd

tcp tcp


Infrastructure Security Requirements

� Authentication

� Reliably determining the identity of communicating party

� Authorization

� Granting permission to access a resource

� Encryption

� Scrambling the information so that only someone knowing theappropriate secret can obtain original information (through decryption)

� SSL – Secure Socket Layer

� Protocol for transmitting encrypted data by a way of the Internet orinternal network


Security in TIBCO EMS

� SSL communication between

� Java client and tibemsd server

� C client and tibemsd server

� COBOL client and tibemsd server

� tibemsadmin tool and tibemsd server

� Two routed servers

� Two fault-tolerant servers

� Access control on each destination – Permissions are checked

� On creation of publisher and subscriber on the destination

� On send and receive of each message

� Support for external hardware accelerators


Security in TIBCO RV

� SSL between

� RV app and daemon

� RVSD

� Routing daemon neighbors

� RVSRD

� Browser and daemon

� httpsSingle firewall

Double firewall


Security in TIBCO Administrator

� User Management

� Role-based Access Control (RBAC)

� Management of authentication, roles and users

� Resource Management

� Monitoring of machines and applications in TIBCO Domain

� Application Management

� Creation, configuration, deployment and monitoring of applications

� Directory Synchronization

� Secure (encrypted and authenticated) synchronization with LDAP

� Remote Administration

� HTTPS interface for administration, metadata and deployment configuration


https

User, RoleManagement

Access Control

Secure Communications


Web Service Security in TIBCOBusinessWorks

� BW 5.3 supports WSWS--Security 1.0Security 1.0

� Can encrypt “elements” of a SOAP message withoutencrypting entire message

� WS-Security implemented usingtwo shared resources:

� WS-Security Policy

� WS-Security Policy Association

� Policy-based security means rules can be added or changed withouthaving to modify existing services


WS-Security Policy

� Defines security policy that can be applied to a security subject:

� Authentication Policy

� Username Password Token

� X.509 Token

� Integrity Policy – Based on XML signature

� Username Password Token

� X.509 Token

� Confidentiality Policy – Based on XML encryption

� X.509 Token

� Timeout Policy

� Adds timestamp to SOAP message

� Provides mechanism to reject message based on timestamp


WS-Security Policy Association

� Allows association of WS-Security policies to a security subject

� Security subjects can have Inbound, Outbound, Inbound Fault, andOutbound Fault security policies

� Inbound tab allows users to define signature and encryption policyfor message parts that need to be verified for inbound SOAPmessage

� Outbound tab allows users to define signature and encryption policyfor outbound SOAP message parts


Services Identification, Implementation andOrchestration


� Services Identification, Implementation and Orchestration

� Services identification

� Process design

� Implementing Web Services

� Service engine architecture

� Service orchestration





Common Services on ESB

� Common Services are reusable components that

� Are self-contained

� Have well-defined interface

� Provide consistent behavior and functionality across invocations

� Use standards to ensure interoperability and adaptability across the enterprise

� Are manageable and discoverable through a common framework

� What benefits do they provide?

� Reduce application development effort and complexity

� Enforce consistency

� Provide significant cost savings

� Minimize overall project risk

� Two types:

�� Infrastructure ServicesInfrastructure Services — Auditing, Exception Handling, Cross-referencing

�� Business ServicesBusiness Services — Tax Lookup, Product Pricing, Sales Order Validation


Service Identification

• poor identification of sharedinfrastructure

• expensive and time consuming

• can fail to capture the currentbusiness needs

• can waste time on areas of lesserbusiness importance

1. Develop a Business Process Map

2. Map Applications to Business Process

3. Develop Interface Wire Diagrams

4. Identify Patterns

5. Implement Services

a) All-new service

b) Wrapped service

c) Composite service

Top-Down Approach Bottom-Up Approach1. Audit existing IT assets

a) Examine applications boundariesand business objects

b) Look for CRUD in data producersand consumers

2. Identify infrastructure services

3. Document functionality exposed by each

� Business Unit, Geographic location

4. Document organizational interfaces

� Customers, Partners, Suppliers


Business Justification for SOA Projects

� Project by project (hidden)Build lots of little SOAs

� Part of doing business

� Electronic commerce

� Customer Care

� Provisioning / Fulfillment

� Project by project (visible)Build a single SOA incrementally

� Fix existing Customer Dissatisfaction

� Poor visibility

� Slow execution

� Quality problems

� Faster Time to Market

� Pre-packaged services

� Enterprise strategic investment� Pooling of multiple common project

expenses

� Alignment with strategic business goals

� Mergers and Acquisitions

� New product or service offering

� 360 Degree view of customer

� Reduction of IT expenses

� Six Sigma Initiative

� Regulatory imperative

� Long-term TCO argument

� Insurance policy / Risk Mitigation


TIBCO BusinessWorks™ 5.3


BW EngineTIBCO DesignerTIBCO Administrator

Domain Server

Web Server

Users,Resources

ProjectRepository

Runtime

� Configure applications

� Deploy

� Manage and monitor

� Administer

Design

� Define processes

� Configure services

� Test and debug

� Generate EAR

Distinct BusinessWorks™Environments


TIBCO Designer™

GraphicalGraphicalProcessProcessModelingModeling

NativeNativeStandardsStandardsbased XSLTbased XSLTMapperMapper

Adapters,Adapters,Services,Services,

Processes,Processes,Deployment,Deployment,ManagementManagement

DragDrag--nn--DropDropAccess toAccess to

ResourcesResources

Intuitive graphical design environment streamlinestime and cost of development and training

Intuitive graphical design environment streamlinestime and cost of development and training

Fully IntegratedFully IntegratedTest EnvironmentTest Environment


� Key Working Group participant� Have obtained 100% interoperability

SOAP 1.2Transport

� Member of Expert GroupJBI (JSR 208)Java BusinessIntegration

� Member of OASIS Technical CommitteeWS-SX(SecureExchange)

Security

� Member of OASIS Technical CommitteeWS-TX (Transactions)Transactions

� Actively driving WS-Addressing Working GroupWS-AddressingAddressing

TIBCO LeadershipSpecArea

� Key Working Group participant (contributed expertise in pub/sub messaging)� Pushed for inclusion of sophisticated message exchange patterns

WSDL 2.0Description

� Member of OASIS Technical Committee� WSDM spec ratified as standard and supported by TIBCO products

WSDM (DistributedManagement)

Management &Monitoring

� Member of OASIS Technical Committee and key contributorWS-BPELOrchestration

� Member of WS-Reliable Exchange Technical Committee� Co-author of spec (with Microsoft, IBM and BEA)

WS-ReliableMessagingReliableMessaging

� Co-author of spec (with Microsoft and BEA)WS-EventingEvents

� Co-author and member of Technical Committee� Spec split into WS-BaseNotification, WS-BrokeredNotification and WS-Topics� TIBCO driving consolidation of WS-Eventing and WS-BaseNotification

WS-NotificationsAlerts/Notifications

� Charter and voting member of OASIS Technical Committee� Demonstrated WS-Security Interop at Gartner LA Summit

WS-SecuritySecurity

Standards Leadership and Support


Enabling Asynchronous Services —SOAP over JMS

� SOAP envelope wrapped in a JMS message

� What is the value?

� Reliable message transport with guaranteed delivery

� Secure client communications

� Synchronous andasynchronous services

� Request/Reply andone-way invocation


Designing for Reusability

� Use a standard BW TemplateBW Templatecustomized for your project needs

� Use naming standards for services,processes, adapters, sharedresources and libraries

� Store template under aversion control environment

� This leads to:

� Common look and feel across projects

� Easy to import/export components

� Improved reusability


BW Runtime Engine

� Able to handle a continuous stream of services and processes, each withdozens of activities, in an operating environment with finite critical resources

� i.e., memory, CPUs, threads, connections

� Schedule jobs and give each an equal opportunity to execute

� Provides XML data transformation and validation service

� Evaluate the transitions (XPath) and control the flow

� Perform connection/session management with recovery/retries

� Engine crash and job recovery

� Exception management and logging

� Enables management and monitoring services

� Reduces the need for custom coding of services


*Circled numbers are tunable parameters.

BW 5.3 Engine Architecture

ProcessStarters

1

Connections/Sessions

6

JVM

Heap size

Thread Pool(for Job execution)

3 Max Threads 5

T1 Binding|XSLT|Validate Activity



T-N Binding|XSLT|Validate Activity

Step Count

Checkpoint database

Max Jobs by type

2

Paged Jobs

Reactivate

...D

isp

atch

Qu

eue

(rea

dy

job

s)

Job

Po

ol

(in

mem

ory

)

...

Ready/blocked state

ActivationLimit

4

Queue

Recover

CheckpointOr paged

FlowLimit

7


Engine Tuning Parameters

� Flow limit is important when tuning for high-volume message arrivaland big jobs (memory-intensive)

� Max Jobs is good for big jobs with delays in processing(e.g., request / reply)

� Sequencing is best handled in the process design itself usingsequencing keys

� No longer need to use max jobs / activation limit

� Heap and max threads depend on hardware

� For example, on a 4 CPU machine:

� Having 4 BW engines with 8 threads each is better than1 engine with 32 threads


Transactions

Begin Transaction

End Transaction

Database-1

JMS

Database-2

Delete Data

Insert Data

Publish Message

� A transaction is a logical unit of work

� Group multiple operations into an atomic execution unit

� Operations within a transaction are indivisible

� Either all or none is executed


BW Transaction Manager

Oracle JMSMicrosoft

SQL Server

� Transaction demarcation is provided by the GroupGroup resource

� Transaction is implicitly started at the beginning and terminated atthe end of the transaction group

� Zero coding facility, just drop the activities inside the group

� XA Transaction support for JDBC, JMS, iProcess engine, AE Plug-in


BW 5.3 Features for Services

� Multiple operations per service

� Better SOA Orientation in UI

� One-click WS wizard

� Generate implementation template from WSDL wizard

� WSS: XML DSig and XML Encryption

� SOAP/JMS Topic Support

� WS-I Certification

� UDDI Export at design and deployment time


Service Orchestration

The concept of a flow or process exists at many levels

Message Exchange Patterns

Transactions

Business Process Automation

Distributed Transactions

Human Workflow Form Flow

Business Process Management

Sequencing

B2B Collaboration


BusinessWorks for Service Orchestration

� BusinessWorks orchestrates services to form a complete business process

� Same design / development / deployment / monitoring environment


WS-BPEL

� What is WS-BPEL?

� Defines a syntax for the choreography of existing Web Services.Dependent on WSDL, XML Schema, XPath, etc.

� Features

� Ability to combine block-structured and graph-structuredparadigms

� Ability to specify compensation of faulted scopes

� Event handling

� Late Binding


BusinessWorks and BPEL

� BPEL is not…

� … a way to “export” BW Processes in a Portable Format

� … a “handoff” format, from Business Analyst to Implementer


Exporting a Typical BPM Process toWS-BPEL


Services Deployment




� Deployment Model

� Manual and Automated

� UDDI




Deployment Model –TIBCO Administrator™ 5.3

� DB or file for storing domain data

� Local or server-based for deploying application data

DB

File��

ApplicationData

OR

��

��

��

��

DomainData


TIBCO Application Deployment

� Deployment process includes:

� Binding services to machines

� Hawk rulebase uploading

� Service instance configuration

� e.g. JVM properties

� Fault Tolerance

� Two ways to deploy applications:

� Manual using TIBCO Administrator GUI

� Command-line deployment for automation


Deployed Project

Deployment Using TIBCOAdministrator


Deployment Using Scripts

� Need for scripted deployment

� Minimize the need to use administration GUI (i.e., human interaction)

� Ability to export entire deployment into an XML file

� Ease of re-deployment

�� buildearbuildear – Utility to create application archive

� From an entire project, or

� From a specific resource within a project

�� AppManageAppManage – Utility to upload, configure, deploy, start and stopapplications using script


Publishing Services to UDDI

� BW 5.3 and Administrator 5.3 support UDDI

� Publishing to registry

� Look up from registry


Scalability / Fault Tolerance


� Services Identification, Implementation andOrchestration



� Service load balancing

� Service fault tolerance



BW Engine Load Balancing

� Static

� Manually configured during deployment

� Deploy applications to different engines

� Dynamic

� Process design using process starters:

� JMS Queue Receiver

� RVDQ Subscriber

� Controlled at runtime by messaging system in coordination withBW engine


Load Balancing Using RVDQ

Worker20

Worker30

Worker10

DQ GroupAssign Task

Scheduler40

� At design-time, RVDQ transport is configured and used by BWprocess

� At deployment, engines configured in DQ group

� At runtime, scheduler dynamically distributes workload; workersprocess assigned tasks


� Load balanced Queue receivers

� Load balanced multiple servers

EMS Load Balancing

JMSProducer

JMSProducer

JMS QueueReceiver

JMS QueueReceiver

EMSServer

EMSServer

JMS QueueReceiver

JMS QueueReceiver

JMS QueueReceiver

JMS QueueReceiver

EMSServer1

EMSServer1

JMSClient

JMSClient

JMSClient

JMSClient

EMSServer2

EMSServer2

JMSClient

JMSClient

JMSClient

JMSClient

JMSClient

JMSClient

JMS ClientServer1 | Server2

JMS ClientServer1 | Server2


EMS Fault Tolerance

ActiveServer Heartbeats

(may be redundant)

Shared State

App AppApp

BackupServer

Dual-ported SCSI,SAN, NAS, etc.

Non-ActiveServer

Active server failsShared state lock relinquished

Heartbeats(may be redundant)

Heartbeats stop

App AppApp

Client connections disrupted

ActiveServer

Backup server activatesShared state lock obtained

App AppAppApp AppApp

Client connections re-established


BW Engine Fault Tolerance

� Warm stand-by (backup in wait state)

� Uses RVFT to detect BW process engine failures

� Primary/Secondary

� Peer-to-Peer

� Persistent data transferred via database or file system

� Checkpoints

� Persistent shared variables


Cluster Deployment Considerations

� Understand the underlying clustering software fail-over capabilities:

� Virtual IP addressing

� Redundant data stores

� Mounting shared drives

� Implementation of cluster packages

� Besides component fail-over, the system state also needs to berecovered:

� Persistent message data stores, log files, BW checkpoints, etc.

� Do not confuse TIBCO built-in fault tolerance techniques with what isprovided by clustering software

� Avoid multiple controlling mechanisms if possible


Lifecycle Management






� Project environments

� Services lifecycle


� Development & Unit Test

� Multiple developers

� Own domains

� Project synched to VCS

� Integration Test / QA

� Multiple machines

� Single domain

� Mirrors productionenvironment

� Production

� Multiple machines

� Single domain

fsaf

fadsfafdsa

VCS

Domain Dev A Domain Dev B Domain Dev C

Domain Prod

fadsfafdsa

Domain QA

Environments Supporting ProjectLifecycle


Environment Planning

� Frequency and size of information flow (including projected growth):

� Average and peak rates of transactions

� Average and peak rates of messages

� Average message size

� How messages are distributed among components and machines

� Help determine any latency requirements for components

� Response time requirements

� Storage capacity needs:

� Amount of persistent messages queued in messaging layer

� Amount of runtime data kept (e.g. logs, information stored in databases)

� Fault Tolerance requirements


Capacity Planning Recommendations

� Based on capacity and fail-over requirements:

� Calculate roughly how many BW engines are required

� Determine messaging infrastructure requirements (e.g. # EMS servers)

� Understand adapter requirements (e.g. SAP, Siebel, ADB)

� Calculate rough estimates for CPU and RAM requirements:

� Rule of thumb: # BW engines per machine should not exceed # CPU’s (up to 2x)

� Memory requirements can be estimated once components are determined

� Assess network load requirements based on size and frequency ofmessages

� Determine if network bandwidth can support the underlying infrastructure

� Derive a capacity test plan:

� To test estimates early on in the development cycle

� For end to end performance testing in QA environment


Version Control

� BW supports version control to increase reusability and productivityby sharing project objects among developers

� A typical BW multi-developer project can be divided into differentfunctional groups and mapped to the folder structures in the BWproject template

� Check-in / out project components using supported RCS

� Visual Source-Safe, Perforce, ClearCase, XML Canon

� Check-in / out project components using other RCS tools

� Open project in Designer with “File Sharing” option selected

� Developer can only work on objects with assigned privileges


Design-time Version Control Support


Overview of Environment Migration

Extract EAR files

Deploy into QAenvironment

ConfigureGlobal Variables

Run componentsin QA

QAExtract EAR files

Deploy into Productionenvironment

ConfigureGlobal Variables

Run componentsin Production

Production

Project LifecycleProject Lifecycle

Project V-file structure

Build and debug projectin TIBCO Designer

Project stored inVCS

Development

Generate EARfiles for deployment

SAR

EAR

PAR

AAR

SAR

EAR

PAR

AAR


Use of Global Variables

� All environment related parameters should be globalvariables

� Infrastructure related parameters

� Network services and ports, EMS Server configuration,destinations, etc.

� End system parameters

� Application login IDs, server connection parameters, etc.

� File and database parameters

� Directory and file location, database connection, etc.


Services Lifecycle

ServiceChange

Required

LinkService

RequestService Access

Implement ServiceAccess

Identify Service toBe Used

Utilize Service

Gates:

Deliverables: None Service Access Request None Service Metrics

None Service Access Approval None None

Gate Keeper: None Services Librarians None None

OperateService Start Service Schedule Service

ShutdownSchedule Service Start Stop Service

Gates:

Deliverables: Service Start Schedule Condition Requiring Shutdown Service Shutdown Schedule None

Start Schedule Approval None Shutdown Schedule Approval None

Service Ready to be Started

Gate Keeper: Services Librarians None Services Librarians None

RetireService Retire ServiceRequest Services

Retirement

Gates:

Deliverables: Service Retirement Request Service Retirement Announcement

Service Retirement Approval None

End

Gate Keeper: IT Steering Committee None

Build &Deploy Service

Propose New orChange to Service

Deliverables: Service Proposal

Refer to Implementation Project Life Cycle starting with Requirements Phase

Design, Build, and TestService

Deploy Service andService Usage Info

Design Artifacts Deployable ComponentsService Discovery ArtifactsService Access Procedures

Develop Service Spec andEstimates

Service Specification

Start

Gate Keeper: It Steering Committee Enterprise Architecture Services LibrariansIT Steering Committee

Gates: Proposal Approval Deployment Approval Service ReadyProject Approval

A governance process thatA governance process thatspans the entire Servicesspans the entire Services

Life Cycle is needed!Life Cycle is needed!



Fundamentals of TIBCO Architecture

Thank You for Your Attendance

April 11, 2006

tucon 2006 fundamentals of tibco architecutre

Documents