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&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/> . _____ 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/
