Wp Service Mediation Tcm8 2440

8/8/2019 Wp Service Mediation Tcm8 2440

1/11

Service Mediation

The Role of a E terpr se Ser e Bus a SOA
http://www.tibco.com/


2/11

S E R v i c E M E d i ATi O n

Executive SummaryBusiness agilitythe ability to quickly adapt to changing needsis increasinglybecoming a key goal or businesses operating in the highly competitive globalmarketplace. Business managers need rapid resource and process recon gura-tion to e ect such change. To acilitate this change, IT managers are movingaway rom siloed processes and large monolithic enterprise so tware; they areexamining ways to loosely couple applications together and provide business

unctions that can be turned into services and reused across the enterprise.

A service-oriented architecture (SOA) is a way o building an enterprise ITin rastructure out o loosely coupled components known as services thatper orm discrete unctions. Composite applications are a key element o anSOA environment. These applications are created by invoking and orchestratingmultiple services, events and models in such a way that they collectively per orma higher-order business unction. This unctionality increases business agility byenabling IT departments to reuse components that have already been testedin production and have known scalability and quality-o -service characteristics.Such reuse can help reduce time to market and lower IT development costs.

An enterprise service bus (ESB) is a distributed, message-based integrationsolution based on open standards. The role o an ESB is to acilitate reliablecommunications between IT resources such as applications, plat orms andservices that are distributed in multiple systems throughout an enterprise. As ITdepartments increasingly ocus on designing SOAs to lower development costsand increase business agility, ESBs are a key rst step in setting up an enter-prise SOA. ESBs orm the oundation o the SOA and can be complemented byadditional productivity capabilities such as service orchestration and registries.This paper discusses the requirements or an ESB that can address the needs o an enterprise-ready SOA.


3/11


The Road to Web Services and ESB sSOAP, Web Services Description Language (WSDL) and HTTP have solved athorny issue that plagued previous attempts to create standards or distributedsystems such as Common Object Request Broker Architecture (CORBA) or theDistributed Computing Environment (DCE)namely, widespread acceptance

rom the two largest application technology camps (.NET and J2EE) as well asrom a number o application vendors. While this is no mean eat, the accep-

tance was gained by oversimpli ying the standards to a core, agreed-upon set o technology statements. This design principle is simultaneously the Web servicesstandards greatest virtue and its biggest limitation.

In short, no enterprise-class implementation can run on SOAP, WSDL and HTTPalone. As Web services and SOA rapidly gain acceptance in the IT community,they ace the same challenges that previous generations o distributed systemshave encountered, only on a larger scale due their inherent decompositionprinciples. Foremost among these challenges is how to address the scaling o point-to-point connections, also know as the M*N connection problem.

Figure 1 below illustrates the connection explosion problem that point-to-pointintegration approaches introduce. For every application that is added, the num-ber o connections grows exponentially as each application connects to everyother application. TIBCO invented the In ormation Bus paradigm, illustratedon the right side o the gure. In this model, each application connects only

Figure 1: Reducing connectioncomplexity with the ESB

Connecting through the Bus (N)Direct Point-to-Point Connections (M*N)

T d: W b s vic sadoptio sta da diz sSOA m ssagi gA key challenge or developershas been integrating multiplesystems that use di erent lan-guages and ormats. However,the rise o Web services has pro-vided service-oriented architec-tures (SOAs) with a standardizedmessaging ormatSOAPthatenables di erent systems tointeract. Web services also useWeb Services Description Lan-guage (WSDL) to describe theendpoints application programinter ace (API), which enablesapplications written on di erentplat orms, such as C++, Java or.NET, to communicate with com-mon inter aces.


4/11


once to a common backbonethe bus. This minimizes connections and pro-vides a centralized location or administering the connections and managingintegrated systems and architectures.

To manage the complexity o how a service client connects and communicatesto a service provider, the SOA needs a backbone that can go beyond the tra-ditional distributed messaging to provide complex trans ormation, routing andloosely coupled connectivity in a heterogeneous IT environment, regardless o the plat orms used. This reliable backbone provides an enterprise-class servicebus that is true to all parts o the moniker ESB.

Enterprise-Class Requirementsfor an ESBLets take a look at the enterprise-class capabilities o the service bus. Each o the ollowing unctions is an essential element o success ul integration in anSOA. Together they address the challenges acing service clients and serviceproviders in an SOA environment.

Distributed messaging. At the heart o the ESB is a message-oriented middle-ware oundation such as TIBCO Enterprise Message Service so tware. This

oundation provides a reliable, distributed transport mechanism using a store-and- orward mechanism that ensures message delivery even in the ace o network ailures.

Location transparency. With service mediation, a service client invoking a ser-vice provider only needs to be aware that the service exists; the client does notneed to know where the service is running. The ESB locates the service when itis invoked, providing a level o service virtualization and localization transparencyso that i a machine goes down or a service provider has to be moved, individualservice clients do not need to be noti ed o the change. This can signi cantlylower IT management costs and minimize risk.

