TUCON 2006 Fundamentals of TIBCO Architecutre

TIBCO Architecture Fundamentals
Program Overview
April 11, 2006
Paul Asmar – Vice President, Global Architects
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 and
services. 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 this
document 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 particular
purpose. This document may not be reproduced or transmitted in any form or by any means without our prior written permission.
Program Agenda
S Architecture Discussion S Implementing Enterprise

S Architecture and Services
Services with TIBCO®
Overview S Services Infrastructure
S Architecture Challenges S Services Identification,
Implementation and
S Leveraging the TIBCO
Orchestration
Architecture Method
S Service Deployment
S Enterprise SOA
S Scalability/Fault Tolerance
S Tools Demonstration
S Lifecycle Management
TIBCO USER CONFERENCE / 2006 2

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.
What Is an SOA?
S An architecture that enables IT to compose applications from

services, and that promotes greater reuse and flexibility
S Benefits of SOA:
S Simplify – Leverage assets, deliver new functionality more easily
S Open – Reduce costs, risk and vendor lock-in
S Accelerate – Rollout new functionality faster (Agility)
S Enabling technologies for SOA:
S Services – Service development, deployment, management
S Events – Capture, process and deliver events
S Integration – Adapters and integration services
S Mediation – ESB
S Processes – Orchestration

Architecture Evolution: How We Got to SOA
Through Messaging and Integration
Big Iron Client-Server Web Apps SOA
’01-
’95-’01 • “N-tier” services
’85-’95 • 3-tier (UI/logic/data) • UDDI/SOAP/WSDL
Pre-1985 • 2-tier • EAI (processes) • ESB Technology
• Web servers
• Monolithic • RPC, Messaging
• Java/J2EE/JMS
Services
Processes Processes
Events
Mediation Mediation
Events Events

TIBCO’s View of SOA
Automate and Improve

streamline operational
business visibility and
processes responsiveness
Accelerate projects,
initiatives, and
go-to-market cycles

Part 1: Architecture Discussion
April 11, 2006
Paul Brown – Principal Software Architect
Architecture Discussion:
Objective and Topics
S Describe fundamental principles for architecting TIBCO

projects and experience supporting tools and methods
S Architecture and Services Overview
S Architecture Challenges
S Leveraging the TIBCO Architecture Method
S Enterprise SOA
+ + =
Architecture and Services Overview

S What Is Architecture?
S The Scope of Architecture
S The Business Process Connection
S Services
S Enterprise SOA

What Is Architecture?
S Architecture is the characterization of the physical structure

and the logical organization of a system
S Physical Structure — Components and their physical arrangement
S Software on machines, machines on networks
S Machines, networks, and minor components form the infrastructure
S Logical Organization — Component roles and responsibilities with
respect to the business process(es) the system is intended to support
S Who performs what work, when, and under what conditions?
S Who owns what information, how is it accessed and distributed?
S Who monitors, manages, and reports on the overall work process?

What Are We Designing?
S A large-scale system-of-systems
S The major components are systems in their own right
S Each independently performs useful functions for the enterprise
S We are integrating these systems to improve the overall business
S The business processes (by definition) span multiple systems
S We have limited (if any) control over the major systems themselves
S Yet we are responsible for getting them to work together
S The only tool we have to work with is communications with those systems
S To move data
S To coordinate work
S To obtain status
S To monitor and manage the process

Architecture Has Broad Scope

Business Process Design Impacts
Architecture
S Business processes make design assumptions about what systems

can and should be doing: functions provided, interfaces needed,
data and process management
S Inappropriate assumptions lead to ugly system designs and ungainly
business processes
S For best results, work process design should be a collaborative effort
between business and technical people
S Focus on finding a good marriage between business needs and
technical realities
S Achieve business goals
S Practical and cost effective from a technology perspective
S Make sure both sides are aware of “care and feeding” activities
S e.g., administering credentials/qualifications, maintaining
reference data

Business Processes and
Architecture Are Inseparable
S Business process defines the interplay between:

TOT A L
S The people using the system
S The systems themselves People Processes
S The information used in the work

process components (traditional architecture) Information Systems
RE
AR
S Architecture defines the roles of system
C
components with respect to the work H I T CT U
processes, information and people: E
S Which components participate in which activities
S Which components manage which pieces of information
S Which components are involved in which human interactions
A good architecture demands a clear understanding

of these relationships!
What Is the TIBCO Architect’s Job?
S Design a system that:

None
Hurts Doesn't
S Supports the work processes Negative Business
Process
Justify
Cost Good Positive
S Provides the expected benefit

S Can be delivered within the
project cost and schedule
guidelines Architecture Benefit
Meter
S Does this with acceptable risks in:

S Work process disruption
S Ability to achieve the benefit
S Ability to execute within cost and schedule guidelines
If you find that you “can’t get there from here,” blow the whistle loud
and early! Saving time and resources leaves more options open.
What the Architect Must Know about
the Business
S What is the Business Process and how will it change?

S e.g., Automate order entry so customers can enter their own orders
S What are the expected quantifiable benefits?
S Improve order processing productivity by 20% to support anticipated acquisitions
without hiring additional personnel
S What are the cost and schedule constraints?
S The business requires the capability within 9 months at a cost not to exceed
$450K in order to complete the planned acquisition
S How does the business process handle breakdowns?
S If the credit check service is unavailable, accept low-value orders without
checking and manually approve high-value orders
S What is the risk if the business process breaks down?
S If the productivity benefit falls below 10%, the company will operate at a loss; or if
the system is not available 99.9% of the time the productivity benefit will be lost

Services
S What is a service?
S A commonly used unit of functionality
S e.g. Sales Order Management
S Packaged for consistent re-use
S Becomes a de-facto standard
S The goal is to save money!

S Standardize the function so that what the next project (process) needs is
already there
S Most functionality already exists

S In one system, but accessed many ways
S In multiple systems

Typical Service Architecture
S A service is a reusable unit of functionality with standardized interfaces

S A business service is a unit of business process functionality exposed
as a service so that it is available to a wider audience
Using O Either Company or

Component Application-Specific
Semantics for the
Using operation depending on
Component the level of service
abstraction.
O Native semantics for O Company standard
operation and data semantics for data
O Native technology for Service O Company standard
operation and data Interface technology for operation
and data
Native Service
Interface O Native semantics for
Provider of operation and data
Functionality O Native technology for
operation and data
Native
Traditional Object/ Interface
Component Provider of
Approach Functionality
Service Approach

Business and Infrastructure Services Differ!
S Business Services encapsulate portions of business processes

