BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

ESB Roundup Part One: Defining the ESB

by Miko Matsumura on Jul 05, 2006 |
The theme of Accenture chief technology officer Don Rippert's recent interview that the full potential of SOA is still five years away. However, buried in the interview was simple assertion--that the use of an Enterprise Service Bus (ESB) is step three out of four steps to realize the full potential of an SOA. The steps in Don Rippert's model are:
  1. Use of eXtensible Markup Language (XML) to use application interfaces in a more standard way.
  2. Taking some business processes and turning them into web services.
  3. Introduction and full use of the enterprise service bus.
  4. The generation of Business Process Execution Language(BPEL) --the ability through business processing modelling tools and BPEL to create different application behaviour without changing the software
Mr. Rippert stated in the interview that many organizations have an ESB but have yet to make full use of it. He further stated that most companies are still in phase one. This positioning for ESB lies in contrast to statements made by Burton Group analyst Anne Thomas Manes in a recent discussion on the Service Orientated Architecture(sic) Yahoo Group. Anne says:
...an ESB is not on my list if the few "basic components" that I recommend for getting started with SOA. In fact, I discourage people from starting with an ESB. An ESB does not encourage good SOA behavior. ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos.

Referencing her book, she goes on to mention that the basic components include:
  • One or more service platforms (e.g., .NET, a Java EE app server, etc.)
  • An SOA management solution
  • A registry
  • An XML gateway if services will be exposed outside the firewall
Referencing an earlier posting from a group member, she says:
"...an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure. Many ESBs also support reliable messaging, asynchronous messaging, and pub/sub exchange patterns. These capabilities can also be pretty useful--but probably not in the initial stages of a SOA project. (Every organization has lots of projects to choose from that don't require these capabilities.) At a later stage in a SOA project, you might also want an orchestration engine, and most ESBs supply one--but that definitely isn't where an organization should start a SOA initiative. All of these capabilities are things that you don't need when first getting started. Therefore an ESB should be a later-stage purchase."
This seems to fit with Mr. Rippert's view that many organizations have ESB already, but have not made full use of it. Ms. Manes's comments also serve to help define the field of ESB and it's appropriate set of capabilities by suggesting features that many ESBs support.

According to the Wikipedia definition of ESB, an ESB has the following features:
  1. it is an implementation of Service Oriented Architecture
  2. it is usually operating system and programming language agnostic; it should work between Java and .Net applications, for example
  3. it uses XML (eXtensible Markup Language) as the standard communication language.
  4. it supports Web services standards
  5. it supports messaging (synchronous, asynchronous, point-to-point, publish-subscribe)
  6. it includes standards-based adapters (such as J2C/JCA) for supporting integration with legacy systems
  7. it includes support for service orchestration & choreography
  8. it includes intelligent, content-based routing services (itenerary routing)
  9. it includes a standardized security model to authorize, authenticate, and audit use of the ESB
  10. it includes transformation services (often via XSLT) between the format of the sending application and the receiving application, to facilitate the transformation of data formats and values
  11. it includes validation against schemas for sending and receiving messages
  12. it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
  13. it can conditionally route or transform messages based on a non-centralized policy - meaning that no central rules engine needs to be present
  14. it is monitored for various SLA (Service-Level Agreement) thresholds message latency and other characteristics described in a Service Level Agreement
  15. it (often) facilitates "service classes," responding appropriately to higher and lower priority users
  16. it supports queuing, holding messages if applications are temporarily unavailable
  17. it is comprised of selectively deployed application adapters in a (geographically) distributed environment
This wikipedia definition concedes that "the exact definition of an ESB varies".

Both Ms. Manes and Mr. Rippert seem to agree that an ESB is useful and represent a later stage set of functions for SOA deployments. The wikipedia definition can serve as a starting point for discussion about how this useful technology is defined.

In the ensuing discussion, please focus on the definition of an ESBrather than on the views of the industry experts cited in the article.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

