Anne, Firstly, to be clear, even though I speak for myself and not BEA in this discussion, I am interested in promoting our view of the ESB space. I'm a consultant, not in product management, so I can't speak to our future plans. On the other hand, I can speak to how I see customers adopting the products.
Secondly, comments inline. --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > I should have said that most ESBs don't encourage > good SOA behavior. Not all > ESBs are created equal. But for the most part, this > product category focuses > on servicing tactical integration needs rather than > enabling good design of > reusable services. Fair enough, I agree with this, and am disappointed by it, as it will only detract from offerings that do enable good practices. > It would seem pretty obvious that ESBs are more > popular than XML gateways > (just compare the number of vendors in each > category), but don't take that > as proof that ESBs are a better solution. I don't look at it this way -- i would suggest perhaps that most don't see or even agree with the distinction of features that you listed in a prior email, or that an XML gateway offers more functionality than an ESB. This is frankly the first time I've heard a suggestion than an XML gateway, as a product category, offers more and better functionality! For example, one of my larger clients refers to their hardware-based XML gateway as their "enterprise broker". The major reason they opted for this approach was price/performance compared to the available software of the era (2004 timeframe) running on their chosen infrastructure provider. In terms of flexibility and quick-reaction to evolving new interfaces, the gateway isn't great, and they're now looking to complement their XML gateway with ALSB as a neighbourhood proxy to get more flexibility and quick-reaction times for their delivery teams. So here is a case where an XML gateway is deemed more performant but less flexible than an ESB. My overall point is that it is futile to compare product categories in this way, given the market's immaturity and lack of consistent terminology, but I suppose we will have to leave it at that. > I'm not aware of any ESB that performs security > mediation. (vendors -- > correct me if I'm wrong.) BEA's AquaLogic Enterprise > Security product does > -- but not ALSB. This really isn't the case. ALSB most certainly does do many cases of security mediation (though not as many as in conjunction with ALES). It can have TLS inbound and WS-Security outbound, or vice-versa, I can also actively translate a WS-Security authentication request (username/password, x509, or SAML token) into a new SAML assertion downstream. It can even take in a SAML-based input and then use a pre-defined service account for a downstream service. In the 2.5 release due in a couple of weeks, there are even more fine grained capabilities here for identity mapping to downstream services that don't support SAML (and not requiring ALES). > rudimentary monitoring and > management of services managed by ALSB. But that > isn't sufficient in a > heterogeneous environment. I have clients with very heterogenous environments (CICS, WebSphere MQ, Tuxedo, FTP batches, HTTP-REST and HTTP-SOAP etc.) that are starting to use ALSB to manage, monitor, send alerts, and route/transform between their services.... I don't see how it's not sufficient. > (Otherwise, why would BEA establish partnerships > with AmberPoint and SOA Software.) Obviously a product can't be all things to all people.... but in my opinion the main reason for these partnerships is that ALSB isn't a agent-based WSM solution, which might be more appropriate in some contexts. > The management and security capabilities supplied by > XML gateways and SOA > management products are far superior to those > supplied by an ESB. I disagree on this, it doesn't fit with my experience in the field when working with our products and talking to our customers and prospects. There certainly are many that are interested in WSM solutions, but it's usually as a complement, not a superior replacement. > all these capabilities. And this infrastructure > should not be hosted on a > single instance of an app server (my primary > objection to ALSB). Granted, federated management is an issue with the ESB model, though we're working on that. > I stand by my recommendations. I just wanted to clarify whether I understood your position correctly, and to note that not all ESBs are created equal. Cheers Stu __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/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/
