Search engine friendly URLs in ASP.NET – CodeProject

Search engine friendly URLs in ASP.NET – CodeProject.

via Search engine friendly URLs in ASP.NET – CodeProject.

Posted in Uncategorized

Easy SQL table binding to DataGridView – CodeProject

Easy SQL table binding to DataGridView – CodeProject.

via Easy SQL table binding to DataGridView – CodeProject.

Posted in Uncategorized

Basic Concepts: Hub/Spoke vs ESB

Note: This content has been edited for better readability…

Hub/Spoke architecture uses a centralized broker (Hub) and adapters (Spoke) which connect applications to Hub. A Spoke connects to an application and converts application data format to a format which the Hub understands, and vice versa. A Hub, on the other hand, brokers all messages and takes care of content transformation/translation of the incoming message into a format the destination system understands and routes the message. Adapters take data from the source application and publish messages to the message broker, which, in turn, does transformation/translation/routing and passes messages to a subscribing adapter which sends it to destination application(s). Having a single Hub makes a system with this architecture easy to manage but scalability takes a hit. At some point, as the number of messages increases, scalability gets dependent on hardware. Having a bigger box to scale the application has never been an ideal solution. So to overcome this limitation, most vendors have incorporated the concept of a federated hub and spoke architecture in which multiple hubs can be present. Each hub would have local metadata and rules as well as global metadata. Changes to global rules and metadata are automatically propagated to other hubs. Federated hub spoke architecture alleviates scalability issue while central management of multiple hubs makes this architecture easy to manage and brings down support cost.


Bus architecture uses a central messaging backbone (bus) for message propagation. Applications would publish messages to the bus using adapters. These messages would flow to subscribing applications using the message bus. Subscribing applications have adapters which would take a message from the bus and transform the message into a format required for the application. A key difference between hub/spoke and bus topology is that for the bus architecture, the integration engine that performs message transformation and routing is distributed to the application adapters. The bus architecture requires an application adapter

to run on the same platform as the original applications. Since each adapter has an integration engine and runs on same platform on which source and target applications run, this scales much better and is relatively complex to maintain compared to hub/spoke topology.


Enterprise service bus is an infrastructure to facilitate SOA. It provides an API which can be used to develop services and makes services interact with each other reliably. Technically, the ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to the ESB. The current EAI landscape is seeing many vendors who offer enterprise service bus solutions and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. The main difference between ESB and proprietary bus implementation is cost, which is significantly lower for ESB. The reason for this cost difference is twofold: (1) proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, (2) most proprietary buses use some proprietary formats to enhance the performance which increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. The main advantage of ESB is that it costs much less then hub/spoke or bus based product suits, and is standards based. 


Tagged with: , , , , , , ,
Posted in Design, ESB, General SOA, Uncategorized

Defining ESB: Exactly What Is It?

As with any other concept or acronym in IT, ESB has had its fair share of deviation of definitions across vendors and corporate project teams. So I figure I’d survey some definitions from the top players in the space…


The term Enterprise Service Bus (ESB) is widely used in the context of implementing an infrastructure for enabling a service-oriented architecture (SOA). However, real-world experience with the deployment of SOAs has shown that an ESB is only one of many building blocks that make up a comprehensive Service-Oriented Infrastructure (SOI). The term ESB has morphed in a number of different directions, and its definition depends on the interpretation of individual ESB and integration platform vendors and on the requirements of particular SOA initiatives.

Based on the experience Microsoft has gathered from many successful real-world SOI implementations, you can think of an Enterprise Service Bus as a collection of architectural patterns based on traditional enterprise application integration (EAI), message-oriented middleware, Web services, .NET and Java interoperability, host system integration, and interoperability with service registries and asset repositories.

Mule ESB is based on the concept of a service-oriented architecture (SOA). The SOA approach to development allows IT organizations to compose applications by building service interfaces around components of applications and exposing those to service consumers. Services are discrete sets of functionality that are completely separate from each other but can work together on a canonical set of objects. For example, if you need to process customer invoices, you might have one service that merges customer data from a database into the invoice and another service that checks the inventory database to see if the items on the invoice are in stock and a third service that fulfills the order.

Because each service stands alone, services can be used as building blocks for multiple processes and do not have to be recreated for each type of process or message. For example, the service that merges customer data onto the invoice could also be used to merge customer data onto statements, letters, or other documents. The logic that determines how the invoice data and customer data are merged is decoupled from the logic that looks up and retrieves the necessary customer data. This modular approach allows you to create functionality once and re-use it as many times as needed, streamlining development.