ESBs are general purpose proxies by Stuart Charlton

I think the Wikipedia definition can be rather confusing.

An ESB, to me, is a decentralized proxy service that can manage, monitor, or enhance a service's capabilities. It's not necessarily the foundation of an SOA, but it can be very useful and you'll likely build such capabilities somehow into your SOA, whether you acquire an ESB product or not.

Not everyone will create a uniform, equally capable service contract and/or interface in their SOA. Requirements and contracts will vary. People will use different protocols, data types, and operations. Furthermore, SOA is about decentralized computing -- services are autonomous, and there is no "central" broker or messaging technology to knit them together, thus the network needs to be taken into account, along with all the classic challenges of distributed computing: partial failure, concurrency, latency, etc.

Thus:
- Service interfaces (operations, data types) need mediation, enrichment, and routing
- Service contracts need capability mediation (reliability, availability, security, etc.)
- Services need dependency management and monitoring
- All of this shouldn't require coding

That's what an ESB should do -- quick, simple, code-free intermediation & management. It's a configurable proxy. Features like orchestration, BPM, etc. belong in a separate architectural component.

Some examples:
- A consumer talks HTTP/S based authentication, a producer uses WS-Security
- A consumer talks HTTP/RSS, a producer uses WebSphere MQ or JMS
- A consumer talks HTTP/REST and URIs, a producer talks SOAP/WSDL
- A consumer has one set of credentials, a producer has another set (keychain mapping).
- An FTP site is the "service interface" for one end, but the files are broken up into JMS messages on the other end
- A message may need enrichment before routing to a destination, so I can perform callouts to gather extra information
- Protocol independent load-balancing and/or failover is required for a producer
- Messages need to stored and forwarded, retrofitting reliability onto an unreliable service

Formal Definition of Enterprise Service Bus by Dave Chappell

Late last year, Sonic put forth to the industry an "ESB
Architecture and LifeCycle Definition"
which is intended to serve as a reference model for ESBs. It is a document that is intended to show that when you look inside an ESB there are definite moving parts, which are all there for a reason.

The document contains many UML diagrams that show entity relationships between the moving parts, which include things like service endpoint abstraction, service containers, process control, and messaging (WS-RM, JMS, etc). It includes the word "lifecycle" in the title because it goes beyond more than just describing the runtime components, but the relationship between the runtime and other infrastructure pieces such as configuration and deployment repository, which are necessary to cover the full lifecycle of modeling of business processes, configuration of mediation services (such as content based routers and transformations), configuration of protocol and interface technology (connectivity) for appservers, erp systems etc, through to testing, debugging, and deploying a production SOA environment.

It is intentionally devoid of marketing benefits statements, and is purely focused on the moving parts and how they fit together. It is targeted at architects who are trying to understand what kinds of things they should be looking for when looking at all of the SOA infrastructure offerings that are being labeled as ESB's these days.

To give full disclosure here - I work for Sonic. I encourage you to have a look at the paper.
Dave

Spot on Wikipedia by Dave Chappell

I think the Wikipedia definition is spot on, with a caveat on item #1. I have found that its confusing to say that an ESB is an implementation of a SOA. While that may be technically accurate (the ESB implementation may itself be based on SOA principals), its more important to state that an ESB be used as a backbone upon which to build a SOA. In other words, organizations like yours build service oriented architectures, and and ESB is infrastructure upon which to build it.

That being said...while an ESB is a very important part of a SOA infrastructure, it is not the only one. It is also important to have infrastructure for things like SOA governance and Web Service Management.

Dave

ESB definition by Paul Fremantle

The wikipedia entry is a good list of stuff that you can get in an ESB, but you certainly don't need everything in that list to have an ESB. A couple of years ago, IBM was pushing the line that an ESB is a pattern and not a product. At the time, IBM got a lot of stick from the analysts, and they changed that line. Time seems to be proving them right though: the the most important thing about an ESB is the pattern and not the product.

