RE: [service-orientated-architecture] Foody on SOA vs. ESBs

Mon, 13 Mar 2006 08:16:43 -0800

Amit:

 

That is exactly the point I am trying to make.

 

All I am meaning to say is that technology neutralization/legacy adaptation is not the reason to go out and purchase an ESB since bringing you legacy into the new world can be done by technologies SUCH AS Web Services and JCA (this is the way I see it done in our customer base).

 

So my point is that ESB does NOT compete with Web services/JCA semantics but provides an architectural abstraction and functionality above the adapter layer.

 

Does that make sense?

 

Mukund Balasubramanian

CTO/Infravio Inc.

 

 

From: Amit Gupta (FSI) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 13, 2006 2:26 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Foody on SOA vs. ESBs

 

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
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



Reply via email to