--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > 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.
Right. I think I've been saying that from the start. An interface is part of the service definition and service contract. Typical application of an ESB technology is to provide (or implement) an interface. > >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 I don't understand what you mean here. > >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? Let me rephrase. Some *components* may need help in becoming service consumers. For example, an application may have a new need to call service X. There are many ways in which the application can be made to successfully call service X. One of the options is to use ESB facilities to make the call on behalf of the application. > Will it send a request message knowing that the service interface > (the ESB is hidden) cannot understand it? I do not think so. Right. That's silly. > In the best case, the consumer may engage an additional service for > translation work. IMO, that's not a "service." That's a (potentially shared) technical/implementation component. > 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! I'm not sure how you reached this conclusion based on what I posted. A service defines the message(s) it will accept. The consumers must use those messages. A provider might use an ESB to support one or more messages, with the ESB translating the public message to a private form. IMO, that facility is part of the provider implementation. A consumer might use an ESB to create the message needed to send to a provider, translating from the consumer-private message to the public message. IMO, the facility is part of the consumer implementation. > 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) I'm not trying to do that, I don't think. At the business level, there is no ESB. There is no intermediary. Consumer interacts with provider. Technical implementations will map onto specific technologies, like ESB. But maybe we are mixing levels. IMO, a business level consumer is coupled to a provider in many ways. Use of an ESB at the implementation level doesn't change that coupling. > >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Ā Really? I've seen the notion of agent, adapter, proxy, etc. applied in many contexts. At the implementation level, a component that performs the consumer work on behalf of another component, seems reasonable. Together, those components comprise the service consumer. > 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. Correct. The coupling is between the consumer and the ESB hosted service. I've never argued that the services/components that may comprise a service implementation are coupled to the consumer of the aggregated/composed 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. It isn't a human expectation issue at all. Fire and forget is largely an inappropriate approach for most business services and processes, IMO. The popularity and apparent simplicity of pub/sub has caused it to be used in far more cases than it should have been. > >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. Really? How would you describe the relationship? If the consumer doesn't depend on something to do work, then 1) why does it make any kind of call; 2) why does it exist? Coupling is the degree to which one component relies on another. The consumer relies on the provider. If the provider changes in some ways (or disappears) the consumer may need to change. Clearly, we want to structure things such that some changes on either end do not cause requisite changes on the other end. So if the provider disappears (a change) won't the consumer need to change too? If so, then there was 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. No, I don't think that I am. Ignore ESB facilities for the moment. Forget, temporarily, that pub/sub technologies exist. Envision an event producer and consumer at the top business level. Some how, some way, events flow from producer to consumer. We don't care how, only that they do. Why would a producer create events if noone is listening? Why would a consumer listen for events that will never come? Logically, producers and consumers are coupled, at a minimum, by the events they exchange. Technology implementations do not change that, IMO. -Rob
