On 7/2/06, Luie Matthee <[EMAIL PROTECTED]> wrote: > > Hi > > I've been following this thread with some interest, as I've worked for a > number of vendors with ESB offerings. > > <your comments>
Actually, this was Dennis's comment > The main drawback I see to using an ESB is that you're building your > enterprise around proprietary software. Even the open source ESBs all > have their own unique ways of configuring and managing services. The net > effect is that you're locked into a particular service bus and will find > it increasingly difficult to break free over time. > My comment in response to Dennis's comment was: <ATM> The same can be said about all SOA infrastructure products. Lock-in is a fact of life. As soon as you implement anything, you're locking yourself into a product. I think it's better to lock yourself into a single product for configuration and management than to deal with dozens of different tools and procedures for configuration and management. </ATM> > one or more service platforms (e.g., .NET, a Java EE app server, etc.) > > </your comments> > > I'm curious to hear your position on .NET in terms of its proprietary > standing & why you consider it one of the viable application platforms of > choice. > > cheers Luie > If you are developing applications that are to be deployed on a Windows platform, and you don't foresee a need to port them to other platforms, then .NET is certainly a viable platform. As I said in my original response to Dennis, as soon as you implement and deploy a solution, you've locked yourself into that platform -- whether it's IBM WebSphere, BEA WebLogic, JBoss JEMS, Sonic ESB, webMethods Fabric, Sun SeeBeyond, Apache Axis, Spring, Struts, Hibernate, or whatever. If you think that developing with Java somehow gives you vendor and/or framework independence, you're deluding yourself. .NET is a comprehensive, easy-to-use, development framework -- far easier than any Java-based counterpart. And it's certainly better optimized for the Windows platform than any Java framework. It performs better, and except for the most extreme cases, supports comparable scalability. Why wouldn't it be viable? Anne > > Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > > First, let's establish your meaning of the term "ESB". I assume that you are > talking about a product. Examples include BEA AquaLogic SB, Cape Clear ESB, > Fiorano ESB, IBM WebSphere ESB, IBM WebSphere Process Server, IBM WebSphere > Message Broker, IONA Artix, Oracle ESB, Software AG crossvision, Sonic ESB, > Tibco BusinessWorks, and webMethodsFabric. Also, open source projects: > ServiceMix, Mule, Celtix, etc.You are not referring to what IBM first termed > "an architectural pattern". And you are not referring to a multi-product > services infrastructure organizations build to support SOA initiatives. > > I do not believe that an ESB is an essential component of SOA. When it > comes right down to it, you don't need any new products to do SOA. After > all, SOA is about design, not technology. Nonetheless, products can be very > useful, and I recommend buying at least a few basic components to get > started. > > The vendor hype surrounding ESBs has been very effective -- you'd be amazed > how many requests I get from my clients for help selecting an ESB. But then, > organizations frequently want a quick-fix solution. The vendors (and many > analysts) are telling them that an ESB is all you need to get "instant SOA", > or at the very least, that its an essential component. > > But 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. > > In my book, the basic components include: > > > one or more service platforms (e.g., .NET, a Java EE app server, etc.) > a SOA management solution (e.g., AmberPoint, Actional, SOA Software) > a registry ( e.g., Systinet, Infravio) > an XML gateway if services will be exposed outside the firewall (e.g., IBM > DataPower, Reactivity, Forum, Layer 7) > As you say, 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. > > I also definitely don't recommend using an ESB as a central hub for all SOA > traffic. You and I had a private discussion a couple of days ago wherein I > suggested that all important message traffic should be mediated -- but it > should not be mediated by an ESB. It should be mediated by XML gateways > and/or SOA management agents. A mediation system should do ALL of the > following > > > virtualization of endpoints (enabling dynamic location, binding, routing, > versioning, etc) > > transformations > > security mediation and enforcement of security policies > monitoring, management, and control > An ESB can only handle the first two. XML gateways and SOA management > agents can do all four. My preference for a mediation system is an XML > gateway because it offers the added value of hardware acceleration. > Although I recommend XML gateways as a basic component only when exposing > services outside the firewall, that's only when discussing the initial > configuration. When first getting started, I think SOA management is a more > important infrastructure component, because you need the monitoring and > visibility features that only a SOA management system offers. But as the SOA > initiative progresses, I recommend using an XML gateway for mediation > between services inside the firewall. (You'll still need SOA management to > implement endpoint-based policy enforcement points, but XML gateways make > better mediators.) > > Regarding this point: > > > The main drawback I see to using an ESB is that you're building your > enterprise around proprietary software. Even the open source ESBs all > have their own unique ways of configuring and managing services. The net > effect is that you're locked into a particular service bus and will find > it increasingly difficult to break free over time. > The same can be said about all SOA infrastructure products. Lock-in is a > fact of life. As soon as you implement anything, you're locking yourself > into a product. I think it's better to lock yourself into a single product > for configuration and management than to deal with dozens of different tools > and procedures for configuration and management. That's the primary reason > that I recommend using a SOA management system to implement endpoint policy > enforcement points rather than using the inherent capabilities of a service > platform. Centralized management and control is a good thing. The one caveat > is that many ESBs are built on a proprietary MOM protocol, and you > definitely need to be cautious about using proprietary protocols. Not only > do they lock in the product for that specific service, they also force > symmetric deployment of the proprietary protocol. Try to avoid using them. > > Anne > > > On 6/27/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi all, > > > > I'd like to find out how list members view the use of ESBs in SOA. Based > > on what I've read and discussions I've had off list, I suspect a fair > > number of people view an ESB as an essential component of a SOA. > > > > In my own talks on the topic I tell people that ESBs are especially good > > for bridging legacy applications to a SOA. Beyond this, they can > > certainly add a lot of value in the monitoring and control area. > > However, I think there's been way too much marketing hype from the > > vendors that conflates ESBs with SOA. Especially now that WS-Addressing, > > WS-ReliableMessaging, and WS-AtomicTransactions are becoming standard > > components of the SOAP stacks (and WS-Eventing is getting closer), the > > value added to Web services by an ESB seems to me to be minimal for all > > but the largest enterprises. > > > > The main drawback I see to using an ESB is that you're building your > > enterprise around proprietary software. Even the open source ESBs all > > have their own unique ways of configuring and managing services. The net > > effect is that you're locked into a particular service bus and will find > > it increasingly difficult to break free over time. > > > > How do other people feel about this? > > > > - Dennis > > > > -- > > Dennis M. Sosnoski > > SOA, Web Services, and XML > > Training and Consulting > > http://www.sosnoski.com - http://www.sosnoski.co.nz > > Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 > > > > > > > > > > > ________________________________ Do you Yahoo!? > Yahoo! Music: Check out the gig guide for live music in your area > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