This decoupling is a key element of service mediation. Mediation is a well-known pattern for promoting loose coupling. In SOA, service mediation also describes the capabilities of the ESB to convert between transport protocols (including the ability to bridge between synchronous and asynchronous protocols), changing the representation of messages by transforming data, and enforcing compliance with policies by taking the necessary steps such as auditing, logging, security monitoring, etc.

Constructing the building blocks into a logical process is called orchestration. Service orchestration using an ESB allows for automation of common backend processes at the application service layer. These processes can be scheduled or exposed as services that are triggered by external events. Service orchestration differs from business process orchestration which may include longer running stateful business processes, complex human interactions and approvals, or parallel execution of those types of processes at the business service layer.

Using SOA, businesses can realize dramatic savings on development costs and can rapidly adapt to changing business conditions by reusing and reconfiguring existing services in developing new applications. SOA also enables better integration of enterprise IT resources, including previously isolated application silos and legacy systems. Mule fully supports the SOA approach and orchestrates communication among the services, allowing you to easily tie all these applications together.



An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in service-oriented architecture (SOA). As a software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes agility and flexibility with regards to communication and interaction between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex landscapes.

The concept has been developed in analogy to the Bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. Motivation was to find a standard, structured and general purpose concept for describing implementation of loosely-coupled software components (called: services) that are expected to be independently deployed, running, heterogeneous and disparate within a network. ESB is also the intrinsically adopted network design of the World Wide Web and the common implementation pattern for Service Oriented Architecture.

An ESB transports the design concept of modern operating systems to networks of disparate and independent computers. Like concurrent operating systems an ESB caters for commodity services in addition to adoption, translation and routing of a client request to the appropriate answering service.

The prime duties of an ESB are:

  • Monitor and control routing of message exchange between services
  • Resolve contention between communicating service components
  • Control deployment and versioning of services
  • Marshal use of redundant services
  • Cater for commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service

IBM (From a WebSphere ESB perspective)

WebSphere® ESB provides the capabilities of a standards-based enterprise service bus.

WebSphere ESB manages the flow of messages between service requesters and service providers. Mediation modules within the ESB handle mismatches between requesters and providers, including protocol or interaction-style, interface and quality of service mismatches. In an SCA-based solution mediation modules are a type of SCA module. The mediation modules perform a special role, and therefore have slightly different characteristics from other components that operate at the business level.

Mediation components operate on messages exchanged between service endpoints. In contrast with regular business application components, they are concerned with the flow of the messages through the infrastructure and not just with the business content of the messages. Rather than performing business functions, they perform routing, transformation, and logging operations on the messages. The information that governs their behavior is often held in headers flowing with the business messages. The IBM® SOA programming model introduces the service message object (SMO) data structure to support this pattern.

WebSphere ESB supports advanced interactions between service endpoints on three levels: broad connectivity, a spectrum of interaction models and qualities of interaction, and mediation capabilities. The product supports connectivity between endpoints through a variety of protocols and application programming interfaces (APIs):

  • Java™ Message Service (JMS) 1.1. Applications can exploit a variety of transports, including TCP/IP, SSL, HTTP, and HTTPS.
  • WebSphere ESB supports Web services standards that enable applications to make use of Web service capabilities.
    • UDDI 3.0 Service Registry, through the WebSphere Integration Developer
    • WS-* Standards including WS-Security, WS-Atomic Transactions

Because it is built on WebSphere Application Server, WebSphere ESB can provide smooth interoperability with other products in the WebSphere portfolio, including IBM WebSphere MQ and IBM WebSphere Message Broker. It can also, with IBM WebSphere Adapters solutions, use existing application assets, as well as capture and disseminate business events.

The message clients for C/C++ and Microsoft .NET enable non-Java applications to connect to WebSphere ESB using an API similar to the JMS API.

Other features at the connectivity level perform basic protocol conversion between endpoints where the protocol used by the requester to dispatch requests (such as SOAP over HTTP) is different from that of the service provider that is to handle those requests (such as SOAP over JMS).


An enterprise service bus (ESB) is the key to unlocking value from active business data. Essentially a shared superhighway for data, messages, and events to travel on, it enables systems and applications to communicate and work together.