S e.g. “Place Sales Order” or “Invoice Customer”
S The requirements come from the business community
S The users are future business processes
S Infrastructure Services encapsulate portions of system processes

S e.g. “Report error” or “Make Audit Entry”
S The requirements come from the technical community
S The users are future technical projects
Different organizations are involved!

The Reusability Challenge
S How do we design for future usages?

S Today we enter orders in person, via paper, by phone, on-line, …
S What’s next – via Blackberry? Automatic re-order?
S Your CPG firm decides to sell branded clothing as a promotion!
S Orders now need sizes, colors, etc.
S Insight is required when conceptualizing a service
S What might change in the future?
S Evolutionary changes – organic growth
S Revolutionary changes – buying your biggest competitor, new markets
S How do these changes challenge existing functionality?
S Which alternatives are worth investing in?
Who can provide this insight in your organization?

You Will Never Build a Perfect Service!
S Be happy if you get close enough that the changes are

minor
S e.g. adding a field here or there
S Plan for service evolution

S Infrastructure must allow the simultaneous deployment of both
old and new service versions
S Service users can gradually convert to the new version

Architecture Challenges

S Traditional organizational structures
S Organizations and Services
S The Real Situation...
S Project roles
S Impact of component availability

S Enterprise SOA

The Organizational Issue in the
Architecture Puzzle
S Architectural responsibilities are often organizationally fragmented

S Systems
S Technical Architects
S Network Architects
People Processes
S Technology selection groups
S Information
S Data Architects
S Processes
S Business Analysts Information Systems
S People
S Organizations doing the work
S Someone must be responsible for making sure these pieces work together

Organizations in 3-Tier Development
Business
Owner
Business
User
User Interface
Developers
Major System
Owner
Database
Administrator

Organizations in 2-System Integration
Workflow
End-Point Integration End-Point

System Components System

Organizations and Services

The Real Situation Looks More Like This…
Customer Support Customer Analyst

Rep Manager
Business Activity
Monitoring &
Standards & Security
User Integration
Operations
Workflow &
Process
Automation
Connectivity Enterprise
Backbone
Peoplesoft SAP Clarify Warehouse Logistics
Business Business
Partner Partner
Traditional IT Partner
Organizational Management
Boundaries

Who Defines the Development Process?
Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper
Business Process
Architecture
Charter Requirements
Integration Test QA Production
System
Architecture
Development
Who manages the process? Who owns the risk?

Key Project Roles
S The Management Team S The Project Team

S Business Executive Sponsor S Project Manager
S Ensures business cooperation - has S Responsible for resources and schedule
authority over all business owners
involved S There may be more than one development
project!
S Owns the budget for business
services S Services development
S Responsible for the ROI from S Using system development
business services
S Business Process Architect
S IT Executive Sponsor
S Responsible for determining if/how service
S Ensures IT cooperation - has fits into business process
authority over all IT organizations
involved S Responsible for business ROI justification
S Owns the budget for infrastructure S System Architect

services S Responsible for determining how the service
will be implemented
S Responsible for infrastructure ROI
justification
Each Role is Critical to Success!

People Get Things Done
S Humans are tolerant of faults:

S One person asks another to perform work (the request)
S Performer assumes responsibility (the promise)
S Performer delivers the requested result
S Requestor evaluates result and provides feedback
4: F eedbac k
1: Reques t
Reques tor P erform er
2: P rom is e
3: Re s ult
S Either party can respond flexibly to breakdowns in the process

Systems Lack Human Flexibility
S Systems only do what they have been designed to do

S Traditional integration employs only one-way communications
Performing System Design and

Requesting System Design and Support Staff
Support Staff
4: Feedback
6: Designed-for Breakdown
5: Designed-for Breakdown
1: Request
Requesting Performing
System System
2: Promise
3: Result
S Omitting the other communications gives up virtually all means of

detecting breakdowns!

Traditional EAI
Initiating Target
Application Service A Service B
Application
1 3 4 6 7 9
Source System Machine A Machine B Target System
2 5 8
S Successive steps of information movement and processing may look

like a process…but traditional EAI does not treat it like a managed
process
There is no breakdown detection in the overall process!

Impact of Component Availability
S Component availability determines process availability
Component Availability 90.0% 99.0% 99.9%

Resulting Process Availability for a 10-
step Process 34.9% 90.4% 99.0%
S High-availability components require timely breakdown recovery
Repair Time to Maintain 99.9%

Component Failure Frequency Component Availability
Daily 1.2 minutes
Weekly 10 minutes
Monthly 43 minutes
Yearly 8.77 hours

Leveraging the TIBCO Architecture
Method

S Positioning architecture in the project lifecycle
S Making architecture development efficient
S When do questions get addressed?
S Enterprise SOA

Positioning Architecture in the
Project Life Cycle
Budget for Project
Business Benefit, Cost and Schedule Expecations
Define Requirements
Business Process Definitions & Other Requirements
Synthesize Architecture
Knowlege Component Structure and Responsibilities

Gained
from Specify Components
Using
System Component Specifications
Design, Implement, and Test Components
Unit-tested Components
Assemble and Test System
Working System
Deploy and Use System

Making Architecture Development Efficient
Cumulative
Gather and Analyze Cost Evaluate Business
Requirements: Process
Determine Business Alternatives, Identify
Process Objectives, and Resolve
Alternatives, Business Risks
Constraints
Review and Commit

to Next Iteration Initial
Project “GO” Feasibility
Decision Assessment
Assess Project
Feasibility, Plan Evaluate Architectural
Next Phases Alternatives, Identify and
Resolve Technical Risks

TIBCO Architecture Method

When Do Questions Get Addressed?
Business Process Synthesis Architecture Synthesis
Question? Defined by the Activity Defined by the Defined by the Architecture

and Unit of Work Business Process
Who
(what participant)
X X
(internal or external (within the system)
to the system)
What
X
Why
X
When
X
Where
X
How
X X
(logical) (physical)

TIBCO Architecture Method Phases
Business Process Y Use cases selected and prioritized
Analysis Y Business activity models
Y Components, responsibilities, communication needs
Y Network deployment topology
Y Communications mechanisms
Y Information management policies
Architecture
Synthesis Y Component activity coordination
Y Parallel processing
Y Security
Y Monitoring
Architecture Y Evaluate performance capabilities
Evaluation Y Evaluate ability to accommodate both evolutionary and drastic changes
Y Evaluate standards compliance
Define Tests and Y Define testing and operations guidelines
Document Y Document architecture

Business Processes Identification and
Grouping
S Identify business processes