The pattern of an ESB is that it is a single shared communications framework for all service interactions to pass through. And once that happens it can do the mediation, logging, and routing that is required. A lot of companies have implemented this model without any "ESB product" and they reap the benefits whether or not the software they use has an ESB sticker on the side.

So an ESB is a communications infrastructure that enables mediation. What topology should an ESB have? I think the topology should be flexible: you can build an ESB as a single big broker in the middle, or as lots of smart endpoints. Of course the topology affects the manageability, but as long as their is a central registry/repository to configure the ESB then it works fine. The key to this is that an ESB should be driven by policy not by writing code.

What do I mean by policy? What I mean is that you should be able to write rules/configuration/filters, store them centrally (in a registry or repository) and have this policy apply uniformly. Even if I have a service already running, I should be able to add a rule that logs the interaction without changing the code at each end.

Let's come back to what Anne Thomas Manes is saying: you don't need an ESB, just endpoints, a registry, a gateway and a management proxy. Well if you have those things, you might not have a product labelled ESB, but you certainly have everything you need to implement your routing, logging and management centrally. So from the pattern perspective that is an ESB.

Finally I'd like to +1 a lot of the things Stu said above - especially the comment about orchestration. Putting stateful, long-running business process management into the ESB is obviously tempting - otherwise so many people wouldn't be doing it. But it is very dangerous - because once you start getting business logic into the middle of your network you will end up with the most almighty tangle.

Re: ESBs are general purpose proxies by Kit Davies

"Features like orchestration, BPM, etc. belong in a separate architectural component."

Mostly agree except that BPM is useful for converting/mediating between sync & async models.

Clear pragmatic definition of an ESB by Demed L'Her

Overall I tend to agree with most of what is said in the Wikipedia entry for ESB. Mainly because it fits well into my pragmatic definition of ESB as a tool (vs a pattern). And as a tool, it can easily be described with a list of concrete features.

I'm also excited to see such a distinguished audience trying to nail down a definition of ESB.

A couple of things I disagree with Wikipedia on their ESB definition:

"[ESB] is an implementation of Service Oriented Architecture"


Seems to me a little bit like saying that a feature of a JVM is that it is written in Java - does that really matter? Probably not. Even if the internal ESB implementation follows SOA guidelines, that doesn't make this fact a salient ESB feature.

"Contrary to the more classical EAI approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary"
.

This is a little confusing - are we talking about SOA or ESB? If you follow the initial idea that ESB is a tool that can be used to enable SOA, then this paragraph doesn't really belong here ( an ESB definition). In addition, while SOA describes an architecture, EAI merely described an industry. Actual architectures used in EAI projects were extremely diverse (with arguably a majority being of the hub and spoke type). So I am not sure that it makes much sense to compare EAI to SOA (or ESB).