Connecting systems and applications to a common, bus-based backbone, real-time information can circulate across the environment. Data is instantly available and can be accessed, consumed, and acted on by any system, application, or business processes on the network.

Events happening across the environment can also be made available – providing the visibility and awareness critical to engaging with activity in real time. By including traffic enterprise-wide, you can be more aware of when opportunities and threats emerge and respond with greater precision and control.

Any component can be connected, ejected, or modified without impacting the performance of others. Automatic routing and transforming messages between components ensures data arrives in the proper usable format.

Used as a foundation for a service-oriented architecture (SOA), [TIBCO ESB solution, currently ActiveMatrix] can also help expose valuable data and functionality trapped in application siloes and enable them for reuse. Grid-based architecture provides the capacity to quickly configure load balancing and fault tolerance for high availability and uniform lifecycle management of all services independent of technology.

TIBCO ActiveMatrix® Service Bus is a lightweight enterprise service bus (ESB) that mediates the communication between applications and services by routing and transforming disparate data formats and transport protocols.

It supports rapid development, near-zero coding, and low maintenance. Its standards-based platform reduces complexity and increases flexibility and reuse by replacing hard-coded service dependencies with configuration.

Highly scalable, its elastic backbone can also reliably support high availability requirements, enabling you to quickly onboard services from third-party environments or a TIBCO-based infrastructure.

Progress Software (formerly Sonic Solutions)

A service oriented architecture (SOA) will change the way you integrate and manage information assets. With a SOA infrastructure, old systems and applications are no longer lost investments – they can be reconfigured as modular services and made available throughout your enterprise.

Having an enterprise service bus (ESB) makes it easy to enjoy the key benefits of a SOA infrastructure, which are maximum flexibility and simplified management. As an added bonus, the enterprise service bus also also makes it easier to reduce the cost of IT investments by better enabling older or legacy systems to be reused.

Moreover, because the ESB primary function is to connect people, processes, and systems with the right information at the right time with greater performance and high availability, the ESB is therefore a fundamental building block for advanced Responsive Business Integration (RBI) architectures.

RBI enhances and complements application development with modular components that enable design for continuous change. And with an intelligent, policy-driven ESB infrastructure to underpin RBI agility, enterprise organizations stand a far better chance of realizing the many benefits of a successful SOA.

Providing flexible integration of distributed services and applications within an SOA, the Sonic ESB distributed architecture combines independently scalable integration services, intelligent routing, and an enterprise messaging backbone. Customers use Sonic ESB to reduce process cycle time, gather and disseminate information, and reliably respond to business conditions as they occur.

Sonic ESB enables the creation of federated services by allowing architects to more easily manage the SOA from any point. Hard-wired dependencies are eliminated through configurable service interaction, so it’s easier to deploy projects initially and – without need for disruptive re-programming – allow them to scale and evolve, extending their value throughout the organization.

Sonic ESB allows all resources to be readily connected and made broadly available across the enterprise – Web services, J2EE applications, legacy message brokers, and more. By making these federated services available for dynamically-configured interaction with other services, Sonic ESB allows the organization to bring IT resources into better alignment with organizational requirements.

An ESB is an infrastructure platform that fills critical interoperability gaps left open in state-of-the-art standards. More importantly, it enables interoperability across dissimilar standards which often exist in modern computing environments. Along the way, it brings a higher level of robustness to the infrastructure necessary to meet the mission-critical performance, reliability and scalability needed by contemporary enterprises.

In the SOA logic chain, interoperability is the predicate to agility and reuse. However, ‘true’ interoperability must be assessed on multiple dimensions, all of which must be in alignment between services if genuine interoperability is to occur. These dimensions of alignment fall into four broad categories: Functional, Structural, Behavioral and Performance.

For a consumer service to use a particular provider service, it must be aligned on the functional requirements. The provider must do what the consumer wants, whether it’s computing a price, looking up a customer, updating and order or responding to an event of interest. While the functionality is up to the service, there are other considerations which may or may not be handled by the service itself.



. Structural or systemic, alignment might be thought of as aligning the ‘pin-outs’ of an interface. If the pins between a printer and the PC don’t match, the printer won’t print, even if your PC is perfectly capable of driving a serial printer. In SOA, this type of alignment is manifest in the protocols and formats employed by the consumer and provider services. They must align precisely or interoperability will not occur, even if the provider delivers the correct function.



