|
Mukund,
> I still believe an ESB/broker is only a moderately better
(if at all)
> solutioin than a generic Web Service or JCA
adaptor.
>
The above statements seems to be indicating that ESB is
competing with
Webservice or JCA semantics - while in reality, many ESB
servers (including
those from Fiorano) have a built-in support for both "generic
Webservice
hosting and invocation - as well as JCA
adapters.)
I am sure I have misunderstood the intent of your message. Can
you help
me understand it better?
Thanks,
Amit Gupta
VP Engineering,
Fiorano Software Inc.
----- Original Message -----
Sent: Monday, March 13, 2006 1:24
AM
Subject: Re:
[service-orientated-architecture] Foody on SOA vs. ESBs
Gregg:
We are in agreement on almost every aspect of
your tech overview and use case below. I completely agree that an ESB is
relevant. The difference lies in merely two aspects:
1. Architecture
abstraction: I still believe the architecture abstraction for an ESB should be
a location independent "bus". This is indepedent of the reality of most
deployments. We are just talking about the abstraction. You worry me by
mentioning "central broker as an esb" as many times as you do.
2.
Your relative focus on lagacy adaptation to an SOA. Of course anybody involved
in integration projects knows that adaptors take an inordinate focus but I
still believe an ESB/broker is only a moderately better (if at all) solutioin
than a generic Web Service or JCA adaptor.
Of course, what would be
useful in this context is to start creating a listing of 10 features you would
call important in an ESB and prioritize them. I would be interested in
something like that.
Mukund Balasubramanian
CTO/Infravio
Inc.
-----Original Message-----
From: Gregg Wonderly
<[EMAIL PROTECTED]>
To: [email protected]
<[email protected]>
Sent: Sat Mar 11
20:38:37 2006
Subject: Re: [service-orientated-architecture] Foody on SOA
vs. ESBs
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
SPONSORED LINKS
Computer software <http://groups.yahoo.com/gads?t=ms&k=Computer+software&w1=Computer+software&w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service-oriented+architecture&c=5&s=121&.sig=fpXcvMH1T7dIWKArM_WfrQ>
Computer aided design software <http://groups.yahoo.com/gads?t=ms&k=Computer+aided+design+software&w1=Computer+software&w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service-oriented+architecture&c=5&
amp;s=121&.sig=aLmDc98q-ezguJlYUiw3Rw>
Computer job <http://groups.yahoo.com/gads?t=ms&k=Computer+job&w1=Computer+software&w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service-oriented+architecture&c=5&s=121&.sig=S4rCT77z3xUeesYhvuqZ3g>
Soa <http://groups.yahoo.com/gads?t=ms&k=Soa&w1=Computer+software&w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service-oriented+architecture&c=5&s=121&.sig=XVYKxWnIx0EdfkBS6DaTLQ>
Service-oriented architecture <http://groups.yahoo.com/gads?t=ms&k=Service-oriented+architecture&w1=Computer+software&w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service-oriented+architecture&c=5&s=121&.sig=i-_f4IMs4JCXEMjxqUGGtA
>
_____
YAHOO! GROUPS LINKS
* Visit your group
"service-orientated-architecture <http://groups.yahoo.com/group/service-orientated-architecture>
" on the web.
* To unsubscribe
from this group, send an email
to:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
* Your use of Yahoo! Groups
is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/>
.
_____
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
