Ron, who we have to beware, wrote: <<A trivially simple definition of ESB as a pattern could be a mechanism for enabling Service-to-Service communication and composition. Yeah, that's simple. Too simple? Who knows, but I think it works.
A trivially simple definition of ESB as a platform could be a stack of infrastructure technologies that enable Service exposure, consumption, composition, and value-added messaging. Yeah, that's simple too, but seems to fit.>> Interesting to elaborate on the pattern version, "enabling Service-to-Service communication" is not a pattern definition/description. It can come not that simple after all. When we used Web Services 'as services', i.e. we operated with interfaces instead of service entities, and when anything what consumers needed to know (we thought) were in the interfaces only, features of ESB like Service exposure, consumption, composition, and value-added messaging were just fine. When we've added (wrongly or not) more business value (meaning) to the service and stated that service interaction is the result of consumer's interest in business functionality (in general, any functionality may be viewed as a business one for certain business) and RWE, we needed to add a notion of Service Contract. That is, consumer, as assumed, knows about the service up-front and, moreover, decides whether the service capabilities meet consumer's needs before engaging the service. In this new situation, the way how an ESB enables exposure, consumption, composition, and value-added messaging gets challenged. In particular: 1) to exposure: since consumer finds the service/service description up-front, should it be via ESB or via Service Registry/Repository (which is not claimed as a part of ESB to my knowledge)? 2) to consumption: when service is recognized as suitable for the task, there has to be a agreement/handshake between consumer and service provider; we have not heard about such feature of an ESB, do we? 3) to composition: today we do not have a technology or solution capable of defining a business process in meta-data terms followed by physical discovery of appropriate entity for fulfilling the Action execution; we usually define the process together with process action performers up-front. Then we can deploy such defined process on an execution platform. That is, it looks like an ESB may be a deployment/execution platform but not a composer 4) value-added messaging: I agree with BEA (sorry, Oracle) in their value-added consisting in dynamic message re-direct; I do not understand how agreed (in the Service Contract) message content may be modified in an ESB except for one case - when Service Description does not reflect real service interface, but this is far from "trivially simple" case. I struggle to find a use-case where an ESB adds a value to the consumer; for the provider, it, probably, does... some value (and it is a question if this value is adequate to the paid money) - Michael ----- Original Message ---- From: rschmelzer <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, July 24, 2008 9:26:11 PM Subject: [service-orientated-architecture] Blah blah, more on ESB... >From one point of view, an ESB is a pattern (as IBM once professed). >From another point of view, an ESB is a product platform (as seems to be the mainstream conception). One's point of view will determine your philosophy on one vs. many ESBs and also the necessity of the ESB. A trivially simple definition of ESB as a pattern could be a mechanism for enabling Service-to-Service communication and composition. Yeah, that's simple. Too simple? Who knows, but I think it works. A trivially simple definition of ESB as a platform could be a stack of infrastructure technologies that enable Service exposure, consumption, composition, and value-added messaging. Yeah, that's simple too, but seems to fit. Does SOA require ESBs? Not any more so than n-tier architectures require application servers. Can you do SOA without an ESB? For sure, but we've already talked this one blue. You can certainly do highly scalable web-apps without application servers, too. Can you do SOA with ESBs? Sure, just as you can do highly scalable web apps with application servers. Who has the answer? Ron of course. Err, I mean, you do. Figure out what works for you, but don't be too dogmatic - realize that there are many ways to skin the SOA cat. And in any case, I already discussed the need to do architecture first, technology selection and implementation last. Don't let the technology drive the architecture, or depression (manic?) might set in. You're the market - you decide what works. Horse: dead and beaten (what's up with all the animal mutilation?) Ron: gone (but not forgotten!)