Behavorial alignment extends to more intangible notions such as semantics and interaction. With respect to semantics, a consumer service may request a ‘customer’ business object, but the provider service produces business objects called ‘party’ and types the object with an attribute enumerated as customer, vendor, partner, supplier, etc. While the provider is capable of producing the desired information, and the ‘pins are in alignment’, the interpretation of the produced result may or may not be natively intelligible by the consumer because the semantics are different. Similarly, with respect to interaction, there may be a consumer that wants to ‘inquire’ for customers when needed, while there may be a provider service that wants to ‘publish’ customer business objects each time one is created or updated. Although all other aspects of interoperability may be in alignment, if one wants to ask for customers and another wants to broadcast them on particular events, there still won’t be interoperability because the behavior of dialog is out of alignment.

Performance encompasses issues beyond direct interoperability; these are considerations having to do with Quality-of-Service (QoS) and Quality-of-Protection (QoP), or simply the entire realm of service-level and security-policy. Alignment here is equally critical. If a provider service was built to handle 2 requests per second with 1 second response time, consumers must be aligned with that service-level expectation or realistic production interoperability cannot be achieved. Likewise, if a provider service was deployed with the expectation that it would only be consumed by internal services, and was then inadvertently exposed for consumption by a public audience, it would be out of alignment with expected security policy.

The point to all of this is that real-world interoperability is only possible when all aspects of alignment are achieved. However, the choice of where to implement the last three of these categorical considerations is critical to the question of reuse. While the functional aspects of interoperability indeed rest entirely with the services themselves, if the services also take on the responsibility for structural, behavioral and performance related concerns, reuse erodes rapidly and the chain of logic supporting SOA unravels.

If services were left to ‘fend for themselves’ on all these points they would either come up short on support for requirements essential to certain contexts or they would become increasingly bulky . Moreover, the services would be more costly to develop, operate and maintain and would lead to duplication of those capabilities across multiple services with inconsistencies between them.

On the other hand, services that indeed delegate all these considerations entirely to common infrastructure, become inherently more reusable across more contexts and thus become more agile and manageable at scale—preserving the SOA chain of logic. ESB is this common infrastructure onto which a service can delegate mediation of these concerns. Simply put, ESB is a mediation layer for enterprise SOA whose express purpose is to mediate differences in structural, behavioral and performance characteristics between services.

ESB extends the basic idea of abstraction between participants (providers and consumers) to enterprise scale. ESB permits services (consumers and providers) to interact in a loosely-coupled manner; more so than if they were simply connected point-to-point using the most contemporary loose-coupled standard protocols, like WebServices or Java Message Service, alone. This enables services, and the processes that use them, to change over time, at a faster rate and to a much greater degree, without affecting other services or processes around them.

This is the foundation for agility.


Oracle (from an Oracle Service Bus stand point)

Oracle Service Bus transforms complex and brittle architectures into agile integration networks by connecting, mediating, and managing interactions between services and applications. Oracle Service Bus delivers low-cost, standards-based integration for mission critical SOA environments where extreme performance and scalability are requirements.

Oracle Service Bus 11g extends the performance and scalability leadership of Oracle SOA Suite 11g and Oracle API Management.

Oracle Service Bus 11g introduces new capabilities such as Service Result Cache, RESTful API, and improved performance and availability for organizations using enterprise datacenters, as well as mobile and cloud environments.

Tagged with: , , , , , , ,
Posted in Design, ESB, General SOA

Visio Templates for SOA, ESB; Also Importing Visio into IBM Rational SW Arch

For those architects and developers of service oriented projects who need Visio templates or icons because they can’t afford the “big dogs” of enterprise software design tools:

Direct link to the Visio 2010 template and stencils: 

Stencil and Template for Visio 2010

Visio 2010 represents the first noticeable improvement in usability since Visio 2000, but no enhancement in the funtionality, upon which the UML 2.2 shapes are built upon. Therefore, the shapes for Visio 2010 are the same as for Visio 2007; there are minor changes in the template.

Install: If you’d like the template to appear in the “Software and Database” category when you click File/New, together with Visio’s own templates, create in any folder a subfolder called “Software and Database”, for example, “…\My Documents\My Shapes\Software and Database”. You could choose any folder, except of the Visio program folder, i.e., don’t use C:\Program Files\Microsoft Office\Office14\Visio Content\1033. Unzip the stencils and template into “…\My Documents\My Shapes\Software and Database” or the folder you created.