S Group into use cases by common expected result
S Identify key scenarios for use cases

S We want to know the major business processes and variations
S Estimate business impact and risk, occurrence rates, determine required

completion times
S To understand the volume or performance demand on the system
S Identify scenario complexity (system, human involvement)

S To understand which use cases place significant demands on resources
S Business Process Ranking

S Processes with the highest business risk, highest complexity, and most
demanding performance requirements are ranked highest

Use Case Example: ATM Transaction
Make Deposit
Transfer Funds
Bank Customer Check Balance
Withdraw Cash

Uncover Supporting Use Cases
Use common sense - ask about functions you know have to

be there somewhere (adding new system users, new
business customers, etc.)

Business Process Characteristics
Use Case Business Peak Variation in Allowed Average Data Volume
Process Execution Peak Rate Over Completion Execution Per Execution
(Scenario) Rate Time Time Rate
Withdraw At teller 1/second Peaks at lunch 3 minutes 16,000/ 1KB

Cash hour day
At ATM 32/ second Peaks during 30 seconds 139,000/ 1KB
morning and day
evening
commute
Make At teller 0.1/ second Peaks at lunch 3 minutes 1,600/ day 1KB
Deposit hour
At ATM 1/ second Peaks during 30 seconds 4,800/ day 1KB
morning and
evening
commute
Install ATM Machine 1 every 4 Peak during first 4 2/ month 1.5MB
hours few weeks of hours
rollout
Service ATM Machine 5/ minute Uniform during 2 minutes 333/ day 20KB
working day,
gap at lunch
Issue ATM Card 100/ hour Peaks at lunch 5 minutes 400/day 1 KB
hour

Ranking Business Processes
Coupling Triggering of Location of Factors Driving Complexity
Peak Rate/ Peak Rate Data Size Data Size Between Work Process System Rank
Second Rank (Bytes) Rank Participants Definition Complexity
1 or less 1 100 or less 1 Independent Initiated by human External to the - All inputs must be 1
10 2 1K 2 systems, no interaction system. provided by users
100 3 10K 3 integration and output delivered
1,000 4 100K 4 to users
10,000 or over 5 1MB or more 5 Data integration Initiated by External to the - Data structure 2
external events system. definitions and -
such as human communications
Risk to business if process is not Business
interaction or mechanisms are
successfully executed Impact communications. shared
Rank Data movement
- Data movement
does not trigger
must be triggered
No measurable impact 1 work
and coordinated
with work.
Minor productivity loss, minor impact 2
Process Initiated by Process - Coordinating work 3
on ability to demonstrate regulatory integration external events definition is performed in one
compliance, bottom line impact not and/or implicit in the component with
discernable communications pattern of work performed in
with other system communications others.
Intermediate productivity loss, some 3 components that trigger work - Detecting and
measurable impact on ability to comply in components reporting
with regulations, some measurable breakdowns in the
process
impact on bottom-line
Monitored Initiated by Process - Representing the 4
processes and external events definition is process and its
Major productivity loss, inability to 4
workflow and/or explicitly variations
comply with regulations, major impact communications represented in - Assigning work to
on bottom-line with other system the monitor or resources at run-
components workflow engine time
Catastrophic – unrecoverable business 5 - Defining
failure, loss of life processes at run-
time.

Business Process Ranking
Use Case Business Frequency Data Size Complexity Risk Rank Overall
Process Rank Rank Rank Rank
(Scenario)
Withdraw At teller 1 2 2 4 16
Cash At ATM 2 2 3 4 48
Make At teller 1 2 2 4 16
Deposit At ATM 1 2 3 4 24
Install ATM Machine 1 5 2 3 30
Service ATM Machine 1 3 2 4 24
Issue ATM Card 1 2 3 3 18

Selected Business Process Scenario
Customer: ATM System Bank
Person
S Withdraw Cash insert card and enter PIN
from ATM (card data, PIN) validate PIN
S Responsibilities prompt for transaction
for process (prompt)

select "Withdraw Cash
activities are
modeled by (selected transaction) prompt for amoun
placement
enter amount (prompt for amount) (disbursal request)
in swim lanes
obtain disbursal grant disbursal
(amount)
S Swim lanes authorization authorization
represent roles Success?