Transport transparency. In traditional, point-to-point integration approaches,components and objects are all very tightly coupled. In SOA, services arelocated throughout the IT environment and are less tightly coupled, due tolocation transparency. While relying on location transparency to connect service


5/11


clients and providers, the ESB also provides physical transport protocol bridgingto allow communication between services using di erent transports.

Multiprotocol support. Because the HTTP transport model contains inherentreliability issues and only unctions well or synchronous message exchangepatterns (MEP), it does not satis y the requirements o every application or ser-vice. For example, Java Message Service (JMS) contains asynchronous character-istics as well as improved transport reliability in comparison to HTTP. To supportdisparate application behavior, some systems use SOAP over JMS to achievetheir desired e ects. Other types o transport models are being used as well,including proprietary transport systems rom major enterprise resource planning

and systems vendors. There ore, ESBs need to be able to support many types o transport systems to e ectively integrate disparate systems and manage com-plex communications at the transport level.

Quality of service. For enterprise applications, quality o service (QOS)mainly pertains to service reliability. Message delivery and reliable serviceinvocation are mission-critical unctions o any system. Yet Web servicesalone do not provide guaranteed delivery. An ESB, on the other hand, canprovide high service reliability by ensuring end-to-end message delivery thatis beyond the reliability transports such as JMS can provide. Moreover, the waythe high QOS is achieved must be standards-compliant, such as supporting the

WS-ReliableMessaging speci cation.

Message exchange patterns. Most ESBs today operate on a request/replyparadigm using SOAP over HTTP, meaning the service client issues a requestmessage to the user and waits or the response. This is also known as a synchro-nous MEP.

However, in the publish/subscribe MEP, the service client can send a messageand subscribe to the response, rather than wait or it. The publish/subscribe MEPcan respond more e ciently to events within an enterprise, particularly when theli ecycle o a service action takes place over long periods o time. An ESB needs

to be able to address both paradigms.

Content-based routing. There are two types o routing within an ESB. The rst,service routing, occurs when a service invocation enters the ESB and the ESB


6/11


routes the request to the appropriate service provider, without requiring the ser-vice client to know the location o the service provider. This is how the locationtransparency discussed earlier is achieved.

The other type, content-based routing, introduces a set o rules or businesslogic that is applied to the content o the message at the routing stage andenables the ESB to route messages to speci c service providers based on theircontent or example, prioritizing orders rom certain customers or fagginglarge orders or special treatment. This is a valuable service or businessesbecause it can help lower in ormation management costs, ensure adherenceto service-level agreements and enable companies to ocus on customer

satis action.

Transformation. While the task o an ESB is to route messages rom one serviceto the next, there are sometimes going to be cases where the data ormats aremismatched. Hence, the ESB needs to be capable o trans orming data rom one

ormat into another.

Additional Evaluation CriteriaIn addition to evaluating the previous eatures when deciding on the best integra-tion tool or an SOA, special attention should be placed on the ollowing criteria:

Open standards. Open standards, such as SOAP, WSDL and Java BusinessIntegration (JBI), are an integral requirement o an enterprise SOA. There ore,these open standards should be supported both by the ESB solution compo-nents (runtime container, messaging in rastructure, integration services anddesign-time notations) and by the mechanisms or integrated resources to par-ticipate (attach, request and respond) on the bus.

Scalability and high availability. The ESB must be able to handle a large volumeo messages to meet enterprise needs. In addition, high availability is essentialto ensure uninterrupted business operations. I one element in the ESB ails, it

should not necessarily stop services rom communicating.

These criteria help IT departments ensure that the ESB is capable o handlingthe necessary transaction load quickly, reliably and with room or uture growthan essential element o business agility.


7/11


The TIBCO ESBfor SOAPowerful Exte s o s to a S mple co ept

With TIBCO BusinessWorks so tware, introduced in 2001, TIBCO o ers amature ESB product that provides complete unctionality or designing an SOA.TIBCO has specialized in integration or more than 20 years, pioneering event-

driven architecture (EDA) with the introduction o its service-oriented In ormationBus architecture in the 1980s. In act, the philosophy at TIBCO is that enterprisesneed a single architecture that supports both services and events so IT depart-ments can expose in ormation and applications as reusable services across theenterprise and enable the real-time fow o event-driven in ormation.

With this vast experience, TIBCO understands that an SOA is not just aboutWeb services. While most ESBs presume everything is a Web service, pure Webservices standards are not enough to ensure the integration o all applicationsand inter aces.

BusinessWorks is an extensible SOA enablement plat orm or integrating enter-prise applications and developing and deploying Web services. Its bus-basedarchitecture can be extended to accommodate a wide range o integration capa-bilities, providing an e ective tool or organizations with complicated integrationissues, and its con gure rather than coding approach can help reduce totalcost o ownership.

BusinessWorks goes beyond ESB unctionality by providing an integration back-bone that e ectively creates, orchestrates and deploys services and assets in anenterprise SOA. The ollowing eatures and unctionalities in BusinessWorks canhelp IT departments realize the ull bene ts o an SOA.


8/11