Start Visio, click the File tab, click Options, click Advanced, and then, under General at the very bottom, click File Locations. Type full path of this folder without the last segment “Software and Database” into the fields “Stencils” and “Templates”. That is, type in “C:\Document and Settings\<user name>\My Documents\My Shapes\” . The template “UML 2.2 Template (Visio 2010)” will appear in the category “Software and Database”.

If you’d like the UML 2.2 template to appear in another category, such as a “UML” category, use “UML” instead of “Software and Database” in the steps above. 

Sonic Icon and Sonic Diagram Library

Library Description

For software architects who need to illustrate integration projects, the Sonic Icon and Sonic Diagram Library provides a complete set of Microsoft Visio stencils and diagrams that will save you hours of effort and provide a clearer more accurate representations of the key integration patterns you’re planning for your firm. Unlike network or software diagramming notations, the ESB Icon set was developed specifically for use in portraying services-oriented architecture (SOA) integration patterns deployed using an enterprise service bus (ESB). The library was developed by David A. Chappell (a Sonic employee) in concert with Sonic Software’s Product Marketing team. The library is used extensively in Dave’s new book Enterprise Service Bus — Theory and Practice, published by O’Reilly Media, Inc.

License Terms

The Sonic Software ESB Icon and Diagram Libraries are Copyrighted© 2004 Sonic Software, All Rights Reserved. The user will need to read and accept the license before being granted permission for download or first use.

System Requirements

Use of the library is implemented in Microsoft Visio 3.0 or later. The download file is compressed using WinZip (link below) and requires that or PKZip to unpack:;jsessionid=ED730316DD018FABC658E44FAE34A11C

Reference sites:

Hi Team!  Just wanted to let everyone know that VisioCafe has been updated with IBM‘s latest official stencils for use with Microsoft Visio.  These include all models of the Storwize V7000, including the newest models:  The 2076-312 and 2076-324 (which have the dual port 10 Gbps iSCSI card).

Here is the link to VisioCafe.  The Storwize V7000 stencils are in both the IBM-Disk as well as the IBM-Full packages.

VisioCafe is an independent non-profit web site for the gathering together of IT industry Visio collections.
Each collection is copyrighted to its respective owner, and is not the property of VisioCafe.
If you would like to host a Visio collection here for free, please contact us at

 Images of Visio Templates and Icons

Import Microsoft Visio diagrams into IBM Rational Software Architect: Part 2. Using the Visio Import feature to import UML class and use case diagrams

Version 8.5 of IBM Rational Software Architect introduced a new feature for importing Microsoft Visio diagrams. In this second article in a three-part series, Rakesh Choudhary describes how to import UML class and use case diagrams created in Visio 2010.


  • You need a basic understanding of working with UML diagrams in Microsoft Visio 2010, as well as UML diagrams in IBM® Rational® Software Architect, Version 8.5.
  • You need to understand the purpose of Sketcher diagram elements in IBM Rational Software Architect.
  • It would be helpful to be aware of steps to generate .xmi files from UML diagrams in Visio. This article describes how to do that in Visio 2010, but the steps might be quite different for other versions of Visio.

Get the rest of the details at

Tagged with: , , , , , , , , ,
Posted in Design, General SOA

SOA Patterns Site Link

SOA Design Patterns Historical Influences

Because service-orientation has deep roots in past distributed computing design platforms, many of the SOA design patterns have origins and influences that can be traced back to established design concepts, approaches, and previously published design pattern catalogs.

As illustrated in the following figure, object-orientation, EAI, enterprise application architecture, and software architecture in general represent areas for which well-recognized design pattern catalogs exist, each of which has influenced SOA design patterns.

Tagged with: , , , , , , ,
Posted in General SOA

IBM: Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture


The Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying e-business applications. This IBM Redbooks publication focuses on how you can integrate Enterprise Service Bus (ESB) implementations in a service-oriented architecture (SOA). The book discusses patterns for integrating ESBs and includes step-by-step instructions for integrating ESBs implemented in WebSphere Business Integration Message Broker V5 and WebSphere Application Server V6. However, the ESB integration patterns and concepts apply to ESBs implemented with any product.

Part 1 introduces SOA and ESB concepts, and discusses the ESB capabilities of WebSphere Business Integration Message Broker V5 and WebSphere Application Server V6. It describes guidelines for determining when integration of ESBs is necessary, and describes patterns for integrating ESBs.

