tibco designing services wp

8/11/2019 Tibco Designing Services Wp

1/15

C O N S U L T I N G S E R V I C E S

Designing Servicesin an SOA UsingTIBCO BusinessWorks


2/15

DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 2

HIGHLIGHTS:

The information described hereis part of a series of introductory

best practices reports fordeploying a successful SOA.

Other TIBCO reports in thisseries include:

TIBCO Service-Oriented ITOrganizational Structure Best

Practices: An Introduction

TIBCO SOA Project

Organization, Staffing andFunding Best Practices:An Introduction

TIBCO SOA Governance BestPractices: An Introduction

TIBCO Services Life Cycle BestPractices: An Introduction

This document provides a working definition 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 find out how we can help you develop and

deploy an SOA that best meets your unique requirements and environment.

A Definition of SOADefinitions of SOA range from highly technical definitions around software

components and their attributes to high-level business-oriented definitions

that make analogies to the way services are offered in the business world.

If we distill the many SOA definitions 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 stylemeans 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 agilitymeans that the key driver of SOA is to provide benefit 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


3/15


that an SOA exposes must be at sufficiently coarse granularity to be usefulto the business.

Loosely coupledis 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 define

composite servicesand to orchestrate servicesto 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 workflow. 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 ofany real-time enterprise architecture.

We regard events as first-class citizens in an SOA. They are implemented

via services which emit or consume asynchronous messages using a

standard service endpoint.


4/15


TIBCO views event-driven architecture (EDA) as complementary to SOA. Evenwithin 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 first-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 referto 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 isgeneral 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 specific 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


5/15


the best design patterns available from the wider Web services andSOA communities.

SOAP envelopeis 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.

WSDLis 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 policyas 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.


6/15


A Functional View of the SOAReference ArchitectureThis 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-TimeEnterprise Platform

Service Delivery

NetworkPeer-to-peer network ofcommon, consistent andreusable services, QOSand objects.

OperationalManagement

EventManagement Security

MetadataManagement

End-UserServicesMeans of accessingand analyzing underlyinginformation and activities

Presentation ServicesAnalytic Services

Portal Dashboard Rich ApplicationsEvent

CorrelationEvent

Analysis KPI

CompositeServicesOrchestration & compositionof services and tasks

Business Process Management

CheckCredit

CheckAccess

ProvisionEmployee Create Customer

CheckPartner

Inventory

EnterpriseApplicationsLegacy, Packaged,and Custom

J2EE/.NETData

Warehouse

PackagedApps

Mainframe

Messaging

Integration Point-to-PointServices

BusinessServices

PartnerManagement Registration

ServiceOrchestration

TradingPartner


7/15


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 providersand 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 workflow applications. This layer also

supports the composition of basic services into more complex services.

Analytic Servicesrepresent those applications that perform some level of

analysis, correlation, aggregation, etc. on groups of events in order to deriveinformation 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+EDAEnterprise Architecture


8/15


Service Administrationrepresents the functionality required to support thedevelopment, 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

workflow process. The process would execute as a series of calls out to external

service providers. Finally the end of the workflow process could be notified to

interested parties by a publisher service. If the BPM engine does not natively

operate within our SOA implementation, then the BPM engine behavior couldbe 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 defining characteristics of an SOA service.

This is a machine-readable description of the functionality that the service


9/15


supports and the mechanisms by which this service can be invoked. The servicedescription includes:

A service interface, which is the abstract boundary that the service

exposes. It defines 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 semanticsof 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 ef fect ofinvoking the service. Service semantics may be formally described in a

machine-readable form, identified but not formally defined, or informally

defined 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


10/15


Service ImplementationThe 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 theservice or the agents that use that service (e.g. service consumers that may

invoke a specific 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.

Auditpolicies, which describe how interactions with the service are to be

traced either for SLA monitoring or for legal purposes such as the use ofnon-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).


11/15


Ideally service policies should be implemented as orthogonal aspects of codethat 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 datamodel embedded in the service definitions and the internal application-

specific data representation.

Operation Mapping mapping external service operations onto internal

application invocations.

Key Mapping mapping external system-independent entity keys into

system-specific 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 specific case wherethe service interface maps directly to the application interface. However,

in general the semantic adapter is an important part of any integration


12/15


architecture for managing change between the enterprise service model andthe 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 theapplication that implements the service functionality. This adapter may operate

against an API or using an integration technology such as COM, CORBA, MQ,

ODBC, a file-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 thesoftware 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 BusinessWorksor 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 workflow.

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.


13/15


Authorization that a given service consumer is authorized to invokea 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 serviceendpoints, 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 significant 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 ManagementLife 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 specific environment

(e.g. Development, Test, Production).


14/15


Runtime Life Cycle the ability to start, stop and pause a serviceendpoint 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 definition.

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 fine-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.


15/15

For More InformationThis document has presented a definition of SOA along with a description of

the functional components of an SOA. Weve given specific 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 find 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 identification purposes only. 11/05

tibco designing services wp

Documents