Hi everybody. It's a little bit late but Happy New Years! IF ESB is viewed as just a platform, I agree with you. But technology is always evolving and I think it's very difficult to stop it. :)
I think we will be moving forward to the next generation ESB soon. I'm currently trying to find a way to integrate pattern based application development framework with ESB - kind of like pattern based SOBA environment. Cheers, H.Ozawa Todd Biske wrote: > Agreed. I had a blog entry recently that discussed exactly these two > differences, and that the confusion between the purpose of an ESB (it > is a platform, is it mediation, or is it both) is what continually > causes problems for IT shops trying to make decisions. > > Since your view is that ESB is a platform, then I'm 100% with you that > not everything should go through the ESB. > > -tb > > On Dec 30, 2006, at 7:21 AM, Anne Thomas Manes wrote: > >> I prefer to think of an ESB as a "platform" (hosting services) rather >> than a "mediation system" (managing message traffic and flow). From >> my perspective, the primary role of an ESB is to service-enable >> functionality that is trapped in a legacy system. In many cases it >> isn't economically feasible to refactor functionality in legacy >> systems into shared services, therefore the functionality is likely >> to stay put for some time. In these circumstances, you often need to >> use archane integration techniques ( e.g., adapters, transformation, >> protocol switching, etc) to enable open access to the functionality. >> And that's what ESBs do best. And conceptually, this type of >> capability is "platform" rather than "mediation". The archane >> integration functionality is part of the service implementation -- >> which ought to be hidden from consumers by the service interface. In >> this scenario, only messages destined to and from the legacy >> applications need to flow through the ESB. >> >> Some ESBs also support orchestration, but even in this situation, I >> view the ESB as a "platform" (in this case, a composite service >> platform). You define an orchestration and expose it as a service. >> Some folks use these orchestration system to implement complex >> integration scenarios, pulling information from multiple backend >> systems, using multiple protocols, transforming data, etc. Again, >> we're talking about archane integration functionality, all of which >> is part of the service implementation. The end result of an >> orchestration is a service that other applications consume. ( i.e., >> "platform", not "mediation") >> >> Some folks use ESBs to do dynamic service resolution, routing, load >> balancing, etc, with the occasional message validation and/or >> transformation . This is "mediation", but as I indicated in my first >> response, ESBs are not very efficient as mediators, and most ESBs >> have pretty limited mediation capabilities. In particular, they >> typically don't support operations monitoring and control, and they >> rarely support security mediation (authentication, authorization, >> auditing, credential mapping, federation, etc). >> >> Other mediation systems, such as XML gateways and SOA management >> systems are much better at mediation than ESBs. >> >> Anne >> >> >> On 12/29/06, Todd Biske <[EMAIL PROTECTED]> wrote: >> No arguments from me either. Anil, I think your comment about folks >> that haven't thought through exactly where the ESB fits in the SOA >> infrastructure have probably put a lot more thinking on hold than >> just service analysis and design. :) >> >> >> I also agree with Anne that ESB *can* be a useful component of the >> infrastructure. There's a need for service mediation techniques in >> the infrastructure, and ESB products are one way of providing those >> capabilities. As Anne always indicates, there are other ways of >> providing those capabilities as well, included but not limited to XML >> appliances, WSM gateways, application servers, etc. >> >> -tb >> >> On Dec 29, 2006, at 1:37 PM, Anil John wrote: >> >>> >>> >The key point that I make to my clients is that an ESB should not >>> be viewed as the core of the >>> >services infrastructure, and that not all messages must flow >>> through an ESB. Only those messages >>> >that require the services of the ESB should flow through the ESB. >>> >>> + 1 >>> >>> >Organizations that rely too heavily on ESBs wind up doing >>> integration rather than designing shared, reusable services. >>> Indeed! I've often found that folks who have deployed or are >>> thinking of deploying ESB's *without thinking through exactly where >>> the ESB fits in the SOA Infrastructure* have a tendency to put their >>> service analysis and design thinking on hold. >>> >>> Anne, by all means keep on fighting the good fight! You are not alone. >>> >>> Regards, >>> >>> - Anil >>> >>> >>> From: [EMAIL PROTECTED] com >>> [mailto:[EMAIL PROTECTED] On Behalf >>> Of Anne Thomas Manes >>> Sent: Friday, December 29, 2006 8:20 AM >>> To: [EMAIL PROTECTED] com >>> Subject: Re: [service-orientated-architecture] Bradley on Senior >>> Management & SOA >>> >>> Being one of the "remaining hold-outs who continue to argue strongly >>> that ESBs are irrelevant or transitory". ... >>> >>> (By "ESB" I'm referring to products such as BEA AquaLogic, IBM ESB, >>> and Sonic ESB.) >>> >>> Actually, I don't say ESBs are irrelevant. I view an ESB as a useful >>> component in a services infrastructure. It provides a means to >>> expose legacy application functionality as services, and it supports >>> mediation (although not efficiently) and sometimes orchestration. >>> But it's just one of many components in the infrastructure, along >>> with service platforms, SOA management, XML gateways, >>> registries/reposito ries, and other components. >>> >>> The key point that I make to my clients is that an ESB should not be >>> viewed as the core of the services infrastructure, and that not all >>> messages must flow through an ESB. Only those messages that require >>> the services of the ESB should flow through the ESB. Most clients >>> have a hard time with this concept -- the typical response I get >>> back from them is, "so what -- we go back to point-to-point >>> connections? (!)" At which point I try [again] to explain the >>> difference between SOA and integration. SOA is about refactoring >>> shared capabilities into services that applications consume -- in >>> the same way that applications today consume DBMS services. Do you >>> need a broker to sit between an application and a DBMS? >>> >>> This is actually the biggest issue that I have with ESBs -- they are >>> fundamentally focused on integration rather than service-orientation >>> . Organizations that rely too heavily on ESBs wind up doing >>> integration rather than designing shared, reusable services. >>> >>> I try to make it clear that depending on a single product is harmful >>> to a SOA initiative. Most large organizations already have multiple >>> ESB/EAI technologies deployed, and these systems are not going to go >>> away just because they've deployed a new ESB. >>> >>> Unfortunately (at least from my perspective) I'm only one voice >>> providing advice to these clients. >>> >>> The reason that ESBs take up such a big percentage of current >>> spending is that the vendors tell them that an ESB is a requirement >>> for SOA. And enterprise clients *want* to hear that they can buy one >>> product and get "instant SOA". They don't want to hear me tell them >>> that an ESB is not the universal SOA solution. But most clients that >>> have gotten beyond the early planning and pilot stages have begun to >>> realize that my advice is worth listening to. >>> >>> Anne >>> >>> On 12/29/06, Gervas Douglas < [EMAIL PROTECTED] > wrote: >>> <<A nagging worry among SOA advocates over the last year or so has >>> been that SOA was not being understood or bought into by C-level >>> management. A GCR's survey – sponsored by BEA – shows that this is now >>> changing in the surveyed companies. It should be stressed that this >>> survey was only of large organizations which had taken the first step >>> already and deployed some SOA. >>> >>> The survey states that CIOs and CTOs are now the leading sponsors of >>> SOA programmes. While this clearly demonstrates what most of us >>> engaged in SOA programmes or advising such programmes already know: >>> SOA is progressing along the normal adoption curve from pilot to more >>> systematic deployment and as this happens the sponsorship moves up the >>> management structures. >>> >>> Two nuggets which I found interesting were: >>> >>> • The second biggest cost (after software infrastructure at 40% of >>> total spend) was staff reskilling – at 30% of the total cost. This >>> should not be a surprise – SOA puts significant new strains on IT >>> staff both in terms of technical skills and more importantly >>> governance and collaborative skills. >>> • The largest components of the software spend was on ESBs and >>> security (both at 24% of that 40% of total). This suggests that the >>> ESB has been recognized as a keystone product in a SOA strategy. This >>> may come as a surprise to the remaining hold-outs who continue to >>> argue strongly that ESBs are irrelevant or transitory. >>> >>> Two caveats worth noting: >>> >>> While it is good to see sponsorship at the CIO/CTO level, as a >>> business strategy SOA needs line of business sponsorship as well. If >>> SOA remains only an IT strategy, organizations will risk not gaining >>> the full benefits. >>> >>> And with regard to the uptake of Enterprise Service Bus products, what >>> isn't asked or answered by this survey was what the respondents meant >>> when they said ESB – a subject which I will return to.>> >>> >>> You can read this at: >>> >>> < http://www.ebizq.net/blogs/soaroads/ >>> 2006/11/soa_now_in_the_executive_suite.php > >>> >>> I get the distinct impression that non-IT management attitudes to SOA >>> (and other relevant technological concepts such as BPM, SaaS, mashups >>> etc.) varies very much according to the market being surveyed. I have >>> been reliably informed that CxOs of large enterprises in Nordic >>> countries (Scandinavia plus Finland) are well aware of the concept of >>> SOA. From my experience of that region, this is no geat surprise to >>> me. Spain is another competent early adopter country where they seem >>> to be getting to grips with SOA. I would also expect countries like >>> Australia, NZ and South Africa to be demonstrating competence in this >>> area. From some of the contributions to this Group, it would seem >>> that there is a high level of SOA awareness in Germany and the UK. >>> Does it however extend to non-IT CxOs?? >>> >>> It would be interesting to read your impressions on the subject. >>> >>> Happy 29th December! >>> >>> Gervas >>> >>> >>> >>> __. >>> >> >> >> >> >> > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