(disbursal authorization)
of participants Yes
(cash) Dispense Cash
(dispensing notification)
record withdrawal
remove cash report funds delivered transaction
(notification acknowledgement
(removal notice) print receipt and
return card
remove card and receip
(card, receipt)

Important Concepts and Relationships
Units of work and other deliverables are

another way to help define the scope
Person Bank Bank Server
1..* Account 1 1..* 1
customer services has
Account
1..* provides service for 0..* transactsWi
+accountNumber:Strin
Just one account 1

per ATM card?
0..*
0..* is serviced by
ATM Card
ATM System
+PIN:String 0..* 1..*
0..*
accepts accepted by
providesServicesThrough

Extended Scenario Showing Architecture
Customer: ATM Machine ATM Server Bank
Person
insert card and enter PIN
(card data, PIN) validate PIN
prompt for transaction
(prompt)
select "Withdraw Cash
(selected transaction) prompt for amount
enter amount (prompt for amount) (disbursal request) (forwarded request)
obtain disbursal Determine Bank grant disbursal

(amount)
authorization and Forward authorization
(disbursal authorization) (disbursal authorization)

Success?
Yes
(cash) Dispense Cash
(dispensing notification) (forwarded notificaton)
Determine Bank record withdrawal
remove cash report funds delivered and Forward transaction
(removal notice) print receipt and (notification acknowledgement) (notification acknowledgemn

return card
remove card and receip
(card, receipt)

Proposed Topology
S Initial topology design can be a simplified representation of the

actual deployment topology
S Important thing is to identify LAN segments and WAN connections
ATM Mahchines ATM Server:
ATM_Machine ATM_Server Bank Servers:
Bank_Server
0..* 1
0..*
<<lanSegment>> <<lanSegment>> <<lanSegment>>

ATM Machine Lan ATM System LAN Bank LAN
<<wanSegment>> <<wanSegment>>
ATM WAN Bank WAN

Architecture Evaluation
The ability of the architecture to perform adequately

The feasibility of implementing the architecture within the
cost and schedule guidelines
The ability of the architecture to evolve over time
The ability of the architecture to accommodate unusual
situations
Compliance with enterprise standards and architecture

Enterprise SOA

S Enterprise SOA
S Governance
S Mindset
S Organization
S Technical

Governance Is Essential
S For deciding what ought to be a service

S Ensuring ROI
S Limiting speculative service development
S For ensuring those with appropriate insight participate in specifying

the service
S For ensuring information about services is appropriately
disseminated to potential users
S For ensuring that services get used and not re-invented
S For coordinating service operation with dependent systems

Mindset Issues
S Services are not about technology

S Services are about cost-effectiveness
S Focus should be on what reusable functionality is needed
S Technology issues are secondary
S Every interface isn’t a service!

S Services involve overhead, both at design and run-time
S Granularity of work must outweigh the overhead
S Must demonstrate potential for reusability (commonality)
S Identify the multiple users of the service
S 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?

Technical Best Practices
S Standardize your service delivery mechanisms

S Do it thoughtfully - these will become your standards – mistakes will be
expensive to correct
S You may not get to a single standard!
S You get the ROI from minimizing the variations
S Include event notification as well as request/reply in your thinking!
S Use standards where applicable and appropriate
S Avoid rolling your own (re-inventing an existing wheel)
S Recognize that standards are not yet mature
S e.g. WS-Notification and WS-Eventing
S Modular WS- standards ease the evolution
S Cover the full CRUD cycle in every service!
S Design Create, Read, Update, and Delete for all entities
S Partial coverage almost always requires massive rework to complete, even in the
interface design

The Standards Don’t Cover it All!
S Many standards require infrastructure investments

S WS-Security, WS-Policy require a credentialing infrastructure
S UDDI standardizes the mechanics of accessing information about

services, but not the content
S Your own policies and practices must manage the content
S WSDL will not tell you the design intent of the service
S When you should or should not use the service
S You probably want to control and manage the actual access to

services
S Both for capacity planning and for access control purposes
S You need processes for this

Keys to Services Success
Keep the big picture in focus

S It’s about ROI
Make sure those with insight participate in service

definition and investment decisions
Assign key responsibilities
S Business Process Architect, Systems Architect, Project Manager
Provide the authority to make them effective

S Business Executive Sponsor, IT Executive Sponsor

Tools Demonstration
Architecture and Services

Organizational Challenges
Leveraging the TIBCO Architecture Method
Enterprise SOA
Tools Demonstration
S Load analysis

Load Analysis Technique and Tool Demo
S Identify the scenarios that account for a majority of the work

S Synthesize the architecture for those scenarios
S Component activities, communications, topology
S Evaluate the peak loading

S Of the processes/machines
S Of the network segments
S Interpret the loading in terms of hardware requirements

S Machine sizing and configuration
S Network bandwidth

April 11, 2006
Fundamentals of TIBCO Architecture
Part 2: Implementing Enterprise Services
with TIBCO
April 11, 2006
Paul Asmar – Vice President, Global Architects

Medha Samant – Senior Global Architect
Implementing Enterprise Services with TIBCO
Objective and Topics
Formulate strategies for implementing TIBCO products

supporting the SOA vision
S Services Infrastructure
S Services Design, Implementation and Orchestration
S Services Deployment
S Scalability / Fault Tolerance

TIBCO Integration Backbone & ESB
Reference Architecture
TIBCO Integrated Services Environment (ISE)
Services Construction & Orchestration

Custom Apps Packaged App Mainframe Trading Data
J2EE/.NET Partner Integration
Adapter Adapter Services
New Existing
ETL &
Service Service WS WS JDBC
TIBCO Integration Backbone & ESB

Core ESB Services Cross Exception
Multi-Protocol Event Services Referencing Handling
Web Data Intelligent Service Message Translation
Services Mediation Routing Runtime S HTTP S MQSeries
Transactions Security
• SOAP • XSLT • Subject Container S TIBCO EMS S Any JMS Audit &
S XA S JTA S SSL S WSS Logging
• WSDL • Content S TIBCO Rendezvous
TIBCO TIBCO
TIBCO UDDI Security & Portal Rich
Repository Registry Policy Services Clients
Services Lifecycle Management & Assurance Presentation Services
TIBCO Management & Monitor

What Is an Enterprise Service Bus?
S Gartner coined the term “ESB”

S Definitions vary wildly
S A product (Gartner, Sonic, …)
S Technology that supports ED-SOA (TIBCO, Forrester)
S A pattern (IBM, who just launched 2 ESB products)
S Optionally contains content-based routing, multi-protocol support, registry,
identity management, process orchestration (vendors, customers)
S What is consistent? ESB supports:

S JMS-based asynchronous messaging
S Support for Web services and registries
S Routing and standards based transformation

Services Infrastructure
S Messaging backbone
S Transport level monitoring and security
S WS Security
S Services Identification, Implementation and Orchestration

S Scalability and Fault Tolerance
S Change Management

TIBCO Enterprise Messaging Service
Supports JMS specification v1.1

Store-and-forward architecture
Robust, highly-scalable performance
Numerous TIBCO enhancements that retain compliance
with the specification
C-based server
for performance
JMS
JMS EMS
EMS JMS
JMS
Client
Client Server Client
Client
Server
Pure Java client Multiple servers may be
library for portability Store File combined for load-balancing
and fault-tolerance

TIBCO EMS Features
S Security – Authorization and access control, SSL

S Administration
S Fault tolerant server pairs
S Server routing
S Bridging between destinations
S Flow control mechanisms
S C, C#, Java client APIs
S Rendezvous, SmartSockets bridging
S Integration with 3rd party naming services (JNDI)
S Integration with 3rd party application servers
S JBoss, WebSphere, WebLogic, etc.

EMS Server Routing
S Provides load balancing and improved WAN performance

S Persistent messages are written to disk at each server
S Servers forward messages to peers only when there is client interest
Route
Server Server
App App App App App App

EMS Routing Examples
Topic messages can travel one hop or multiple hops

(from the first server)
Queue messages can travel only one hop to the home
queue, and one hop form the home queue
A C
B D

EMS Overlapping Zones Example
EMS
EMS
Client
Client
1-Hop
Zone
San Francisco
London
Multi
Hop Zone EMS
EMS
Client
Client
1-Hop Zone
1-Hop
EMS
EMS Zone
Client
Client
New York

EMS Destination Bridges
S Administratively controlled bridging S Sample use cases:

between client destinations
S Unobtrusively logging
S Any combination of queues and messages to a database
topics may be bridged
S Monitoring messages sent
to a load-balanced queue
Queue
Sender Receiver
Load-balanced
ÅBridge Queue
workers
Receiver
Topic
Subscriber
Administrative
observers
Topic
Subscriber

TIBCO Rendezvous®
Distributed architecture
S Reliable UDP/PGM multicast, broadcast, unicast on the LAN
S TCP-connected software routers for WANs
Host A Host B Host C Host D
RV App RV App RV App RV App RV App

RV lib RV lib RV lib RV lib RV lib
rvd may be
rvd rvd rvd auto started
by
applications
LAN LAN
rvrd rvrd
WAN

TIBCO Rendezvous Features
S Different QoS
S Reliable
S Guaranteed
S 1-of-n delivery (distributed queues)

S Fault tolerant application groups
S WAN routing
S RVRD – RV Routing Daemon
S RVRD peer-to-peer data compression
S Daemon configuration via HTTP

S Routing daemon subject weights and path costs

TIBCO SmartSockets®
S Mature, stable provider-based publish subscribe

S Best-effort and guaranteed quality-of-service
S Real-time monitoring of infrastructure and applications
S Rich internet application support
S Key markets: Finance & Aerospace RTclient
RTservers
RTclient RTclient
RTclient

Hybrid Messaging Architecture
JMS
JMS CC .NET
.NET
Client
Client Client
Client Client
Client
Java
Java
Application
Application
Server
Server
SmartSockets MDB
EJB
TIBCO Enterprise
Messaging Service
TIBCO Rendezvous
TIBCO
TIBCO
Administrator
Administrator

Messaging Option Considerations
TIBCO Enterprise TIBCO

Message Service Rendezvous
When you want standards-based When a high fan-out is required
integration
When message security is a high When the network structure is changing
priority fast
When you must integrate with Java When minimum administration
applications and/or J2EE app server overhead is required
When you must integrate with When excessive auditing and tracing is
applications that already support JMS NOT required

Efficient Messaging Design
S Solid and consistent destination naming scheme

S Messages should be self-describing
S Scaling and load-balancing should be considered as part of design
S Be careful about using out of box configuration
S Proper configuration and tuning is required to ensure reliability and
performance of the messaging subsystem
S Persistent messages should only be used when required
S Slow consumers can cause performance degradation in the
message layer
S Age out messages and use exception handler to deal with old
messages
S EMS persistence is not a database

Services Infrastructure Tuning
S EMS Server S EMS Client

S Pre-allocate file storage S Make use of EMS routing as per your
network layout
S Set max message memory
S Use ‘message bridging’ for slow topic
S Enable message swapping consumers
S Adjust queue level pre-fetch S Use features such as message
S Set ‘reserve_memory’ in case of compression, message expiry, when
emergency appropriate
S Disable un-necessary message S Disable non-mandatory JMS headers

tracing, console trace and log trace S Use flow control
S Avoid extensive use of message
selectors
S Choose delivery mode and
acknowledgement modes wisely

Distributed Monitoring Architecture
App
Log
Apps Apps
Apps Apps
Apps file
Apps
AMI
JMX
Hawk
Hawk
Hawk
Hawk Hawk
Hawk Hawk
Hawk
Rule Agent
Agent
Agent
Agent Agent
Agent Agent
Agent Bases
TIBCO Messaging
Hawk Display TIBCO Admin EM Advisor Custom Console
Tivoli Adapter SNMP Publisher Event Service

TIBCO Administrator
S User Management
S Users
S Roles
S Authentication
S Resource Management
S Machines
S Applications
S Domains
S Application Management
S Configuration
S Deployment
S Monitoring

TIBCO Monitoring Domain
S Managed by a TIBCO Administration Server

S Responsible for maintaining server-based projects
S Multiple administration domains may exist on one server

S Each domain must have an associated master server
S Stores user and group information in the domain data store

S Can also sync with LDAP server for users and groups
S SunONE Directory Server, MS Active Directory, Novell eDirectory
S By default, all machines that belong to a domain are expected

to be on the same network subnet
S Can use RVRD if access across subnets is required

EMS Administration
EMS Administration Utility

S Command-line interface
TIBCO Administrator
S Web-based GUI
Custom interface using API

S Provided by EMS (not the JMS spec)

Managing EMS with TIBCO
Administrator
S Use the Domain Utility to add servers

S View information on EMS Server:
S Queues / Topics
S Settings / Statistics
S Connections
S Producers, Consumers
S Routes, Durables
S Etc.
S Edit common server settings, manage queues, topics, and other

functionality

Monitoring EMS with TIBCO Hawk
S EMS ships with Hawk Microagent

S tibemsadmin.hma
S Provides methods for monitoring and managing EMS Server

S HawkController class for monitoring and managing
S HawkListener class for monitoring
S Example methods
S Get users, get connections
S Get topics, routes, queues
S Etc.

Using EMS for Hawk Network
Transport
HMA
(AMI App)
RV Network
127.0.0.1
rvd Agent
tcp EMS tcp Hawk

tibemsd Console
rvd Agent
S Using the loopback address as the RV network

parameter isolates all RV traffic the local machine
S RV is now packaged with Hawk and does not
HMA
(AMI App)
require a separate installation

Infrastructure Security Requirements
S Authentication
S Reliably determining the identity of communicating party
S Authorization
S Granting permission to access a resource
S Encryption
S Scrambling the information so that only someone knowing the
appropriate secret can obtain original information (through decryption)
S SSL – Secure Socket Layer

S Protocol for transmitting encrypted data by a way of the Internet or
internal network

Security in TIBCO EMS
S SSL communication between

S Java client and tibemsd server
S C client and tibemsd server
S COBOL client and tibemsd server
S tibemsadmin tool and tibemsd server
S Two routed servers
S Two fault-tolerant servers
S Access control on each destination – Permissions are checked
S On creation of publisher and subscriber on the destination
S On send and receive of each message
S Support for external hardware accelerators

Security in TIBCO RV
S SSL between
S RV app and daemon
S RVSD
S Routing daemon neighbors
S RVSRD
S Browser and daemon
Single firewall
S https
Double firewall

Security in TIBCO Administrator
S User Management
S Role-based Access Control (RBAC)
S Management of authentication, roles and users
S Resource Management
S Monitoring of machines and applications in TIBCO Domain
S Application Management
S Creation, configuration, deployment and monitoring of applications
S Directory Synchronization
S Secure (encrypted and authenticated) synchronization with LDAP
S Remote Administration
S HTTPS interface for administration, metadata and deployment configuration

Secure Communications
https
User, Role
Management
Access Control

Web Service Security in TIBCO
BusinessWorks
S BW 5.3 supports WS-Security 1.0

S Can encrypt “elements” of a SOAP message without
encrypting entire message
S WS-Security implemented using

two shared resources:
S WS-Security Policy
S WS-Security Policy Association
S Policy-based security means rules can be added or changed without

having to modify existing services

WS-Security Policy
S Defines security policy that can be applied to a security subject:

S Authentication Policy
S Username Password Token
S X.509 Token
S Integrity Policy – Based on XML signature
S Username Password Token
S X.509 Token
S Confidentiality Policy – Based on XML encryption
S X.509 Token
S Timeout Policy
S Adds timestamp to SOAP message
S Provides mechanism to reject message based on timestamp

WS-Security Policy Association
S Allows association of WS-Security policies to a security subject

S Security subjects can have Inbound, Outbound, Inbound Fault, and
Outbound Fault security policies
S Inbound tab allows users to define signature and encryption policy
for message parts that need to be verified for inbound SOAP
message
S Outbound tab allows users to define signature and encryption policy
for outbound SOAP message parts

Services Identification, Implementation and
Orchestration
S Services Identification, Implementation and Orchestration
S Services identification
S Process design
S Implementing Web Services
S Service engine architecture
S Service orchestration

Common Services on ESB
S Common Services are reusable components that

S Are self-contained
S Have well-defined interface
S Provide consistent behavior and functionality across invocations
S Use standards to ensure interoperability and adaptability across the enterprise
S Are manageable and discoverable through a common framework
S What benefits do they provide?
S Reduce application development effort and complexity
S Enforce consistency
S Provide significant cost savings
S Minimize overall project risk
S Two types:
S Infrastructure Services — Auditing, Exception Handling, Cross-referencing
S Business Services — Tax Lookup, Product Pricing, Sales Order Validation

Service Identification
Top-Down Approach Bottom-Up Approach

1. Develop a Business Process Map 1. Audit existing IT assets
2. Map Applications to Business Process a) Examine applications boundaries
and business objects
3. Develop Interface Wire Diagrams
b) Look for CRUD in data producers
4. Identify Patterns and consumers
5. Implement Services 2. Identify infrastructure services
a) All-new service 3. Document functionality exposed by each
b) Wrapped service S Business Unit, Geographic location
c) Composite service 4. Document organizational interfaces
S Customers, Partners, Suppliers
• can fail to capture the current

