> 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.
In this case , ESB becomes a consumer agent or delegate, i.e. consumer still decides whether to use the service. Here is no place for consumer’s difficulties in understanding the service (i.e. the things which would require a data translation by the ESB). I agree with this interpretation. > > 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/implement ation component. Why it is not a service? It is definitely not a business service but it may be an infrastructure service. Please, elaborate on this. >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. Let me put described scenarios into the context of service discovery and following invocation. 1) The consumer finds the service, i.e. Service Description with public service interface(s), communication and execution policies ( execution context policies ), service functionality and promised RWE; 2) the consumer decides the service is good for consumer’s needs and …What? In the aforementioned scenarios, the consumer sends its private message to the announced end-point( which is actually the ESB end-point). The private message is not the one described in the Service Description ! ( The scenarios assume that ESB would magically transform consumer’s message into the provider’s message but consumer does not know about it). Do you still think a consumer would do this? You already classified this as a silly action… My point, you cannot hide message transformation in the ESB unless this transformation is neither for consumer nor for provider. This exact solution is taken by Sun Microsystems for their ESB – “Composite Application”. They transform all private messages from both communication sides into INTERNAL normalised message format for transmission through the Bus. > So if the provider disappears (a change) won't the consumer need to >change too? If so, then there was coupling. I believe that consumer may stay the same. This is why I promoting an idea that robust SOA eco-system with business services has to provide several different ways for the consumers to reach the same RWE. We claim application redundancy and saying that services would help avoid it. OK. How about business continuity? Why even in a small town there are 2 or more barbershops and laundries? Because consumers need more than one! It is not about competition only; if one is closed (disappeared) today, it is possible to use another one. The same is with SOA services. I, as a consumer, do not need to change just to go to another laundry (I hope). Am I coupled with any laundry? I do not think so. > Why would a producer create events if no one 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. This is a philosophical substance. Of cause, in a society we all have ties to others. Does it mean that I, living in London, is coupled with somebody in Canadajust because we both speak English and the Head of both countries is Her Majesty? Does it mean that two programs written in Java are coupled because of Java? I think that the word ‘coupled’ is too strong for those cases. At any particular moments in the market, there are a lot of producers with no consumers as well as potential consumers w/o producers. The relationship between them I would described as intention or interest. This relationship is too weak to be called coupling, IMO. - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, June 25, 2008 12:17:18 AM 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: > 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/implement ation 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/translat e 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
