Steve, >From an architectural perspective, we are in complete agreement. It comes down to the term "ESB". For me, "ESB" means a product marketed under that moniker, such as Mule or WebSphere ESB. And I vehemently argue that the products marketed as "ESB" do not provide the "bus" capabilities that you describe below. I refer to the stuff you refer to a "bus" capabilities as a "managed communications infrastructure" (MCI). I refuse to call it "ESB" because people will then assume I am talking about ESB products. An MCI typically comprises SOA management, registry/repository, and/or XML gateway products.
See my last response to Michael for more on "managed endpoints". Anne On Mon, Jun 30, 2008 at 1:11 PM, Steve Jones <[EMAIL PROTECTED]> wrote: > 2008/6/30 Anne Thomas Manes <[EMAIL PROTECTED]>: > >> Steve, >> >> Why do you feel you need a bus at all? > > If you take Bus as being the infostructure[sic] that enables consumers > and producers to connect then I think that you do need some form of > technology to smooth this out and particularly help with the > enforcement of policies. NB I'm assuming that the bus is > > a) federated > b) not necessarily marketed as an ESB > c) might not even use ANY technology but be enforced by governance > >> >> One of the biggest challenges we have in this discussion is that "ESB" >> is undefined. Some ESBs, like ServiceMix and Mule, are clearly focused >> only on mediation. Other ESBs, particularly the ones based on SCA, >> play a new and improved role as a service container. > > This is the bit I don't agree with, I don't see that as an improvement > to a bus architecture but just another SDP which means fundamentally > they are the same as any other application server and not a bus. > >> SCA-based ESBs >> provide service containers that enable a service to natively speak >> multiple protocols. Every service has a BabelFish in its ear. Hende >> you don't need some big hub in the center to enable disparate systems >> to communicate. > > I don't think you need a big hub, I think federation is the norm but I > don't think that the SCA based ESBs are a great ESB in that it plays > to the "tick box" approach of vendor competition rather than being a > practically appropriate approach. Why allow multiple protocols and > approaches? Why not standardised down to a limited set? Why allow > something in the middle to switch an async call into a sync one thus > meaning that consumers write poor code which has a heavy block in it > rather than event based approaches which would be more effective and > better reflect the service they are consuming. > >> >> That's the beauty of positioning an ESB as a service platform. If your >> services can communicate using any protocol, then you don't need a >> bus. > > This implies that the protocol is important. I'd argue that it isn't. > Its the message and security elements (the syntax and semantics) > which are important and ESB service platforms don't help there. Also > putting hosting and development together with mediation means that > they have to change together rather than enabling greater degrees of > independent change. > >> >> You don't *need* an ESB to build and deploy services. All application >> platforms now include frameworks for building and deploying services. >> But those frameworks are middleware-specific. A better approach is to >> use a framework/container that is middleware-agnostic. One that >> enables the service to communicate through multiple protocols. That's >> the new role of an ESB. > > Which means its no longer a bus, its an SDP. From bitter experience > if you don't have a separation of the mediation parts from the > business logic parts then they become intertwined and the rate of > change slows to a crawl with the SDP becoming the next generation of > integration problems. > > I've seen people try and use ESBs as SDPs and the end result is that > they are just another application silo and the tight binding that goes > on between platforms can in some cases be _worse_ due to the > "simplicity" of remote service consumption. > > Steve > >> >> Anne >> >> On Mon, Jun 30, 2008 at 5:19 AM, Steve Jones <[EMAIL PROTECTED]> >> wrote: >>> I'm going with Michael and Jason on this one. An ESB needs to be a >>> _bus_ not a service development platform. As soon as an ESB becomes a >>> SDP it ceases to be a bus and becomes just another application >>> platform that you have to integrate with and which has application >>> platform release schedules and complexities. >>> >>> Keep the bus simple, keep it for mediation and don't put business >>> logic into the bus. This was a rule that I started back in the EAI >>> days where I'd see the EAI solution have business logic in it that >>> should have been put into the various end points but wasn't due to >>> "time" constraints, which normally meant they hit deadline 1 but >>> missed 2-10 and then canned the programme. >>> >>> I think the issue here though is the "what is an ESB". With the BSB >>> spec I tried to define what I meant by a business level service bus >>> and it has many of the elements that you talk about Anne from a >>> governance perspective. So maybe the challenge here isn't whether an >>> ESB should be an SDP but the following >>> >>> 1) What are you SDPs >>> 2) Keep the links between them simple and limited >>> >>> So some of the "richer" (i.e. basically non-standards based app >>> server) ESBs fit into category 1 and some of the more "limited" (i.e. >>> actually more powerful) ones fit into category 2. >>> >>> For me the purpose of a Bus is to enable producers and consumers to >>> link, this means supporting the basic communication approaches >>> (pub/sub included) and mediating between the different models >>> (security and data). From an RM perspective I don't think it causes an >>> issue as its effectively just part of the execution context (as long >>> as you don't put any business logic and hence RWE into it). >>> >>> Keep the Bus (what ever you call it) stupid, because that stupidity >>> gives you the ability to change the rest much more simply. >>> >>> Steve >>> >>> 2008/6/29 Anne Thomas Manes <[EMAIL PROTECTED]>: >>> >>>> Haven't we seen this flash before on this list? >>>> >>>> While I agree with Jason's overall perspective (i.e., don't let >>>> technology drive your architecture and recognize that too much >>>> reliance on an ESB can be harmful to your initiative), I disagree with >>>> his recommendation to view an ESB primarily as a service intermediary. >>>> An ESB is first an foremost a service platform -- one that includes >>>> built-in transformation capabilities. >>>> >>>> As Jason says, >>>> >>>> "you need security, governance, quality, and management, in addition >>>> to the transformation and content-based routing capabilities of Service >>>> intermediaries, in order to build an effective SOA infrastructure." >>>> >>>> My overarching recommendation for service intermediaries is to keep >>>> the number of intermediaries in the path to a minimum. Security, >>>> governance, and management are required features in a SOA runtime >>>> environment. These capabilities are supplied via SOA management or XML >>>> gateways -- not by ESBs. And, oh by the way, SOA management and XML >>>> gateway solutions can also support transformations and content-based >>>> routing. Hence SOA management and XML gateways offer more >>>> comprehensive intermediary solutions than ESBs -- at least for typical >>>> intermediary requirements. >>>> >>>> In some circumstances, you may need more advanced routing and/or >>>> transformation capabilities. i.e., you may need to support a pub/sub >>>> model, reliable message delivery, or transformations based on a >>>> database query or external algorithm. I view these scenarios as >>>> "integration" rather than service-enablement, and as Jason indicated, >>>> ESBs are good at integration. In these circumstances, it's appropriate >>>> to use an ESB in the middle. >>>> >>>> But for more typical mediations (e.g., message validation, >>>> transformations using XSLT, and simple routing) the management >>>> infrastructure can handle it. Or--do the mediation at the endpoint. An >>>> ESB is a useful component in a SOA infrastructure. It provides a >>>> platform that enables a service to natively speak multiple protocols, >>>> and it can transform messages to and from standard formats. >>>> >>>> My recommendation is to think of an ESB as an edge component -- not as >>>> something that sits in the middle enabling universal communication. It >>>> is one of many platforms that will host services within a SOA >>>> environment. >>>> >>>> Anne >>>> >>>> On Sun, Jun 29, 2008 at 7:23 AM, Gervas Douglas >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> Avoid Getting Lost on the (Enterprise Service) Bus >>>>> >>>>> Document ID: ZAPFLASH-2008530 | Document Type: ZapFlash >>>>> By: Jason Bloomberg >>>>> Posted: May. 30, 2008 >>>>> >>>>> So, you've been following ZapThink long enough to know that beginning a >>>>> Service-Oriented Architecture (SOA) project by purchasing an Enterprise >>>>> Service Bus (ESB) is starting at the wrong end of the initiative. >>>>> Purchasing >>>>> any technology, especially an ESB, at the beginning of an architecture >>>>> project is a recipe for failure, you've been telling anyone who'll >>>>> listen. >>>>> But for whatever reason, your organization didn't pay attention to you, >>>>> and >>>>> now they've dropped a bundle on an ESB. Maybe your boss golfs with the >>>>> vendor sales rep, or maybe the powers-that-be are listening to the >>>>> wrong >>>>> analyst firm, who knows. But in any case, you're stuck with that >>>>> decision, >>>>> and you're now expected to implement SOA with it. >>>>> >>>>> Fortunately, while purchasing an ESB too early in a SOA project does >>>>> substantially increase your risk of failure, all is not lost. After >>>>> all, >>>>> you're not alone; this mistake is one of the most prevalent SOA snafus >>>>> in >>>>> IT >>>>> shops around the world today, and not all of those projects end up as >>>>> failures. Many of today's ESBs are now mature products, and can be an >>>>> important part of a fully functional SOA implementation. Understanding >>>>> the >>>>> risks that buying an ESB too early in a SOA initiative presents, and >>>>> dealing >>>>> with those risks proactively, can turn a bad situation around and get >>>>> your >>>>> SOA initiative back on the right track. >>>>> >>>>> Understanding the Risks >>>>> Fundamentally, the problem with buying the ESB first is that you might >>>>> fall >>>>> into the trap of doing things the way the ESB would like you to do >>>>> them, >>>>> in >>>>> light of the fact that many ESBs are in many ways traditional >>>>> middleware >>>>> under the covers. After all, if middleware solved all your problems, >>>>> then >>>>> you wouldn't be considering SOA in the first place -- and adding >>>>> Service >>>>> capabilities to your middleware doesn't change this fundamental fact. >>>>> >>>>> In fact, the pitfalls that the ESB-first approach introduce fall into >>>>> three >>>>> broad categories: >>>>> >>>>> Taking an overly integration-centric perspective of the project -- Most >>>>> ESBs >>>>> are generally really good at connecting things -- in other words, most >>>>> ESBs >>>>> are quite capable integration middleware solutions. The problem is, SOA >>>>> isn't about connecting things, it's about building loosely-coupled >>>>> Services >>>>> the business can leverage to meet changing process needs. We want to >>>>> get >>>>> away from the "connecting things" approach to distributed computing, >>>>> and >>>>> instead move to a "composing Services" paradigm, where integration >>>>> becomes >>>>> a >>>>> byproduct of composition. >>>>> >>>>> The "middleware for your middleware" problem -- if it were practical >>>>> (or >>>>> even possible) to take a single piece of middleware and put it all by >>>>> itself >>>>> in the middle of your IT infrastructure, that would be one thing, but >>>>> for >>>>> most large (and many midsize) organizations, the vision of relying upon >>>>> one >>>>> piece of middleware to solve all integration problems is an unrealistic >>>>> fantasy. In reality, organizations tend to have several different >>>>> pieces >>>>> of >>>>> middleware, of different vintages and for different purposes. >>>>> Introducing >>>>> one or more ESBs into the mix means that now you have to integrate your >>>>> ESBs >>>>> with existing middleware as well as with each other, leading to the >>>>> requirement of middleware for your middleware. Where will it ever end? >>>>> >>>>> The "good money after bad" fallacy -- The "good money after bad" >>>>> fallacy >>>>> is >>>>> actually much broader than IT. People would rather throw money at an >>>>> approach that's already cost a bundle than to switch approaches to a >>>>> less >>>>> expensive, but more effective alternative. If you've been buying >>>>> middleware >>>>> from a vendor for years, and now they tell you that you need an ESB, >>>>> you're >>>>> likely to take that advice, even if an alternative is lower cost and >>>>> lower >>>>> risk, simply because you've already spent so much with that vendor. >>>>> >>>>> ESB-First SOA Best Practices >>>>> Now that you've steered your bus past the pitfalls, let's see if we can >>>>> point it in the right direction moving forward. The most important >>>>> thing >>>>> to >>>>> remember is that your architecture should drive the technology, not the >>>>> other way around. Remember that ESBs, like any mature solution, come >>>>> with >>>>> a >>>>> boatload of features -- many of which may not be appropriate for your >>>>> situation. It is often figuring out which features not to use rather >>>>> than >>>>> the capabilities you should actually use that is the key to being >>>>> successful >>>>> with a product like an ESB. >>>>> >>>>> In particular, it is essential to take a process-driven approach to >>>>> your >>>>> infrastructure, instead of an integration-centric approach. Remember >>>>> that >>>>> building Service compositions that implement processes typically >>>>> compose >>>>> capabilities across multiple execution environments. Furthermore, those >>>>> compositions are both dynamic and unpredictable -- the business process >>>>> specialist in charge of the compositions may change them around long >>>>> after >>>>> you've deployed the Services. Governance becomes the key to managing >>>>> that >>>>> unpredictability, rather than pre-defined integrations. >>>>> >>>>> As a result, you shouldn't rely upon any one execution environment for >>>>> your >>>>> Service implementations, or any one process management environment >>>>> either, >>>>> for that matter. ESBs can offer an effective, managed execution >>>>> environment >>>>> for some of your Service interfaces, but you rarely if ever want to >>>>> rely >>>>> upon any one runtime environment for all of your Services. In other >>>>> words, >>>>> you should balance the advantages of running your Services "on the bus" >>>>> with >>>>> the fact that SOA allows you to leverage heterogeneity both on and off >>>>> the >>>>> bus. >>>>> >>>>> One essential point here is that SOA leverages interoperability more so >>>>> than >>>>> portability. In a virtual machine-based "write once, run anywhere" >>>>> environment, whether Java or Microsoft Common Language Runtime >>>>> (CLR)-based, >>>>> distributed computing relies upon the portability of code. SOA, >>>>> however, >>>>> leverages the interoperability of the Service interfaces so that you >>>>> don't >>>>> need to move the underlying Service implementations around. As a >>>>> result, >>>>> running all your Services on the ESB can actually impede your SOA >>>>> implementation, rather than support it. >>>>> >>>>> So, if you shouldn't think of your ESB as either integration middleware >>>>> or >>>>> as a universal Service execution environment, then what role should >>>>> your >>>>> ESB >>>>> play? The answer is a Service intermediary. Transformations and >>>>> content-based routing are the essential capabilities a Service >>>>> intermediary >>>>> should deliver, in conjunction with robust security and management. >>>>> Building >>>>> the Business Service abstraction depends upon transformations and >>>>> content-based routing, and fortunately, most ESBs offer these >>>>> capabilities. >>>>> So, only use the traditional messaging middleware capabilities of your >>>>> ESB >>>>> if you really need them, and only leverage the Service runtime your ESB >>>>> provides when convenient, but configure your ESB as an intermediary to >>>>> get >>>>> full value out of it as part of your SOA infrastructure. >>>>> >>>>> Not only does using an ESB as an intermediary enable you to architect >>>>> the >>>>> Business Service abstraction, it also resolves the "middleware for your >>>>> middleware" problem, because intermediaries can intermediate between >>>>> disparate integration technologies just as well as they can >>>>> intermediate >>>>> between Service providers and consumers. If you feel you need to use >>>>> your >>>>> ESB's message queuing technology, for example, just because it's there, >>>>> however, then you won't get this benefit. >>>>> >>>>> The ZapThink Take >>>>> Yes, you need security, governance, quality, and management, in >>>>> addition >>>>> to >>>>> the transformation and content-based routing capabilities of Service >>>>> intermediaries, in order to build an effective SOA infrastructure. But >>>>> remember, ESBs aren't the be-all and end-all of SOA infrastructure -- >>>>> many >>>>> ESBs on the market include most of the above capabilities, but rarely >>>>> if >>>>> ever offer everything an organization requires. In fact, XML appliances >>>>> are >>>>> likely a better approach to security and policy enforcement, a >>>>> registry/repository combined with a full-lifecycle SOA quality solution >>>>> might serve as your design time and run time governance tools, while a >>>>> robust SOA management solution might be a critical part of your >>>>> infrastructure as well. In fact, many organizations leverage such >>>>> products >>>>> in conjunction with existing middleware to build out their SOA >>>>> infrastructure without having to buy an ESB at all. >>>>> >>>>> The bottom line is to always remember that the business drives the >>>>> architecture, and the architecture drives the technology. Don't let the >>>>> technology drive the architecture! SOA is particularly adept at >>>>> abstracting >>>>> existing technology, which can include recently purchased products in >>>>> addition to your legacy environment. But knowing which of your existing >>>>> capabilities to leverage -- and which to forego -- can make or break >>>>> your >>>>> SOA initiative. >>>>> >>>>> >>>>> Messages in this topic (1) Reply (via web post) | Start a new topic >>>>> Messages | Members >>>>> MARKETPLACE >>>>> ________________________________ >>>> >>> >> >
