CONS ULT I NG S ERVI CE S

Designing Services
in an SOA Using
TIBCO BusinessWorks
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 2
HIGHLIGHTS:
The information described here
is part of a series of introductory
best practices reports for
deploying a successful SOA.
Other TIBCO reports in this
series include:
TIBCO Service-Oriented IT
Organizational Structure Best
Practices: An Introduction
TIBCO SOA Project
Organization, Stafng and
Funding Best Practices:
An Introduction
TIBCO SOA Governance Best
Practices: An Introduction
TIBCO Services Life Cycle Best
Practices: An Introduction
This document provides a working denition of service-oriented architecture
(SOA), a reference architecture that supports SOA and some example
implementations of SOA concepts using TIBCO products. It is designed
for enterprise software architects and assumes that the reader has a basic
knowledge of integration architecture and Web services principles.
The information in this document is part of an in-depth set of best practices
that supports TIBCOs delivery methodology, the TIBCO Accelerated Value
Framework, which is used by our TIBCO Professional Services Group to help
customers minimize risks, accelerate delivery and achieve a quality integration
and SOA strategy and deployment.
Contact TIBCO Professional Services Group for more details on the topics
presented in this report and to nd out how we can help you develop and
deploy an SOA that best meets your unique requirements and environment.
A Denition of SOA
Denitions of SOA range from highly technical denitions around software
components and their attributes to high-level business-oriented denitions
that make analogies to the way services are offered in the business world.
If we distill the many SOA denitions down to their common core it would be
something like this:
SOA is an architectural style based on the concept of a service that
enables business agility. Service providers and service consumers interact
in a loosely coupled manner via an independent interface contract.
This implies a number of core properties for an SOA:
Architectural style means that SOA is a way of planning, designing,
implementing and managing IT systems. This encompasses not only
the technology of SOA, but also and probably more fundamentally, the
organizational and IT management principles underlying an SOA.
Business agility means that the key driver of SOA is to provide benet to
the business in the form of agility in supporting the business requirements.
Agility implies wrap and re-use rather than rip and replace, therefore
SOA must be technology agnostic and able to operate within highly
heterogeneous environments. Business agility also means that the services
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 3
that an SOA exposes must be at sufciently coarse granularity to be useful
to the business.
Loosely coupled is a core attribute of SOA and it has many
technical implications:
- Service implementation is independent of platform and language.
Providers and consumers are related to each other only via an
independent interface contract.
- Services should be independent, and exhibit coarse granularity and
location-transparency.
- Service interactions take place via a messaging infrastructure
descriptive messages exchanged, ideally, in an asynchronous manner.
- Service providers and their associated interface descriptions and
semantics must be discoverable in some manner.
Beyond the core concept of services compose-ability is regarded as a
key attribute of an SOA. That is, an SOA must support the ability to dene
composite services and to orchestrate services to support business
processes. These properties should be a natural consequence of the loosely
coupled nature of services.
EVENTS IN A SERVICE-ORIENTED ARCHITECTURE
In the real world, asynchronous events are a key operation within any given IT
architecture. Events include technical events such as a user hitting a button
on a web form, a printer running out of paper or a disk drive undergoing
a catastrophic failure. Business events include events such as a customer
calling the helpdesk, a worker completing a task or a stock split on the stock
market. Asynchronous events have causes that may lie outside the realm of the
business or the IT implementation but which have effects within the business or
architecture. A customer call may initiate a workow. A stock split may initiate
a series of database updates and a disk drive failure may initiate a disaster
recovery process.
Events represented by asynchronous messages are an important part of
any real-time enterprise architecture.
We regard events as rst-class citizens in an SOA. They are implemented
via services which emit or consume asynchronous messages using a
standard service endpoint.
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 4
TIBCO views event-driven architecture (EDA) as complementary to SOA. Even
within the Web services mainstream, there is increasing acknowledgement
that interactions between service providers and service consumers must
increasingly be asynchronous and move away from purely synchronous
request/response message exchange patterns. TIBCOs view is that events
must be rst-class citizens in an SOA.
In TIBCOs approach to SOA, events are exposed as services with the same
underlying infrastructure as for synchronous request/reply services. When it
comes to implementation there should be no fundamental difference between
services that are demand driven (i.e. services accessed via synchronous
request/reply message exchanges) and services that are event driven (i.e.
services as asynchronous message publication). In this document when we refer
to SOA, we mean SOA+EDA.
SOA AND WEB SERVICES STANDARDS
Web services are a group of related and/or competing standards based on
XML that are intended to facilitate the implementation of SOA for application
development, system integration and business-to-business interoperability.
As implemented, there are a number of problems with Web services standards
when employed for the purposes of an SOA. Web services currently rely too
much on synchronous request/reply interactions. The standards as they exist
are too closely tied to unreliable message transports such as HTTP. These
appear to be faults of implementation rather than design because there is
general awareness of these limitations and progress is being made to open
up the Web services standards to more loosely coupled, message oriented,
asynchronous implementations.
The SOA reference architecture presented in this document is independent
of any specic Web services standards. However, it makes sense to refer to
and use some of the Web services standards as they are widely adopted and
consolidated because:
Interoperability is a desired property of many services in an SOA
architecture and the use of public standards, where appropriate,
fosters interoperability.
Some aspects of the Web services standards embody best practices
that have been learned through many years of distributed application
integration solution development. Therefore we want to make use of
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 5
the best design patterns available from the wider Web services and
SOA communities.
SOAP envelope is a useful mechanism for wrapping service invocations
along with associated metadata. Even if you dont use the SOAP envelope
standard schema in an SOA implementation, it is still important to have some
kind of standard message envelope for service interactions. SOAP is generic
enough and extensible enough to support most implementation requirements.
WSDL is a useful mechanism for publishing a service description that
is completely independent of the service implementation. Anyone can
obtain the WSDL for a service and use it to implement a service consumer.
This is a key attribute of SOA the service description must be separable
from and independent of the service implementation.
The concept of a policy as embodied in the emergent WS-Policy
standards is a useful design pattern. The ability to separate out policy-
style behavior into an orthogonal component is very powerful for
implementing extensible and compose-able services.
The use of Web services standards are not required to build an SOA.
Some aspects of the Web services standards are in an SOA to foster
independence of implementation and hence interoperability between
different platforms.
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 6
A Functional View of the SOA
Reference Architecture
This section provides a functional view of the SOA reference architecture. The
overall architecture is broken down into a hierarchical description of the logical
components within the architecture. We also present a description of the
functions that each logical component must support within the architecture.
THE TIBCO REAL-TIME ENTERPRISE PLATFORM
Figure 1 shows a high-level diagram of the TIBCO real-time enterprise
platform. The aim of this reference architecture document is to represent the
components of the TIBCO platform as generic implementation mechanisms.
The primary focus will be on the Service Delivery Network layer.
Figure 1. TIBCO Real-Time
Enterprise Platform
Service Delivery
Network
Peer-to-peer network of
common, consistent and
reusable services, QOS
and objects.
Operational
Management
Event
Management Security
Metadata
Management
End-User
Services
Means of accessing
and analyzing underlying
information and activities
Presentation Services Analytic Services
Portal Dashboard Rich Applications
Event
Correlation
Event
Analysis
KPI
Composite
Services
Orchestration & composition
of services and tasks
Business Process Management
Check
Credit
Check
Access
Provision
Employee
Create Customer
Check
Partner
Inventory
Enterprise
Applications
Legacy, Packaged,
and Custom
J2EE/.NET
Data
Warehouse
Packaged
Apps
Mainframe
Messaging
Integration
Point-to-Point
Services
Business
Services
Partner
Management
Registration
Service
Orchestration
Trading
Partner
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 7
THE HIGH-LEVEL ARCHITECTURE
Figure 2 takes the real-time enterprise platform shown in Figure 1
and abstracts it to the highest level to highlight the main elements of
the architecture.
At the base of the architecture, we have a series of service endpoints that
represent service providers and service consumers within our architecture.
Service endpoints represent demand driven (e.g. request/reply) service providers
and consumers as well as asynchronous event-driven service providers and
consumers (e.g. event publishers and subscribers).
The Business Process Management (BPM) layer represents the orchestration
or choreography of interactions with service endpoints to support a business
process or to achieve a business goal. These may include short-lived business
processes such as straight-through processing applications as well as long-
lived processes such as human-oriented workow applications. This layer also
supports the composition of basic services into more complex services.
Analytic Services represent those applications that perform some level of
analysis, correlation, aggregation, etc. on groups of events in order to derive
information about those events.
Presentation Services represent dashboards, portals or rich clients that support
personalization and aggregation of services data for human user interfaces.
Figure 2. High-Level SOA+EDA
Enterprise Architecture
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 8
Service Administration represents the functionality required to support the
development, discovery, deployment, monitoring and life cycle of services.
It also includes the requirements of a policy framework including support for
security authentication, authorization and encryption.
In terms of our reference architecture, the higher-level layers such as analytic
services, presentation services and business process management are usually
special cases of service providers and service consumers. For example, a BPM
engine may expose a subscriber service by which external systems may initiate a
workow process. The process would execute as a series of calls out to external
service providers. Finally the end of the workow process could be notied to
interested parties by a publisher service. If the BPM engine does not natively
operate within our SOA implementation, then the BPM engine behavior could
be wrapped within custom service endpoints. The remainder of this document
will be primarily concerned with the service endpoints and the administration
services components of the architecture.
SERVICE ENDPOINTS
This section describes the functional composition of the service endpoints. If
we zoom in for a detailed look at one of the service endpoints in Figure 2 we
see a layering of components like that shown in Figure 3.
At the bottom of the service endpoint stack is the underlying host system that
implements the business functionality exposed by the service.
At the top of the service endpoint stack we have the service description
that ultimately resides in a registry or repository. The service description is
supported at runtime by the service implementation that comprises a service
interface and a policy implementation.
In the middle we have an adapter layer that supports connectivity between
the host system and the enterprise and performs any semantic mappings
between the external services model and the internal data schema and
application interface.
The following sections go into more detail about the role of each of these
components in the TIBCO SOA reference architecture.
Service Description
The service description is one of the dening characteristics of an SOA service.
This is a machine-readable description of the functionality that the service
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 9
supports and the mechanisms by which this service can be invoked. The service
description includes:
A service interface, which is the abstract boundary that the service
exposes. It denes the types of messages and the message exchange
patterns that are involved in interacting with the service, together with any
conditions implied by those messages.
The message transport or details of how the service can be accessed at
the messaging layer.
The semantics of the service, which is the behavior expected when
interacting with the service. The semantics expresses a contract between
the service provider and the service consumer. It expresses the effect of
invoking the service. Service semantics may be formally described in a
machine-readable form, identied but not formally dened, or informally
dened via an out of band agreement between the provider and the
requester entity.
The service description must be publicly accessible in some way in a
service registry or repository. The description should be both machine and
human readable.
Figure 3.
The Service Endpoint Stack
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 10
Service Implementation
The service implementation is the runtime component that supports the service
functionality as a service. It comprises the following two sub-components.
Service Interface
The service interface is the runtime instantiation of the service description. In
the case of a service provider, this is the component that service consumers
contact in order to invoke the service. In the case of a service consumer, this is
the component that makes a connection to the service provider.
Policy Client
The service implementation must be able to enforce policies associated with
the service. A policy is a constraint or a requirement on the behavior of the
service or the agents that use that service (e.g. service consumers that may
invoke a specic service provider subject to certain policy constraints). Typical
service policies include:
Security (or permission), which describes the conditions under which a
service may be used by an agent. These may include how agents are to
be authenticated before using the service, which agents are authorized
to use the service and how data is to be encrypted in interacting with the
service interface.
Audit policies, which describe how interactions with the service are to be
traced either for SLA monitoring or for legal purposes such as the use of
non-repudiation logs.
Quality of service (QoS) policies, which relate to the service levels that a
service must support for its consumers. How can we be guaranteed that
the service will be available when needed? If the service is not available,
what are the policies relating to resumption of the service? For example,
if an asynchronous message is sent to the service, can we be sure the
message will be processed when the service resumes or must we re-try on
a given interval, etc.
QoS and audit policies are potentially related in the sense that audit policies
may be used to monitor how well a service implementation meets the QoS
requirements. For example, we may use the audit policies to measure a given
SLA or key performance indicator associated with a service Implementation
(and advertised as part of the service description).
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 11
Ideally service policies should be implemented as orthogonal aspects of code
that plug-in to the service implementation code.
The policy client will often perform its functions by contacting one or more
associated policy servers. For example, a security policy client may make
reference to authentication and authorization information in a central security
policy server. Or an audit policy client may send information about the
invocation of a service to a central audit repository.
The Adapter Layer
The adapter layer is the glue between the service implementation and the
host system (that implements the underlying business functionality).
The adapter is responsible for connecting the external enterprise world
(mediated by the services standards) with the internal applications that
implement the service functionality. We split the adapter into two further
logical components the semantic adapter and the technical adapter. This split
is necessary because the two components are often implemented by different
software packages.
Semantic Adapter
The semantic adapter supports the semantic mapping between the external
services world and the internal application implementation. Semantic mapping
includes:
Schema Transformation mapping between the external common data
model embedded in the service denitions and the internal application-
specic data representation.
Operation Mapping mapping external service operations onto internal
application invocations.
Key Mapping mapping external system-independent entity keys into
system-specic entity keys.
Integration Logic executing any logic or process that is necessary to
map the internal behavior of the application to the external behavior of
the service.
The semantic adapter may not always be necessary in the specic case where
the service interface maps directly to the application interface. However,
in general the semantic adapter is an important part of any integration
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 12
architecture for managing change between the enterprise service model and
the application implementation of the service.
The semantic adapter supports semantic mapping between the
external services world and the internal application implementation.
The semantic adapter is important for managing change between
the enterprise service model and the application implementation of
the service.
Technical Adapter
The technical adapter is responsible for the physical connectivity into the
application that implements the service functionality. This adapter may operate
against an API or using an integration technology such as COM, CORBA, MQ,
ODBC, a le-based interface, etc. The technical adapter generally does not
perform any semantic transformations, but instead communicates with the
application using its native schemas and operations.
The technical adapter may not always be required or may not always be distinct
from the semantic adapter. But in general there needs to be something that
operates on an application interface on behalf of the service.
Host System
The module labeled functional implementation in Figure 3 represents the
software component that actually carries out the function(s) supported by the
service. In an integration environment, this is usually a host application such as
a database, ERP application, etc.
In some cases TIBCO BusinessWorks