Part 2 describes the business scenario used in this book and explains key technologies relevant to SOA and ESB.

Part 3 guides you through the process of integrating ESBs. Two scenarios are described: integration of homogeneous ESBs and of heterogeneous ESBs. The homogeneous ESB scenario describes the integration of two ESBs implemented in WebSphere Application Server V6. The heterogeneous ESB scenario describes integration between an ESB implemented in WebSphere Application Server V6 and an ESB implemented in WebSphere Business Integration Message Broker V5.

Tagged with: , , , , , , ,
Posted in ESB, General SOA

Giovani Salvador: Java, SOA and XML

Java, SOA and XML

Posted by giovanisalvador on July 27, 2008 at 3:32 PM PDT

I have been involved in SOA (Service Oriented Architecture) projects and also studying a lot all the aspects of the SOA world. It is interesting that I thought that I knew SOA before working effectively with SOA. More specifically, I thought my knowledge on XML parsing (of course, using a JAXP implementation) would be sufficient to say that I really know XML.

For example, when we think of an XML document we usually think of something like this:

<customer>        <address>                <zipcode>123</zipcode>                …        </address>        <address>                <zipcode>321</zipcode>                …        </address></customer>

and not this:

<?xml version="1.0" encoding="UTF-8"?><definitions xmlns=""         xmlns:wsdl=""        xmlns:soap=""        xmlns:tns=""        xmlns:xsd="" name="SyncBusiness"        targetNamespace="">        <types>                <xsd:schema targetNamespace=""                         xmlns:xs=""                        xmlns:order="">                        <xs:import namespace="" schemaLocation="./order.xsd" />                        <xsd:element name="submitOrderResponse" type="order:Order" />                        <xsd:element name="submitOrder" type="order:Order" />                </xsd:schema>        </types>        <message name="submitOrderResponse">        ...        </message>        <portType name="SyncBusiness">        ...        </portType>        <binding name="SyncBusinessSOAP" type="tns:SyncBusiness">                <soap:binding style="document"                        transport="" />                <operation name="submitOrder">                ...                </operation>        </binding>        <service name="SyncBusiness">                <port binding="tns:SyncBusinessSOAP"                        name="SyncBusinessSOAP">                        ....                </port>        </service></definitions>

But when you get involved with SOA using an ESB (Enterprise Service Bus) implementation you start to deal with a world you typically have not any involvement.



Tagged with: , , , , , , ,
Posted in Java Platform

IBM: Model and build ESB SOA frameworks

Summary:  Application integration is the biggest challenge today for many enterprises. Building an Enterprise Service Bus (ESB) is probably the quickest and most cost-effective way to address this challenge. In this article, you gain insight on ESBs, and how to model and construct ESB service-oriented architecture frameworks.

Capabilities of the Enterprise Service Bus

An Enterprise Service Bus exhibits these minimum, or mandatory, capabilities:

  • Communication
    Supports routing and addressing for at least one messaging style (such as request/response, or publish/subscribe), and at least one transport protocol that is or can be made widely available. This enables location transparency and service substitution, which enables the decoupling of the consumer view of services from their implementation.
  • Integration
    Supports several integration styles or adapters. It enables the provision of services based on these integration capabilities, and decouples technical aspects of service interactions and the integration of services in the enterprise.
  • Service interaction
    Supports an interface definition format and associated messaging model (such as WSDL and SOAP) to allow the decoupling of technical aspects of service interactions.
  • Management and autonomic
    Provides a consistent administration model across a potentially distributed infrastructure, including control over naming, routing, addressing, and transformation capabilities. This enables the management of services in the enterprise.


More advanced ESBs typically offer a number of additional value-added features, including:

  • Adapters, to enable connectivity to packaged and custom enterprise applications, as well as to leading technologies.
  • Service orchestration engines, to support both long-running (stateful) and short-running (stateless) processes.
  • Quality of service and service-level capabilities.
  • Presentation services, to enable the creation of personalized portals that aggregate services from multiple sources.

Typical architecture of an Enterprise Service Bus

The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards such as SOAP, HTTP, and Java™ Messaging Service (JMS). It is typically designed for high-throughput, guaranteed message delivery to a variety of service producers and consumers. The ESB enables the use of multiple protocols (such as synchronous and asynchronous) and performs transformation and routing of service requests. The ESB enables services to interact with each other based on the quality of service requirements of the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, and so on.