(and, but I'm nitpicking here, I'd drop the "intelligent routing" in #8 - might make sense in a marketing collateral, but probably not in Wikipedia).

Re: Clear pragmatic definition of an ESB by Demed L'Her

ESB as a tool

I should really have said "ESB as an infrastructure".

Re: ESBs are general purpose proxies by Demed L'Her

It's only upon reading your comment on "proxies" that I realized that Wikipedia didn't mention anything about the fundamental ESB concepts that are mediation and service virtualization.

The central notion of a service by Joost de Vries

I see a lot of ESB definitions along the lines of the Wikipedia definition: a long checklist of capabilities or products; transformation, routing, queueing etc. etc.
To me the essence should be that it raises the level of abstraction from thinking in messages and ad-hoc chaining of message processing capabilities (first a bit of content-based routing, then some transformation, oh I need to add a time-to-live property to the message, etc.) to thinking in services.
To me an ESB should allow service-oriented development, as in object-oriented development. So it should show a notion of a service as a software artefact. A service would probably be typed and depending on its type should specify some attributes and exclude others. Adding a servicedefinition to the registry is all that's needed to publish a service implementation.
To realize that level of abstraction you'll need all the capabilities that are mentioned and more. But it's nothing without the central notion of a service.

Minimalist ESB Definition by Antony Reynolds

Problem with ESB is that is now quite a highly charged and emotive term - always seems to happen when vendors get involved (disclaimer I work for Oracle).

I like to view an ESB as a virtualisation layer for services in an SOA. It is just a tool that can help or hinder SOA like so many other tools.
I view an ESB as providing the following key functions which have already been amply expanded on in this discussion.

* Connectivity via a variety of mechanisms (adapters, WSIF, Web Services, Database, JMS ...)
* Message Transformation (including domain value transformation)
* Message Routing

Using an ESB to provide a service virtualisation layer that decouples services from each other, whether as part of a point to point integration or as part of a BPEL process, allows us to play with abstract services at the business process layer.

Just my tuppence worth.

Re: Clear pragmatic definition of an ESB by Dave Chappell

Regarding the excerpted monolithic hub and spoke comment, I would like to add some clarity, particularly since that part of the wikipedia definition looks very close to something I say in my ESB book.

If the SOA implementation is going to be a distributed one, then it doesn't make a whole lot of sense to have that be supported by a monolithic hub and spoke EAI server. The benefits of hub and spoke are mostly that you have a single place to host your orchestrations, routing logic, data transformations, and adapters. However, this can also become a central bottleneck for processing and a single point of failure.

The ESB runtime infrastructure which provides transformation, routing, adapters, etc should allow the selective deployment of what you need exactly when and where you need it. If you need to scale the SOA to hundreds or thousands of services, then you should be able to install the supporting pieces where you need them. For example, if you need to use an adapter to access an ERP system at a remote manufacturing plant, then you install the minimum infrastructure necessary there to host an adapter, and not the whole EAI broker stack.
Provided that the management infrastructure of the ESB knows where all the remote pieces are, and allows a unified view of the ESB enabled SOA, then you don't lose any of the percieved benefits of centralized hosting.
Dave

Re: The central notion of a service by Dave Chappell

Bravo! I can't believe I didn't notice that one was missing in the WikiPedia definition either. Yes, service oriented development and the enablement of service level abstraction should be a foremost capability for an ESB.
Dave

There is no E in ESB by Steve Jones

The Wikipedia article falls into the trap of declaring that an ESB can do everything, so it includes process, deployment, rules, integration, content based routing etc etc. In other words its an application server in another name.

The second bit is that its a myth to believe that a product will be enterprise wide. EAI taught any sensible company that believing that a product bought today will still be your enterprise solution in 4 years time is madness, and so it is with ESBs.

My proposal would be to separate out the three pretty distinct problem classes when doing an assessment. One challenge is leveraging the current estate and getting functionality out (Integration), the second is building new applications (Build) and the final is managing the interactions between these new applications (Business). I blogged on it a while back.

Integration products have very different requirements and drivers from ones that aim to enable interaction in a more standards oriented space, and I'm not sure why it makes sense to confuse the two domains. Equally building new applications (in process or OO languages) requires different skill sets and approaches.

An Integration Bus will be measured on its power, a Business Service Bus on its simplicity and an Application Development solution by its flexibility. And any reasonably sized business will not have one solution that fits all their needs.

Enterprise Nervous System Pattern by John Gilbert

I fall into the 'ESB is a Pattern not a Product' camp. I believe all the necessary technology pieces exist out there, so I don't need to buy a product. That said, it is necessary to understand the pattern. I discuss this at length in my article 'AOP-Enable ESB'.

The basic idea is to think of your enterprise as a nervous system. Things happen which cause other things to happen. For example, a service is invoked, an event is published to indicate what happened, the event is evaluated by whatever is listening, the listeners might invoke other services, and so on, and so one.... Just like in the real world.

Way back when before all the marketing spin, it was just Event Bus (EB). Then SOA became the buz, so the S (Service) was added: ESB. Then thanks to Enterprise Architectre (EA) the E no longer stood for Event. So, I think of it as Enterprise Event/Service Bus Architecture (EESBA). But that is too long, so I just prefer Business Oriented Architecture (BOA), with the focus on catering to your enterprise nervous system to accomplish your business goals.

Intelligent Routing (was - Re: Clear pragmatic definition of an ESB) by Dave Chappell

(and, but I'm nitpicking here, I'd drop the "intelligent routing" in #8 - might make sense in a marketing collateral, but probably not in Wikipedia).


Intelligent routing means being able to examine the content of a service request and route it to one or more potential recipients based on the value of the data that's being carried, some header information that was placed in the request, or even contextual information that is associated with the process context (if there is a process flow being executed).

This can done using Xpath, Xquery, Javascript (or your scripting language of choice) for example. This type of routing adds a bit more intelligence to the SOA over static routing techniques. This is one example of mediation that an ESB should provide.

Just a nit here--I also noticed that the Wikipedia definition attributes intinerary based routing in #8 (intelligent routing), but I think it belongs more in #7 (service orchestration)
Dave

Re: ESB definition - Pattern vs Product by Dave Chappell

A couple of years ago, IBM was pushing the line that an ESB is a pattern and not a product. At the time, IBM got a lot of stick from the analysts, and they changed that line. Time seems to be proving them right though: the the most important thing about an ESB is the pattern and not the product.


The primary reason IBM started the pattern vs product issue was because they were getting the "stick" from the analysts about what their ESB story was. They didn't have a product, so they came up with the Redbook that basically says if you "squint" the right way, you can see an ESB in some combination of the various sea of infrastructure products under the Websphere brand. This to me is a Platypus approach to SOA infrastructure and misses a HUGE point about what an ESB is for.

The whole idea behind and ESB is that it IS a product..one that comes from a single vendor that is designed to be pulled off the shelf, installed, configured, and deployed as a common infrastructure in support of a broad scale SOA initiative. By taking that approach, the user can take advantage of the fact that the ESB vendor has focused on providing a consistent environment for interfaces, connectivity, process control, security, QoS settings, scalability, high availability, etc, and does it in a way that doesn't require a hoarde of global services to set that up and keep it humming.

I know you're an ex-IBM'er Paul, so I'm curious to know what you mean by "Time seems to be proving them right" statement. Are you saying that there are more customers taking the platypus approach rather than adopting their recently announced product?
Dave

Re: Intelligent Routing (was - Re: Clear pragmatic definition of an ESB) by Demed L'Her

We're in agreement on the function; no question there - routing is essential to an ESB. I was simply nitpicking on the choice of the word "intelligent" which I tend to shy away from. Most ESB's use simple predefined routing rules on context, content or headers (using XPath for instance), and qualifying them of "intelligent" seems to me a bit of a stretch.

Re: There is no E in ESB by Joost de Vries

The second bit is that its a myth to believe that a product will be enterprise wide. EAI taught any sensible company that believing that a product bought today will still be your enterprise solution in 4 years time is madness, and so it is with ESBs.

Yeah, the if-you-standardize-on-our-tool-you're-integration-problems-are-solved product. That's why a pattern-driven design or - architecture is needed and tools that are open and leave room for such pattern-driven design are very worthwhile.

I must say I like the definition that's forming here: an ESB facilitates publishing of services at a higher level of abstraction than message-types but does not contain service implementation in any way. So an ESB excludes orchestration, workflow, service composition, rule engines and portals.

Re: There is no E in ESB by Stefan Tilkov

I'm not entirely sure that anybody participating in this thread really cares, but my definition of an SOA is "something that vendors claim you need because they have something to sell".

Basing an SOA on an ESB (in the sense of an ESB product) is IMO a fundamentally misguided way to approach the concept.

To ESB or Not to ESB by Mark Hapner

For full disclosure, I work for Sun as an architect of its integration products.

While it's interesting to debate what should be in an ESB box, this is somewhat peripheral to the question of what middleware an organization should buy to support its creation of global application collaborations ('global' in the sense that its participating applications could potentially be anywhere on the Net, running on any platform). There is a 30+ year history of application integration that started with batch extract-transform-load and now is beginning to enter the age of global collaboration. Global collaborations are built with an architecture that is an interesting synthesis of what the industry has learned from this history. In particular, from three highly successful integration strategies - MOM (Message Oriented Middleware), EDI B2B and Web Sites.

In all three cases, collaborating applications exploit a protocol interop layer without which integration couldn't take place. However, the usefulness of the collaborations comes mainly from the work they do and it takes a lot of effort at the application layer to create something that justifies the development investment. You can spend $$'s on MOMs, B2B Gateways and waste time fooling around with Apache without the least benefit.

Much of what the industry says about SOA illustrates how little it actually understands about what it takes to breath life into a global application collaboration. Its like OO programming experts and MOM vendors attempting to explain how to create a successful web site. Frankly, they wouldn't know one if it fell on them.

As a whole, the industry is just coming to grips with what it takes to create successful, useful global application collaborations. This will be a technical and business value journey just like web sites have been and are a journey.

Developers and IT management don't want to hear this, but the truth is that global collaborations are not simple and they are not cheap. Neither are good web sites. You create a new web site because you envision the potential to create an important new collaboration of great value and you are willing to do whatever it takes to breath life into it. The same is true for a global application collaboration. Those that think of 'services' and 'SOA' as some kind of new programmatic 'reuse' technique are way off base.

So, the core question is where to start ...

Every vendor wants to sell you their tools and middleware and Sun is no exception. What tools and middleware should you buy to get started? It may be heretical for a middleware vendor to say this, but the first thing you need to do is identity a few good global collaborations that it is worth your effort to create. Once you have a practical focus you will see what support you will need at the business logic, infrastructure and protocol layers to handle the collaboration facing portion of your apps and what you will need to handle the internal integration of the apps.

You will likely find that much of what comes in an ESB box will be helpful. It typically contains things that help with both the global collaboration aspects and internal aspects of the job as others have discussed here. Given the marketing popularity of 'ESB' and 'SOA' all vendors have applied them in various ways to their products. Is there an ESB architecture that is the magic bullet for global app collaboration success, I doubt it. If there isn't, than this discussion just degrades to comparison of ESB product feature sets.

What is clear is that developers of globally collaborating applications will be using a wide range of business logic level technologies to implement their apps - from scripting, to Java annotations, to business rules, to asynchronous orchestration, to HIPAA validators, to ... That the better a 'platform' supports directly mixing and matching a diverse set of these within an application the more productive its developers will be. This doesn't require some complicated new 'component model'. All these technologies share the ability to produce and consume messages. It just requires some basic platform level collaboration and tools collaboration so that developers can build the next generation of globally collaborating apps. Most ESB vendors provide their own form of this layered over the Java Platform.

To see a glimpse of how the Java Community has begun to extend the Java Platform to provide this in an open way, download the Java EE 5 Tools Bundle Beta ( java.sun.com/javaee/downloads/index.jsp) and experience how it allows you to treat BPEL as yet another way to implement business logic within a Java EE app.

Re: There is no E in ESB by Joost de Vries

So, Stefan, how would you describe the design(architecture) and infrastructure(tools) needed to publish your SOA? (that's what I'd like to see as an ESB btw)

In other words: you can say "that's not an ESB" but you'll need something in that space to do SOA anyway.

Re: To ESB or Not to ESB by Joost de Vries

Mark,

I wonder why you equate SOA with 'global application collaboration'.
Yes, there's a part that's about the value network that an organization is participating in. Not necessarily global, but ok.
But there's also a part that's about 'application collaboration' within an organization.

Developers and IT management don't want to hear this, but the truth is that global collaborations are not simple and they are not cheap. Neither are good web sites. You create a new web site because you envision the potential to create an important new collaboration of great value and you are willing to do whatever it takes to breath life into it. The same is true for a global application collaboration. Those that think of 'services' and 'SOA' as some kind of new programmatic 'reuse' technique are way off base.

I'm not sure what your point is. Do you mean to say that one should not go about publishing all kinds application functionality for possible future reuse? (I agree)
Or do you mean to say that organization internal integration does never gain by the central central notion of a business service, even as a central software construct in the integration space?
If so, I disagree: I think EAI as it is can become quite complex very quickly. The central notion of a busines service can mitigate this complexity imo by using the old measures encapsulation (a system does not need to know about other systems protocols, formats, availability, ...) and separation of concerns (do not handles message formats, message patterns (synchronicity etc.), data normalisation etc all in the same message-flow code in your broker, as you would do with old-style integration, but separate these things out to separate OSI-like layers).
I'm confused by your website metaphor. How's SOA/ESB similar to building a website?

Re: To ESB or Not to ESB by Mark Little

Hi. For disclosure purposes I'm Mark Little, JBossESB Development Manager and Director of Standards at Redhat/JBoss.

I find it interesting that the Wikipedia entry says nothing about interoperability. Although Web Services are important for interoperability purposes, they're not the only SOA-related technology that people use. Furthermore, Web Services don't address portability at all.

I think interoperability is an important aspect of an ESB/SOA infrastructure and one that should be considered from the outset and not as a secondary thought.

Re: To ESB or Not to ESB by Ron Ten-Hove

(Full disclosure: I work for Sun, developing integration products.)

People use the term 'interoperability' in many different ways. In the context of an ESB, it can mean that the various "nodes" on the bus can interact (exchange messages appropriately), even if those nodes are from different vendors. Or it could mean that hetereogeneous busses can form a "federation" of sorts. Or it could simply mean that the integrated applications/data sources/protocols can be used in a fashion that is blind to the underlying technology (e.g., service-oriented integration).

I agree that interoperability is very important. Could you expand on how you see interoperability manifesting itself in a 'proper' ESB?

Re: There is no E in ESB by Stefan Tilkov

Missed your post earlier, sorry. Having an ESB, to my mind, usually means having a single one. That's what I object to. As long as it's your interfaces and wire standards that form your SOA, I don't care about the implementation details, whether it's a single or multiple ESBs or something else.

Re: To ESB or Not to ESB by Mark Little

So I've been developing distributed systems for over 20 years and interoperability isn't peculiar to ESB, but I think it's relevant: it cuts across different vendor service implementations in the same ESB as well as different services residing in different ESBs. Take the case of Web Services. There are two main reasons for using Web Services: (i) cross-platform/cross-vendor interoperability, and (ii) internet scale computing. At the moment, and probably for the forseeable future, (i) is the most important aspect. With the exceptions of TCP/IP adoption and the original WWW, we have never been at a point in distributed computing history where all of the major vendors have agreed on the same underlying platform. CORBA didn't get there. DCE didn't get there. Neither did DCOM or J(2)EE; the latter being more concerned with portability than interoperability.

Where does this relate to an ESB? Well an ESB should follow the same principles as far as interoperability is concerned. In my definition, an ESB is a SOA infrastructure, which means that you should be able to leverage existing infrastructural investments *at both ends of the pipe*. I shouldn't have to ensure that services running in different enterprises that want to talk to one another have to use the same ESB. Web Services are fine for many things and particularly where interoperability is more important than, say, performance. However, there are many cases where interoperability and performance, or interoperability and reliability/scalability/whatever-ability are needed, and in those cases SOAP/HTTP, or SOAP/JMS doesn't cut it.

In summary, my point is that interoperability isn't an issue that should be punted to Web Services or ignored. It (or lack thereof) is another route back to vendor lockin, which ESBs have been touted as breaking.

Re: To ESB or Not to ESB by Mark Hapner

The web site analogy comes from the fact that both web sites and services are technologies for creating global collaborations - 'global' in the sense of that the technical collaboration is defined using a global on-the-wire design that does not depend on proprietary elements or isn't capable of working globally. Just like internal web sites shouldn't depend on a specific browsers or proprietary HTTP extensions - internal application collaborations shouldn't be non-global.

The creation of a living global collaboration of applications is what determines if you are doing service based integration just as a running web site with a healthy community of users is what determines if you are doing web site collaboration. My point on 'reuse' is simply that creating collaborations one-by-one is the operational objective rather than some generic software 'engineering' objective of 'reuse'. Each one takes significant commitment and must be motivated by its direct value just as web sites are.

Distributed vs brokered by Eric Newcomer

One thing that hasn't come up so far is the important distinction between ESB infrastructure that's distributed (i.e. endpoint oriented aka agent based) and ESB infrastructure that requires a broker, server, or hub.

Some folks on this discussion have mentioned the Web, which works this way. If we are to really achieve interoperability (as Mark correctly emphasizes) it needs to be achieved using a distributed approach. Meaning whichever SOA infrastructure is being used needs to interoperate with any other SOA infrastructure being used. This is the place where the JMS oriented ESBs tend to break down in meeting SOA requirements.

We have also recently seen articles about how and why JEE is not suitable for SOA infrastructure. Certainly Java and JEE based applications are going to have their place in any modern SOA. However, JEE follows the classic three-tier structure pioneered by TP monitors for the purpose of scaling up a single application, essentially by multiplexing client and data resource connections.

SOA is a different game. It's all about services talking directly to each other, like browsers to Web servers, regardless of the implementation environment. It is not about scaling up applications, or developing bespoke applications. It is all about heterogenous applications sharing data.

The distributed, or agent-based approach, is better suited for these kinds of "n-tier" or tierless applications.

Re: ESBs are general purpose proxies by Dave Chappell

Its has been Sonic's vision that an ESB is so much more than just a proxy. An ESB should be a highly distributable infrastructure capable of connecting, mediating, and coordinating the interaction between a variety of diverse applications and services across a variety of platforms, protocols, and interface technologies. I agree with these statements you make -


Thus:
- Service interfaces (operations, data types) need mediation, enrichment, and routing
- Service contracts need capability mediation (reliability, availability, security, etc.)
- Services need dependency management and monitoring
- All of this shouldn't require coding


but how can you really provide support for availability and reliability with a simple proxy approach? If its just a proxy, then what about its availability and reliability?
Dave

Re: There is no E in ESB by Paul Vencill

I love it!! I think I'll probably quote you on that, Stefan.

As a completely unrelated question; your name sounds Bulgarian, is it?

Re: Minimalist ESB Definition by Leo Gan

Problem with ESB is that is now quite a highly charged and emotive term - always seems to happen when vendors get involved (disclaimer I work for Oracle).

I like to view an ESB as a virtualisation layer for services in an SOA. It is just a tool that can help or hinder SOA like so many other tools.
I view an ESB as providing the following key functions which have already been amply expanded on in this discussion.

* Connectivity via a variety of mechanisms (adapters, WSIF, Web Services, Database, JMS ...)
* Message Transformation (including domain value transformation)
* Message Routing

Using an ESB to provide a service virtualisation layer that decouples services from each other, whether as part of a point to point integration or as part of a BPEL process, allows us to play with abstract services at the business process layer.

Just my tuppence worth.


And... where is the *definition*? Sorry, Didn't see any.

Re: Intelligent Routing (was - Re: Clear pragmatic definition of an ESB) by Leo Gan

To me it is a lot of stretch :) It doesn't mean anything.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

32 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT