+1 on all points. -Rob
--- In [email protected], "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 > >>>> ________________________________ > >>> > >> > > >