Figure 2 illustrates component types that can connect to an ESB:

  • Custom applications, based on standards like J2EE and Struts, which plug into the ESB to provide a user interface to enterprise services.
  • Service orchestration engine, which hosts long running business processes, based on standards like Business Process Execution Language (BPEL).
  • Adapters, typically built to the Java Connector Architecture (JCA) specification, enable integration with a wide variety of enterprise applications.
  • Presentation and portals enable the creation of personalized portals that aggregate services from multiple sources.
  • Data services which provides real time view of data from heterogeneous data sources.
  • Web services provides a standard means of connectivity to legacy and proprietary integration technologies.

Figure 2. ESB architecture
ESB architecture


Tagged with: , , , , , , ,
Posted in ESB, General SOA

Oracle: Enterprise Service Bus

Defining the ESB

An accepted definition for this term has yet to be firmly established that is most likely caused by a lack of industry standards, whereas standards like BPEL and BPMN 2.0 exist for process engines and other components. The term “Enterprise Service Bus” was coined by Gartner in 2002, and further introduced by the analyst Roy Schulte to describe a category of software products that he observed were available on the market at that time. Ten years later, there is still very little agreement on what exactly an ESB is or what it should deliver. There are different definitions depending on the manufacturer or source. Among other things, an ESB is defined as:

“A style of integration architecture that allows communication via a common communication bus that consists of a variety of point-to-point connections between providers and users of services.”

“An infrastructure that a company uses for integrating services in the application landscape.”

“An architecture pattern that enables interoperability between heterogeneous environments, using service orientation.” (Figure 1)

Figure 1: The ESB architecture pattern is divided into these main system architectures

The ESBs that are available in today’s market essentially differ in terms of the architecture of their systems. As shown in the preceding figure, they are mostly based on the following architectures:

Extended Message-Oriented Middleware (MOM)

These systems correspond to the original definition of ESB and typically distribute multiple nodes across the network, using a MOM infrastructure to support reliable messaging and event-driven processing among the nodes. Although the ESB nodes communicate using a proprietary protocol, service endpoints don’t need to be aware of the MOM. Services can be exposed using a WSDL or other protocols.

Extended Integration Brokers

Over the last five years, traditional integration broker vendors have been adding support for Web services and repositioning their products as ESBs. These systems are more standards-compliant than they once were but still tend to be more proprietary than most ESBs. They also tend to provide a very centralized solution in which all messages pass through a centralized broker.

Extended Application Servers

A number of ESB vendors use a Java EE application server as the basis for their ESB products. These products are typically stronger in terms of service creation and composition than they are in legacy integration. They tend to be rather centralized, although they do support distributed nodes.

Endpoint-Based Plug-In Channels

A few ESB vendors support an extremely distributed model that implements service mediation at the service endpoint, and supports heterogeneous communications using a channel plug-in architecture

Mediation Agents

Although these products don’t technically qualify as ESBs because a service platform is provided, more than one vendor has been known to label this type of product as such. Mediation agents can be centralized or distributed and support service mediation. There are also related product categories that implement parts of ESBs but are not officially marketed as ESBs by manufacturers [REF-1]:

XML Gateway

XML gateways are hardware appliances that primarily support service mediation, which is one of the key features of ESBs. In fact, XML gateways often support service mediation capabilities that ESBs do not or cannot support, such as transformation acceleration and the decryption and encryption of XML documents. However, XML gateways do not provide a service platform, a feature that is typically associated with ESBs.

Tagged with: , , , , , , ,
Posted in Java Platform
Curve Monsters

Don't fear the curve, embrace it!

Soltis Consulting, Inc.

Business Concepts, Ideas, and Information

Ebonair Lifestyles

Accommodating the debonair lifestyles of ebony professionals everywhere

Affluent Blacks of Dallas

An online society for established and upwardly mobile black professionals, and those who aspire to be


Technology news, trends and analysis covering mobile, big data, cloud, science, energy and media

Thought Catalog

Thought Catalog is a digital youth culture magazine dedicated to your stories and ideas.

Trade News in Brief

International Economic Affairs & Relations / Regional & International Organizations / Global Commerce & Business

Software Bodyguard Blog for IT Security Protection

Info to Help You Protect Your Digital Assets and Identity

SOA Developers Blog

Helpful tidbits for service-oriented software developers

Samsona Corporation

If you can dream it, we can software it