or BPM software may act as the host

system in the sense that the service functionality is implemented as a
BusinessWorks process or as a BPM workow.
SERVICE ADMINISTRATION
The service administration component looks after the functions associated with
security, monitoring, service discovery and service life cycle management.
Security
Security includes:
Authentication that a service consumer or service provider are in fact
who they say they are.
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 13
Authorization that a given service consumer is authorized to invoke
a given service provider and conversely that a given service provider
may be invoked by a given service consumer. In the event-driven model,
authorization assures that a given service provider can publish a given
event and that a given service consumer can subscribe to a given event.
Encryption allows for all or part of a message to be encrypted so that
only authorized service endpoints can read the message.
In an SOA, security is controlled by centrally managed policies associated with
service providers and consumers.
Monitoring
Monitoring provides the infrastructure to track operations on service
endpoints, the responsiveness of service endpoints with respect to service
level agreements (SLAs) and to signal alarms to system administrators when a
service endpoint fails or its parameters go out of bounds. The main aspects of
monitoring include:
Audit the ability to track signicant points in a service invocation along
with metadata.
Performance the ability to measure the performance of a service
endpoint for capacity planning and to determine SLA compliance.
Alarms the ability to notify system administrators and enterprise
management systems of alarm conditions in a service endpoint.
In a distributed SOA it is helpful for the monitoring to be agent-based using
runtime agents associated with each service endpoint. This provides better
scalability and also allows the local agents behavior to correlate with the
service endpoints current state in its life cycle.
Discovery
Service discovery covers the ability for developers to locate and use services
at design time as well as the ability for service consumers to discover and use
services at runtime.
Life Cycle Management
Life cycle management covers the ability to manage service endpoints through
the following states in their life cycle:
Deployment the ability to deploy a service into a specic environment
(e.g. Development, Test, Production).
DESI GNI NG SERVI CES I N AN SOA USI NG TI BCO BUSI NESSWORKS 14
Runtime Life Cycle the ability to start, stop and pause a service
endpoint once it has been deployed.
Version Management the ability to promote service endpoints from
one version to another to take into account changes in functionality or in
interface denition.
Version Rollback the ability to roll-back a service endpoint from one
version to an earlier version.
A widely-agreed consequence of the loosely coupled nature of services in an
SOA is services can be managed independently of each other. This implies
a very ne-grained level of management at the level of an individual service
rather than the service container.
Dependency Management
In an SOA where service endpoints are loosely coupled and independently
managed, it is important to be able to determine dependencies between
service endpoints.
At runtime we want to be able to discover if changes or failures of a service
endpoint will have adverse effects on other service endpoints or on business
processes that depend on that service endpoint.
At design time, we want to determine if changes in a given message schema or
service description associated with a service endpoint will have an impact on
other service endpoints.
For More Information
This document has presented a denition of SOA along with a description of
the functional components of an SOA. Weve given specic emphasis to the
implementation of service endpoints to support integration architecture.
Contact TIBCO Professional Services Group for more details on the topics
presented in this report and to nd out how we can help you develop and
deploy an SOA that best meets your unique requirements and environment.
Global Headquarters
3303 Hillview Avenue
Palo Alto, CA 94304
Tel: +1 650-846-1000
Toll Free: 1 800-420-8450
Fax: +1 650-846-1005 www.tibco.com
2005, TIBCO Software Inc. All rights reserved. TIBCO, the TIBCO logo, The Power of Now, TIBCO Software, and TIBCO BusinessWorks are trademarks or registered trademarks of TIBCO Software Inc. in the United States and/or
other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identication purposes only. 11/05