Following discussion and answering ROB... >IMO, a service consumer will never have a contract with an ESB, as an >ESB, directly. An ESB is a technical platform which either hosts >services (in which case the contract is with the service, not the >ESB) or (more likely) hosts interfaces to services. Agree. This only means that, for the consumer, an ESB is not a service of its own.
>In a service interface role, the ESB is the conduit between service >consumer and provider. The consumer, logically invoking an operation >of the service, invokes the proper WS, posts the XML over HTTP, >publishes the right message, etc. that is facilitated by the ESB. The >ESB in turn interacts with the service in a manner defined by the >service (perhaps via another service interface). The ESB involvement >doesn't usurp the service contract--it supports it. I can agree with this only if all/any issues related to the ESB would be reflected in the Service Definition and, accordingly, in the Service Contract. >In a service facade role (or adaptive role), things look eerily >familiar to the service interface role. The consumer still does what >it does. Not exactly; only if appears as a n interface while it may appear as a service. Then, we have a problem >A service provider exposes an interface via the ESB. Consumers are >expected to interact with that interface, using particular syntax and >semantics. Some consumers will need help doing this. Oups! If a consumer has decided it wants to use the service (the ESB is hidden) but cannot do this because it cannot support “particular syntax and semantics”, then guess what the consumer would do? Will it send a request message knowing that the service interface (the ESB is hidden) cannot understand it? I do not think so. In the best case, the consumer may engage an additional service for translation work. It is hard to imagine a situation where a declaration in the Service Descriptor would say something like : I (the service) accept whatever message from any unknown consumer; I can understand/translate it into my language (semantic), do not worry! The problem here is that we are trying to squeeze an infrastructural ESB into Business Domain oriented service (when it was just a Web Service interface, there were no much difference between ‘business’ and infrastructure) >In an adaptive role, the ESB serves as an agent for the consumer, >transforming what the consumer understands into something the >provider understands. It can then interact with the provider on the >consumer's behalf. This notion of ‘an agent for the consumer’ is left from the Web Services time… I see only one reasonable use-case for this feature: the ESB hosts a process ( e.g. in BPEL) exposed as a service; the consumer contracts with this service/process directly; in the process, the ESB invokes other services and does whatever data transformation/semantic translation as needed. There is no any coupling between the consumer and engaged service. >But the useful applicability of fire and forget interactions is >relatively rare, IME. The vast majority of processes, integrations, >etc. care very much that "the other side got it and processed it." The human expectations of the integrator are not imbedded into the used technicalogy like MOM. This why it breaks. >If a consumer invokes, via an ESB, a service to make an airline >reservation, then by golly something better do that. There is a >dependence by the consumer that something somewhere performs the >action. It is dependent, therefore it is coupled. You describe an intent to reach a RWE - this has nothing to do with coupling. One Big guy even assumed that just sending a request message is EQUAL to gaining RWE (so much he believed in “coupling” of intention and actual delivery), which is absurd. >If the publisher stops publishing, what becomes of the subscribers? >Left in the cold. They need *something* somewhere to publish the >message. Thus, they are coupled to a producer. They don't know who it >is, where it is, just *that* it is. I am afraid, you are mixing business task with technology implementing it. Technology’s feature (not an option) totally isolates sender from the receiver. From business perspective it does not make sense because a consumer acts only if it is interested in a RWE. This does not mean that technical sender “assumes” technical receiver, I believe. - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, June 24, 2008 6:28:31 PM Subject: [service-orientated-architecture] ESB/Intermediary in SOA (was Data services (was Re: Definition of SOA)) --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > Rob, it is obvious ( based on the last part of the message below ) > that we are on the same plate. > > However, a few details are still in my interest to be cleared. > > Following "... Which in itself is then a service. So the consumer > is now interacting with service Y, which happens to be implemented > in an ESB, rather than with service Z" - may lead to the confusion > if the consumer X has a Contract with Z. If Y service shields Z > service from the X consumer, the Contract has to be between X and > Y, right? Exactly. > If ESB acts as a business service interface (vs. infrastructure > ESB), the provider must include ESB into the Service > Description and, respectively, into the Service Contracts. We > agreed on this. Yes. The ESB is an interface mechanism for the service. > Now, if ESB acts as a service of its own, the consumer has to > contract with ESB. It would be no problem here unless ESB magically > represents service's functionality and RWE, and does it for every > service version. Have you heard about such ESBs? Is it realistic to > assume such creature at all? (For every service...?) One of the challenges is in the breadth of functionality that an ESB can provide. An ESB can fill many roles, which can make discussions confusing when one side of the discussion is assuming one role and the other side is assuming another role. IMO, a service consumer will never have a contract with an ESB, as an ESB, directly. An ESB is a technical platform which either hosts services (in which case the contract is with the service, not the ESB) or (more likely) hosts interfaces to services. In a service interface role, the ESB is the conduit between service consumer and provider. The consumer, logically invoking an operation of the service, invokes the proper WS, posts the XML over HTTP, publishes the right message, etc. that is facilitated by the ESB. The ESB in turn interacts with the service in a manner defined by the service (perhaps via another service interface). The ESB involvement doesn't usurp the service contract--it supports it. In a service facade role (or adaptive role), things look eerily familiar to the service interface role. The consumer still does what it does. The interaction between the ESB and the "service" may be more traditional- -e.g. write to DB interface tables. Or the interaction might be via low-level API exposed by the application/ component. The net effect is the same as the service interface role, though. The above two roles front the service provider. An ESB can also "front" a service consumer. A service provider exposes an interface via the ESB. Consumers are expected to interact with that interface, using particular syntax and semantics. Some consumers will need help doing this. In an adaptive role, the ESB serves as an agent for the consumer, transforming what the consumer understands into something the provider understands. It can then interact with the provider on the consumer's behalf. An ESB can host a service, where someone implements the service completely within the ESB framework. This service will expose an interface (implementation separate from interface) most naturally via the ESB. So the ESB hosts both the interface and service host. (the list of roles above is undoubtedly not exhaustive) I think it is important to note that in none of these roles is the ESB an independent actor in terms of "ESB as a service." The ESB is instead an agent for the consumer or the provider, supporting, not replacing or altering, the service contract. When the ESB hosts a service, it is the service that is important and specifies the contract and interface, not the ESB. This gist of the consumer and provider interaction is not changed by the technical plumbing that is facilitating the interaction. The business level consumer doesn't have a contract with the ESB just because that is the communication channel to the provider. The contract is still with the provider. > BTW, an intermediary can transform message in any way it wants w/o > sender and receiver knowing about it - full decoupling. It depends on how you view the transformation components hosted on the ESB. If you agree with the descriptions of the above roles, the components hosted on the ESB are merely extensions of the consumer or the provider. Thus, the ESB-hosted component that translates the original message to an intermediate format is a part of the consumer. The ESB-hosted component that translates the intermediate format to the provider format is a part of the provider. Consumer and provider are coupled on the intermediate format. Such a view isn't without precedent. A few clients have found that the adaptive, ESB-hosted components should be written and maintained by the end point development teams. The "integration team" isn't responsible for the code that translates to/from the intermediate format. The end point development teams (consumers and providers) are. This helps make the relationship between service consumer and service provider more clear > Honestly , I do not understand what did you mean by "They are > coupled in what the provider agreed what it will do upon receipt of > the message." If provider promises to broadcast the message to > anybody who would be interested, at which level the sender is > coupled with that anybody? Fire and forget is valid interaction. "I don't care who, if anyone, is listening." But the useful applicability of fire and forget interactions is relatively rare, IME. The vast majority of processes, integrations, etc. care very much that "the other side got it and processed it." If a consumer invokes, via an ESB, a service to make an airline reservation, then by golly something better do that. There is a dependence by the consumer that something somewhere performs the action. It is dependent, therefore it is coupled. > At the level of common interest? If so, if the interest disappears, > they become decoupled? :-) Correct. If the publisher stops publishing, what becomes of the subscribers? Left in the cold. They need *something* somewhere to publish the message. Thus, they are coupled to a producer. They don't know who it is, where it is, just *that* it is. -Rob
