I think, Anne, we are in sync now. Thanks for the comments. - Michael
----- Original Message ---- From: Anne Thomas Manes <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, June 30, 2008 2:16:51 PM Subject: Re: [service-orientated-architecture] [ZapFlash] Avoid Getting Lost on the (Enterprise Service) Bus Michael, We are in agreement regarding the importance of an ESB in a SOA infrastructure (i.e., not mandatory). We're quibbling about how to position it in order to get our point across. Note that I said "one of many platforms". And I refer to an ESB as a "service platform", not as a "SOA platform", but perhaps that subtly is lost. I fervently do NOT recommend adopting the mindset that you must select *one* ESB, and it will henceforth become the platform that everyone must use to implement and deploy services. Your story of shifting everyone from WebSphere to BizTalk is exactly the kind of thing I'm trying to prevent. My position is that most organizations should use multiple ESBs, just as today they use multiple application platforms. But your point is well-taken. I position an ESB as a service platform to try to convince people that it is a less significant infrastructure component than if it were the bus in the middle. All the vendor architecture diagrams show the ESB as the universal integration system that forms the foundation of the SOA infrastructure. They imply that all messages have to pass through the bus. And this idea resonates with a lot of people. They are under the misconception that you have to have a universal translator in the middle that enables everything to communicate. And I'm trying to break that mindset. An ESB is an edge component--not integral to the infrastructure. It's useful, but not mandatory. I fear that if you position it as *the* service mediator, people will believe the vendors and route all messages through the ESB. My point is that ESBs don't make very good mediators. In most circumstances, an XML gateway or SOA management system is a better choice for mediation. The key take-away, though, is that ESBs are not the foundation of a SOA infrastructure. They are good for some things: - service enabling capabilities trapped in a legacy system (platform) - hosting new services (platform) - composing or orchestrating lower-level services (platform) - routing, validation, transformation (mediation) I recommend using ESBs to perform mediation at the endpoint rather than somewhere in the middle--again stressing that the ESB lives on the edge -- not in the middle. Anne On Sun, Jun 29, 2008 at 2:17 PM, Michael Poulin <[EMAIL PROTECTED] com> wrote: > To Anne. > Here are two statements you made which I disagree with: > > 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. > >>My recommendation is to think of an ESB as ... one of many platforms that >> will host services within a SOA environment. > > I worked for the company which capitalized on Java platform. Somebody bought > MS BuzTalk as an integration engine and another somebody found that it was > quite similar to the ESB in its set of functionality. So, the BizTalk was > recommended as an ESB and developers started to deploy all their services on > the BizTalk - exactly as you, Anne, recommend. We had a lot of WebSphere > App. Servers where services were developed and tested but then developers > had to be re-trained to deal with BizTalk. I believe it was silly. [I do not > think that BizTalk 6.x is worth than any other ESB product, the problem is > not in Java vs. C++. The problem is that an environment dictates workers > what and how to do, i.e. it puts SOA up-side-down] > > ESB is not a mandatory element of SOA environment. It may be convenient for > some tasks but not necessary for all tasks. I mentioned in this forum a few > days ago what the problems ESB causes for SOA services developed in > accordance to the SOA RM and future SOA RA (it is not a standard yet, but it > will be eventually). > > Bliend ad-hock invocation of interfaces (so much promoted feature of an ESB) > like Web Services or resources like in REST is acceptable only when the > consumer absolutely confident in the provider and nature of the service. > This is possible only if the consumer and the provider are controlled by the > same 3rd party or by one of themselves. This is programmers approach or BU > Owner approach who does not want to hear about an administrative > cross-boundary use of the services. Today, this situation exists in many > enterprises not because of business or technology rational but due to used > accountability and ownership models. > > It is not the future of business-IT integral SOA Business Services. Service > has much more than just interface(s) . This is why SOA RM does not equal SOA > service to Web or REST Services, they are not the same things. > > I see the role of ESB as only a Mediator in the SOA environment. Its > transformation feature may be easily replaced by a transformation service > used by everybody. Thus, ESB is the platform for aggregated services and/or > services implementing some processes. Other services do not need ESB at all. > > - Michael > > > > > ----- Original Message ---- > From: Anne Thomas Manes <[EMAIL PROTECTED] com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Sunday, June 29, 2008 2:41:23 PM > Subject: Re: [service-orientated -architecture] [ZapFlash] Avoid Getting Lost > on the (Enterprise Service) Bus > > 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 > <gervas.douglas@ gmail.com> 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 >> ____________ _________ _________ __ > >
