--- In [email protected], 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