• poor identification of shared business needs
infrastructure
• can waste time on areas of lesser
• expensive and time consuming
business importance

Business Justification for SOA Projects
S Project by project (hidden) S Enterprise strategic investment

Build lots of little SOAs S Pooling of multiple common project
expenses
S Part of doing business
S Alignment with strategic business goals
S Electronic commerce
S Mergers and Acquisitions
S Customer Care
S New product or service offering
S Provisioning / Fulfillment
S 360 Degree view of customer
S Project by project (visible) S Reduction of IT expenses
Build a single SOA incrementally S Six Sigma Initiative
S Fix existing Customer Dissatisfaction S Regulatory imperative
S Poor visibility S Long-term TCO argument
S Slow execution S Insurance policy / Risk Mitigation
S Quality problems
S Faster Time to Market
S Pre-packaged services

TIBCO BusinessWorks™ 5.3

Distinct BusinessWorks™
Environments
Design Runtime
S Define processes S Configure applications
S Configure services S Deploy
S Test and debug S Manage and monitor
S Generate EAR S Administer
TIBCO Administrator
TIBCO Designer BW Engine
Domain Server
Users, Project
Resources Repository
Web Server

TIBCO Designer™
Adapters,
Services,
Processes,
Deployment,
Management
Graphical
Process
Modeling
Fully Integrated
Test Environment
Native
Drag-
Drag-n-Drop Standards
Access to based XSLT
Resources Mapper
Intuitive
Intuitivegraphical
graphicaldesign
designenvironment
environmentstreamlines
streamlines
time
timeand
andcost
costof
ofdevelopment
developmentand
andtraining
training