Asynchronous Invocation EnhancesSOA FlexibilityBuilt on decades o integration experience, BusinessWorks provides a stable,high-per ormance integration plat orm or a variety o applications and serviceendpoints. In addition to supporting Web services, including SOAP over HTTP,BusinessWorks also o ers SOAP over JMS. This enables asynchronous MEP andincreases message reliability, which is an important aspect o quality o service.For businesses with services that do not need to incorporate Web services aspart o the SOA, the JMS transport support still provides bene ts, because it isinherently more reliable and o ers better quality o service than HTTP.

Multiprotocol Support StreamlinesCommunicationsAlthough ESBs support Web services, not all have multiprotocol transportsupport or provide the same level o multiprotocol support as BusinessWorks.TIBCOs so tware is speci cally designed to support multiple protocols, includingSMTP and FTP. This support provides a greater level o fexibility within an SOAand improves connectivity between heterogeneous systems.

Service Mediation Virtualizes SystemsAs an integration plat orm, BusinessWorks has many di erent ways to bring sys-tems together. A key element o that connectivity is the use o adapters. SinceBusinessWorks is an independent plat orm and not linked to any one hardwareor application server vendor, it is not tied down to any one approach or technol-ogy. BusinessWorks includes adapters or most major business systems, includ-ing main rame applications and common business process so tware, such asOracle and SAP products, which sit on top o the ESB transport and provide theadditional special logic required to ensure complex connectivity.


9/11


Complex Routing and TransformationOptimizes Business ProcessesIn addition to connecting applications and systems within a heterogeneousenvironment, BusinessWorks provides a very power ul trans ormation engine.While most ESBs provide simple trans ormation, BusinessWorks supports com-plex trans ormation. Through an easy-to-use GUI, developers can design verycomplex trans ormations without having to spend hours in tedious coding (seeFigure 2). By applying business logic and rules to messages, business unctionsand services can be more e ciently managed and composed, reducing designrisk and increasing productivity.

Scalability and High AvailabilityBusinessWorks is highly scalable and reliable. Because it does not have to bedeployed on an application server, it does not have to rely on the scalability andreliability o an application server. Instead, multiple instances o the so tware canbe run on many di erent servers that communicate with each other. This pro-vides active availability: i one machine disappears or starts slowing down undera heavy workload, another can take over. These operating system plat orms may

Figure : The TIBCOBusinessWorks no-codingapproach employs a richGUI for easy use.In the top hal o the screen, orchestra-tion is made simple with drag-and-dropoperations. The bottom hal shows themapping o complex trans ormations.

Adapter,Process,

DeploymentConfigurations

Drag-and-DropAccess toResources

NativeStandards-Based XSLTMapper


10/11

S E R v i c E M E d i ATi O n 10

be rom multiple vendors, a signi cant bene t o a vendor-independent ESB.Deploying multiple instances provides scalability and ensures high availability ormission-critical transactions.

Process OrchestrationAlthough orchestration is very much part o an overall business requirement,mainstream ESBs do not typically include orchestration services. BusinessWorkstakes the ESB concept one step urther and includes eatures that can orches-trate di erent business processes within the enterprise and compose thoseservices into applications.

TIBCO Streamlines a Service-OrientedApproachThere are almost as many unctional de nitions or ESBs in the market today asthere are vendors. In describing their products, however, a number o these ven-dors con use the word simple with a lack o unctionality; some products aremissing such basic unctions as adapters or connecting legacy and packagedapplications to the bus, while others lack a proven messaging in rastructure.TIBCO BusinessWorks provides an ESB that is simple to use, as well as a no-coding approach to developing, deploying and running integration projects and

building SOAs. By simpli ying some o the more complex implementation issuesthat are critical or the glue and sequence between connected systems, suchas process orchestration and trans ormation, BusinessWorks serves as a robust,enterprise-class messaging backbone and power ul ESB.


11/11

FOr MOre InFOrMATIOnFor in ormation on a broad range o topics speci c to SOA and event-drivenarchitecturesincluding best practices, standards, organizational governance andrelevant technologiesTIBCO invites you to access the SOA Resource Center atwww.tibco.com/software/soa/ . More in ormation on TIBCO products and pro es-sional services can be ound at www.tibco.com .

Global Headquarters3303 Hillview AvenuePalo Alto, CA 94304

Tel: +1 650-846-1000Toll Free: 1 800-420-8450Fax: +1 650-846-1005 www.tibco.com

2005, TIBCO So tware Inc. All rights reserved. TIBCO, TIBCO So tware, TIBCO BusinessWorks, TIBCO Enterprise Message Service and In ormation Bus are the trademarks or registered trademarks o TIBCO So tware Inc. in the United States and other countries. All other product and company names and marks mentioned in this document are the property o their respective owners and are mentioned oridentifcation purposes only. 11/05
http://www.tibco.com/software/soa/http://www.tibco.com/http://www.tibco.com/http://www.tibco.com/http://www.tibco.com/http://www.tibco.com/http://www.tibco.com/software/soa/

Wp Service Mediation Tcm8 2440

Documents

Transcript of Wp Service Mediation Tcm8 2440