Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Business Process Execution Language for Web Services 2nd Edition

You're reading from   Business Process Execution Language for Web Services 2nd Edition

Arrow left icon
Product type Paperback
Published in Jan 2006
Publisher Packt
ISBN-13 9781904811817
Length 372 pages
Edition 1st Edition
Languages
Arrow right icon
Toc

Table of Contents (14) Chapters Close

Business Process Execution Language for Web Services
Credits
About the Authors
About the Reviewers
Preface
1. Introduction to BPEL and SOA FREE CHAPTER 2. Web Services Technology Stack 3. Service Composition with BPEL 4. Advanced BPEL 5. Oracle BPEL Process Manager and BPEL Designer: Overview 6. Oracle BPEL Process Manager: Advanced Features 7. MS BizTalk Server BPEL Syntax Reference Index

Enterprise Service Bus


While web services are an appropriate technology for SOA, some other aspects need to be considered:

  • In most enterprises, web services are not the only middleware solution used. Usually enterprises already have one or more middleware products, such as messaging systems and ORBs. They cannot afford to replace them overnight with web services. Therefore, there is a need to integrate different middleware products, and provide interoperability with web services.

  • In order to provide connectivity between services, the use of SOAP in complex environments is not adequate. In such environments, we need ways to connect, mediate, manage, and control the services and particularly the communication between them.

  • SOAP over HTTP might not be robust enough for heavy enterprise use. Enterprise information systems require dependable, robust, and secure service infrastructure.

The Enterprise Service Bus (ESB) is the software infrastructure, acting as an intermediary layer of middleware that addresses the above-mentioned requirements. An ESB adds flexibility to communication between services and simplifies the integration and reuse of services. An ESB makes it possible to connect services implemented in different technologies (such as EJBs, messaging systems, CORBA components, and legacy applications) in an easy way. An ESB can act as a mediator between different, often incompatible protocols and middleware products.

The ESB provides a robust, dependable, secure and scalable communication infrastructure between services. It also provides control over the communication and control over the use of services, including:

  • Message interception capabilities: This allows us to intercept requests to services and responses from services and apply additional processing to them. In this manner, the ESB acts as an intermediary.

  • Routing capabilities: This allows us to route the messages to different services based on their content, origin, or other attributes.

  • Transformation capabilities: These allow us to transform messages before they are delivered to services. For XML formatted messages, such transformations are usually done using XSLT (Extensible Stylesheet Language for Transformations) or XQuery engines.

  • Control over the deployment, usage, and maintenance of services: This allows logging, profiling, load balancing, performance tuning, charging for use of services, distributed deployment, on-the-fly reconfiguration, etc.

  • Other important management features include the definition of correlation between messages, definition of reliable communication paths, definition of security constraints related to messages and services, etc.

ESB Features

Currently there are several products on the market that claim to provide ESB functionality. A good ESB should provide at least quality‑of‑service support of enterprise level, including reliability, fault-tolerance, and security. If provided by an ESB, services can depend on these features and do not need to implement them themselves. The ESB should also allow configuring any combination of these quality‑of‑service features and provide flexibility.

An ESB should provide support for a variety of technologies on which services are implemented. In addition to web services, an ESB should provide connectors for a broad range of technologies, such as J2EE and .NET components, messaging middleware, legacy applications, and TP monitors. The ESB needs to provide flexibility to bind any combination of services without technological constraints. It should also support a combination of different interaction models, such as queuing, routing, etc., without changing the services or requiring writing code.

An ESB should make services broadly available. This means that it should be easy to find, connect, and use a service irrespective of the technology it is implemented in. With broad availability of services, an ESB can increase reuse and can make the composition of services easier. Finally, an ESB should provide management capabilities, such as message routing, interaction, and transformation, which we have already described.

An ESB that provides these features becomes an essential part of the SOA. It provides several benefits, including increased flexibility, reduced deployment, development, and maintenance costs, and increased reliability and manageability. Therefore the ESB is an essential part of SOA, which we will discuss in the next section.

You have been reading a chapter from
Business Process Execution Language for Web Services 2nd Edition
Published in: Jan 2006
Publisher: Packt
ISBN-13: 9781904811817
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image