Standards Leadership and Support
Area Spec TIBCO Leadership
Reliable WS-ReliableMessaging S Member of WS-Reliable Exchange Technical Committee
Messaging S Co-author of spec (with Microsoft, IBM and BEA)
Events WS-Eventing S Co-author of spec (with Microsoft and BEA)
Alerts/ WS-Notifications S Co-author and member of Technical Committee
Notifications S Spec split into WS-BaseNotification, WS-BrokeredNotification and WS-Topics
S TIBCO driving consolidation of WS-Eventing and WS-BaseNotification
Addressing WS-Addressing S Actively driving WS-Addressing Working Group

Security WS-Security S Charter and voting member of OASIS Technical Committee
S Demonstrated WS-Security Interop at Gartner LA Summit
Management & WSDM (Distributed S Member of OASIS Technical Committee
Monitoring Management) S WSDM spec ratified as standard and supported by TIBCO products
Orchestration WS-BPEL S Member of OASIS Technical Committee and key contributor
Description WSDL 2.0 S Key Working Group participant (contributed expertise in pub/sub messaging)
S Pushed for inclusion of sophisticated message exchange patterns
Transport SOAP 1.2 S Key Working Group participant
S Have obtained 100% interoperability
Java Business JBI (JSR 208) S Member of Expert Group
Integration
Transactions WS-TX (Transactions) S Member of OASIS Technical Committee
Security WS-SX S Member of OASIS Technical Committee
(SecureExchange)

Enabling Asynchronous Services —
SOAP over JMS
S SOAP envelope wrapped in a JMS message

S What is the value?
S Reliable message transport with guaranteed delivery
S Secure client communications
S Synchronous and
asynchronous services
S Request/Reply and
one-way invocation

Designing for Reusability
S Use a standard BW Template

customized for your project needs
S Use naming standards for services,
processes, adapters, shared
resources and libraries
S Store template under a
version control environment
S This leads to:
S Common look and feel across projects
S Easy to import/export components
S Improved reusability

BW Runtime Engine
S Able to handle a continuous stream of services and processes, each with

dozens of activities, in an operating environment with finite critical resources
S i.e., memory, CPUs, threads, connections
S Schedule jobs and give each an equal opportunity to execute

S Provides XML data transformation and validation service
S Evaluate the transitions (XPath) and control the flow
S Perform connection/session management with recovery/retries
S Engine crash and job recovery
S Exception management and logging
S Enables management and monitoring services
S Reduces the need for custom coding of services

BW 5.3 Engine Architecture
Process Ready/blocked state

Thread Pool
Starters
(for Job execution)
T1 Binding|XSLT|Validate Activity
Dispatch Queue
Job Pool (in memory)
(ready jobs)
T-N Binding|XSLT|Validate Activity
Queue
3 Max Threads 5
7 Flow Step Count
Limit
...
Checkpoint
Or paged 4 Activation
... Limit JVM
1
Reactivate Recover 6
Connections/
Sessions Heap size
2
Max Jobs by type
Paged Jobs Checkpoint database

*Circled numbers are tunable parameters.
Engine Tuning Parameters
S Flow limit is important when tuning for high-volume message arrival

and big jobs (memory-intensive)
S Max Jobs is good for big jobs with delays in processing
(e.g., request / reply)
S Sequencing is best handled in the process design itself using
sequencing keys
S No longer need to use max jobs / activation limit
S Heap and max threads depend on hardware

S For example, on a 4 CPU machine:
S Having 4 BW engines with 8 threads each is better than
1 engine with 32 threads

Transactions
S A transaction is a logical unit of work

S Group multiple operations into an atomic execution unit
S Operations within a transaction are indivisible

S Either all or none is executed
Begin Transaction
Delete Data
Database-1
Publish Message
JMS
Insert Data
Database-2
End Transaction

BW Transaction Manager
S Transaction demarcation is provided by the Group resource

S Transaction is implicitly started at the beginning and terminated at
the end of the transaction group
S Zero coding facility, just drop the activities inside the group
S XA Transaction support for JDBC, JMS, iProcess engine, AE Plug-in
Oracle Microsoft
JMS SQL Server

BW 5.3 Features for Services
S Multiple operations per service

S Better SOA Orientation in UI
S One-click WS wizard
S Generate implementation template from WSDL wizard
S WSS: XML DSig and XML Encryption
S SOAP/JMS Topic Support
S WS-I Certification
S UDDI Export at design and deployment time

Service Orchestration
The concept of a flow or process exists at many levels
Business Process Management
B2B Collaboration
Human Workflow Form Flow
Distributed Transactions
Business Process Automation
Transactions
Message Exchange Patterns
Sequencing

BusinessWorks for Service Orchestration
S BusinessWorks orchestrates services to form a complete business process

S Same design / development / deployment / monitoring environment

WS-BPEL
S What is WS-BPEL?
S Defines a syntax for the choreography of existing Web Services.
Dependent on WSDL, XML Schema, XPath, etc.
S Features
S Ability to combine block-structured and graph-structured
paradigms
S Ability to specify compensation of faulted scopes
S Event handling
S Late Binding

BusinessWorks and BPEL
S BPEL is not…
S … a way to “export” BW Processes in a Portable Format

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

Exporting a Typical BPM Process to
WS-BPEL

Services Deployment
S Deployment Model
S Manual and Automated
S UDDI


Deployment Model –
TIBCO Administrator™ 5.3
S DB or file for storing domain data

S Local or server-based for deploying application data

DB
OR Domain

Data
File

Application
Data


TIBCO Application Deployment
S Deployment process includes:

S Binding services to machines
S Hawk rulebase uploading
S Service instance configuration
S e.g. JVM properties
S Fault Tolerance
S Two ways to deploy applications:

S Manual using TIBCO Administrator GUI
S Command-line deployment for automation

Deployment Using TIBCO
Administrator
Deployed Project

Deployment Using Scripts
S Need for scripted deployment

S Minimize the need to use administration GUI (i.e., human interaction)
S Ability to export entire deployment into an XML file
S Ease of re-deployment
S buildear – Utility to create application archive

S From an entire project, or
S From a specific resource within a project
S AppManage – Utility to upload, configure, deploy, start and stop

applications using script

Publishing Services to UDDI
S BW 5.3 and Administrator 5.3 support UDDI

S Publishing to registry
S Look up from registry

Scalability / Fault Tolerance
S Services Identification, Implementation and
Orchestration
S Service load balancing
S Service fault tolerance

BW Engine Load Balancing
S Static
S Manually configured during deployment
S Deploy applications to different engines
S Dynamic
S Process design using process starters:
S JMS Queue Receiver
S RVDQ Subscriber
S Controlled at runtime by messaging system in coordination with

BW engine

Load Balancing Using RVDQ
S At design-time, RVDQ transport is configured and used by BW

process
S At deployment, engines configured in DQ group
S At runtime, scheduler dynamically distributes workload; workers
process assigned tasks
Worker
10
Scheduler
40 DQ Group Worker
30
As
si gn
Tas
k
Worker
20

EMS Load Balancing
S Load balanced Queue receivers JMS

JMSQueue
Queue
Receiver
Receiver
JMS
JMS EMS
EMS JMS
JMSQueue
Queue
Producer Server Receiver
Receiver
Producer Server
JMS
JMSQueue
Queue
Receiver
Receiver
S Load balanced multiple servers
JMS
JMS
Client
Client JMS
JMS
Client
JMS
JMS EMS
EMS EMS
EMS Client
Client
Client Server1 Server2
Server1 Server2 JMS
JMS
Client
Client
JMS
JMS
Client
Client
JMS
JMSClient
Client
Server1
Server1 |Server2
| Server2

EMS Fault Tolerance
Shared State
Dual-ported SCSI,
SAN, NAS, etc.
Non-Active
Active Backup
Active
Server Heartbeats
Server
(may be redundant)
App App App App App App
Client
Shared
Client
Shared
Backup
connections
Active
connections
Heartbeats
state
state
server
server
lock
lock
re-established
relinquished
activates
stop
obtained
fails
disrupted

BW Engine Fault Tolerance
S Warm stand-by (backup in wait state)

S Uses RVFT to detect BW process engine failures
S Primary/Secondary
S Peer-to-Peer
S Persistent data transferred via database or file system

S Checkpoints
S Persistent shared variables

Cluster Deployment Considerations
S Understand the underlying clustering software fail-over capabilities:

S Virtual IP addressing
S Redundant data stores
S Mounting shared drives
S Implementation of cluster packages
S Besides component fail-over, the system state also needs to be

recovered:
S Persistent message data stores, log files, BW checkpoints, etc.
S Do not confuse TIBCO built-in fault tolerance techniques with what is

provided by clustering software
S Avoid multiple controlling mechanisms if possible

Lifecycle Management
S Project environments
S Services lifecycle

Environments Supporting Project
Lifecycle
Domain Dev A Domain Dev B Domain Dev C
S Development & Unit Test

S Multiple developers
S Own domains
S Project synched to VCS
S Integration Test / QA
fsaf
VCS
S Multiple machines
S Single domain Domain QA
S Mirrors production fadsfafdsa
environment
S Production
Domain Prod
S Multiple machines
fadsfafdsa
S Single domain

Environment Planning
S Frequency and size of information flow (including projected growth):

S Average and peak rates of transactions
S Average and peak rates of messages
S Average message size
S How messages are distributed among components and machines
S Help determine any latency requirements for components
S Response time requirements
S Storage capacity needs:
S Amount of persistent messages queued in messaging layer
S Amount of runtime data kept (e.g. logs, information stored in databases)
S Fault Tolerance requirements

Capacity Planning Recommendations
S Based on capacity and fail-over requirements:

S Calculate roughly how many BW engines are required
S Determine messaging infrastructure requirements (e.g. # EMS servers)
S Understand adapter requirements (e.g. SAP, Siebel, ADB)
S Calculate rough estimates for CPU and RAM requirements:
S Rule of thumb: # BW engines per machine should not exceed # CPU’s (up to 2x)
S Memory requirements can be estimated once components are determined
S Assess network load requirements based on size and frequency of
messages
S Determine if network bandwidth can support the underlying infrastructure
S Derive a capacity test plan:
S To test estimates early on in the development cycle
S For end to end performance testing in QA environment

Version Control
S BW supports version control to increase reusability and productivity

by sharing project objects among developers
S A typical BW multi-developer project can be divided into different
functional groups and mapped to the folder structures in the BW
project template
S Check-in / out project components using supported RCS
S Visual Source-Safe, Perforce, ClearCase, XML Canon
S Check-in / out project components using other RCS tools
S Open project in Designer with “File Sharing” option selected
S Developer can only work on objects with assigned privileges

Design-time Version Control Support

Overview of Environment Migration
Development QA Production
Project V-file structure Extract EAR files Extract EAR files
EAR EAR
SAR SAR
PAR PAR
AAR AAR
Configure Configure
Build and debug project Global Variables Global Variables
in TIBCO Designer
Deploy into QA Deploy into Production

Project stored in
environment environment
VCS
Generate EAR Run components Run components

files for deployment in QA in Production
Project Lifecycle
Use of Global Variables
S All environment related parameters should be global

variables
S Infrastructure related parameters
S Network services and ports, EMS Server configuration,
destinations, etc.
S End system parameters
S Application login IDs, server connection parameters, etc.
S File and database parameters
S Directory and file location, database connection, etc.

Services Lifecycle
Refer to Implementation Project Life Cycle starting with Requirements Phase
Start
Build & Propose New or Develop Service Spec and Design, Build, and Test Deploy Service and
Deploy Service Change to Service Estimates Service Service Usage Info
Deliverables: Service Proposal Service Specification Design Artifacts Deployable Components

Service Discovery Artifacts
Service Access Procedures
Gates: Proposal Approval Project Approval Deployment Approval Service Ready
Gate Keeper: It Steering Committee IT Steering Committee Enterprise Architecture Services Librarians
Link Identify Service to Request Implement Service

Service Service Utilize Service
Be Used Service Access Access
Change
Required Deliverables: None Service Access Request None Service Metrics
Gates:
Gate Keeper:
None
None
A governance process that Service Access Approval
Services Librarians
None
None
None
None
spans the entire Services

Operate Schedule Service
Schedule Service Start Start Service Stop Service
Service
Life Cycle is needed! Service Ready to be Started
Shutdown
Deliverables: Service Start Schedule Condition Requiring Shutdown Service Shutdown Schedule None
Gates: Start Schedule Approval None Shutdown Schedule Approval None
Gate Keeper: Services Librarians None Services Librarians None
Retire Request Services

Service Retire Service
Retirement
Deliverables: Service Retirement Request Service Retirement Announcement End
Gates: Service Retirement Approval None
TIBCO USER
Gate CONFERENCE
Keeper: IT Steering /Committee
2006 None 136
Fundamentals of TIBCO Architecture
Thank You for Your Attendance

April 11, 2006

TUCON 2006 Fundamentals of TIBCO Architecutre

Uploaded by

Document Information

Original Description:

Original Title

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

TUCON 2006 Fundamentals of TIBCO Architecutre

Uploaded by

Copyright:

Available Formats

TIBCO Architecture Fundamentals

Paul Asmar – Vice President, Global Architects

TIBCO USER CONFERENCE / 2006

S Architecture Discussion S Implementing Enterprise

TIBCO USER CONFERENCE / 2006 2

S An architecture that enables IT to compose applications from

TIBCO USER CONFERENCE / 2006 3

TIBCO USER CONFERENCE / 2006 4

Automate and Improve

TIBCO USER CONFERENCE / 2006 5

Paul Brown – Principal Software Architect

TIBCO USER CONFERENCE / 2006

S Describe fundamental principles for architecting TIBCO

S Architecture and Services Overview

TIBCO USER CONFERENCE / 2006 8

S Architecture is the characterization of the physical structure

TIBCO USER CONFERENCE / 2006 9

TIBCO USER CONFERENCE / 2006 10

TIBCO USER CONFERENCE / 2006 11

S Business processes make design assumptions about what systems

TIBCO USER CONFERENCE / 2006 12

S Business process defines the interplay between:

S The information used in the work

A good architecture demands a clear understanding

S Design a system that:

S Provides the expected benefit

S Does this with acceptable risks in:

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

TIBCO USER CONFERENCE / 2006 15

S The goal is to save money!

S Most functionality already exists

TIBCO USER CONFERENCE / 2006 16

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

Using O Either Company or

TIBCO USER CONFERENCE / 2006 17

S Business Services encapsulate portions of business processes

S Infrastructure Services encapsulate portions of system processes

Different organizations are involved!

TIBCO USER CONFERENCE / 2006 18

S How do we design for future usages?

Who can provide this insight in your organization?

S Be happy if you get close enough that the changes are

S Plan for service evolution

TIBCO USER CONFERENCE / 2006 20

S Architecture and Services Overview

S Leveraging the TIBCO Architecture Method

TIBCO USER CONFERENCE / 2006 21

S Architectural responsibilities are often organizationally fragmented

TIBCO USER CONFERENCE / 2006 22

TIBCO USER CONFERENCE / 2006 23

End-Point Integration End-Point

TIBCO USER CONFERENCE / 2006 24

TIBCO USER CONFERENCE / 2006 25

Customer Support Customer Analyst

Peoplesoft SAP Clarify Warehouse Logistics

TIBCO USER CONFERENCE / 2006 26

Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper Gatekeeper

Who manages the process? Who owns the risk?

S The Management Team S The Project Team

S Owns the budget for infrastructure S System Architect

TIBCO USER CONFERENCE / 2006 28

S Humans are tolerant of faults:

The ability of the architecture to perform adequately