Mukund Balasubramanian wrote:
> But isn't the central notion of an ESB the "bus" concept (as is obvious from
> the
> name).
There are well known hardware bus architectures that are point-to-point
(telephone), broadcast (ethernet, cable tv etc), switched broadcast etc. Using
the term bus in software implies a virtualization layer to me. That is a
single
software interface that standardizes the interface that all others see.
> I always interpreted this as providing the logical equivalent of a
> "transport"
> mechanism which connects every "place" (application) to every other for
> "passengers" (messages).
This is why the term ESB is a "thingy" more than an item, or a concept. It can
be both, one or the other, or neither depending on what your abstraction is.
> I still find a lot of logic to the concept and hence to the products. Web
> Services today are notoriously location centric (think service endpoint URL)
> even though they don't HAVE to be.
A mesh network is difficult to manage, and can create a complicated
infrastructure with a multiplication in actual traffic. So, you have to decide
in your architectural steps whether you need each application to have its own
connection to every other application its talking to, or do you need to have a
centralized broker based bus system, both, or something completely different
(such as just using UDP, mulitcast or otherwise).
> So I don't necessarily agree with "The power of an ESB thingy is that it
> provides the neutralization or
> standardization layer away from every application." Nor do I agree that ESB's
> and SOA's compete in any way.
If you have control over the legacy application, you can change it to talk
differently to the world. If you can't change it, then you either live with
its
API, and have applications that talk to it with CORBA, another app with web
services etc. Now you have multiple security implementations, additional
software and systems knowledge/support issues etc. On the other hand, if you
use a centralized broker, or a neutralizing communications proxy "bus", there
are opportunities to start reducing your need for legacy systems support, to
some degrees. You don't have to teach every developer about every applications
interfaces from a systems perspective.
A broadcast based pub/sub broker, setting in the middle, allows new process
based systems to be created by watching and managing a higher level of state in
your enterprise applications.
As an example, we have a customer that uses our broker to send microcontroller
device data into a SQL database. We do the translation from binary arrays to
the brokers generic data objects in one module. That module then publishes the
data object for routing. The delivery manager and queue manager interact to
make all of the deliveries occur. Simple enough. The customer has a 'demand
poll' feature that they use to get instantaneous readings. It needs to feel
like a locally managed operation, but has to utilize the features of the
services that already exist. So, their demandpoll client talks to a module in
the broker which sends a modbus based request to the device. The device
responds by sending in a data report. As the data passes through the broker, a
new module sees the data for the requested device pass through, and it notifies
the client that the data is now present.
Without the use of a centralized broker, a lot more logic would be needed in
other places where production systems would have to be altered, tested and
redeployed. By using the broker, and its container architecture, we can
provide
a really cheap solution which is highly functional, and doesn't impact the
existing architecture.
There will be solutions with lots of different needs. An ESB 'thingy' will
help
you to promote the standards of your architecture into first class citizens of
your SOA.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
