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? 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. 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...?) As of messaging standard, I have to look into sources (it is not at the top of my head now). Now I only remember that JMS does such separation, MQ/WebSphere MQ does and all Transaction Management facilities in Java do not transfer transactions through Destinations because of the same reason. There are a lot of custom solutions, e.g. from BEA WebLogic, for acknowledgment of the sender about receiver getting the message but all of them proprietary solutions. BTW, an intermediary can transform message in any way it wants w/o sender and receiver knowing about it - full decoupling. 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? At the level of common interest? If so, if the interest disappears, they become decoupled? :-) - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, June 23, 2008 10:20:56 PM Subject: [service-orientated-architecture] Re:Data services (was Re: Definition of SOA) --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > Rob wrote: "There is no such thing as components that interact in > some way being "totally decoupled."" - I did not say that > components interacted! In MOM ( and reflective - in EDA), sender > and receiver DO NOT INTERACT with each other, Yes, they do. Not at a direct communication level, but they are interacting. > and even more - they should not know about each other. They only know that they exist, not where they are. They are decoupled communication- wise, but they are coupled in other ways. For example, they are coupled at the agreed-upon message level. They are coupled in what the provider agreed what it will do upon receipt of the message. > This why the standard does not specify any acknowledgment mechanism > between sender and receiver but only between receiver and > intermediary/ destination. To which standard do you refer? > Rob wrote: "Components connected via an intermediary are still > coupled." Let me ask - how? What does mean in this > case "connected"? To what? To the intermediary or to each other? Components communicating to each other through an intermediary are at least at the message/document level (the intermediary doesn't give a rip about the message--but the end-points do). Possibly even more tightly if the interaction is request/reply (which the intermediary may facilitate). They are also coupled in how they communicate- -if the only way to communicate to a provider is via the intermediary, then that also is a level of coupling--consumer must use a particular format and protocol to communicate to a specific host (the intermediary) to cause X to happen. Change a document format at the provider. If consumers must change, they are coupled. Change the behavior of the provider. If consumers now do not get the desired behavior then they'll need to change what they do or who they call, which indicates coupling. > Rob wrote: " The ESB is an interface to the service, so yes, > it "represents" the service as all interfaces do. But that doesn't > change the nature of the contract." > > ESB is not necessary and interface to the service! > It is rather a Facade, or Mediator, or whatever which is capable of > totally masking the service together with its interface. 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. > ESB may or may not represent the service. If a service is implemented using ESB tools, than the ESB is more or less the service. If the ESB is the intermediary to a service, then it is an interface to a service. > So, considering the lowest denominator (I do not want to go here > into comparison of different products from different vendors), ESB > does not represent the service and this dramatically affects the > Contract. I don't want to get into technical details either. But an ESB can do two things, IMO. * Act as a service (service implemented within the ESB), whereby it must honor the contract. * Act as an interface to a service (service implemented elsewhere), whereby it must honor the contract. It is either service or the conduit to one. In either case, the service contract must be honored. If the ESB is treated as a non-interested 3rd party, then you're going to run into the problems I think you're warning about. > Simple example. We have a BizTalk 6.x as such intermediary between > service consumer and provider. The internal configuration of > BizTalk is two pairs of coupled servers; the communication between > servers is SSL enabled, which seriously degrades communication > performance between consumer and provider. Consumer has no clue > (should not have) about BizTalk and its security means. Question: > who should tell the consumer that SLA (a part of the Contract) has > to be adjusted to accommodate invocation delays caused by BizTalk? The service provider. If the provider has chosen to provide an interface via BizTalk, then the performance considerations must be addressed in some manner. The consumer not knowing it is talking to BizTalk is a Good Thing. It thinks it is talking to the service, right? So that path better meet the promised performance levels. Otherwise the service consumer has every right to beat on the provider. And the provider cannot reasonably say "but it's BizTalk's fault, not ours." Instead, the provider folks go to the BT team and beat on them to iron out the performance issues. > "And it doesn't change the separation of interface and > implementation- -as you point out, the call to the intermediary is > a call to the service from the consumer's POV, for all intents and > purposes." - I do not think this relates to the subject; of cause, > an intermediary does not change the separation of interface and > implementation. It relates because the ESB is the interface. It may be an interface facade, which in turn invokes the service provide via another path (e.g. HTTP post or something). My point was that the ESB would be an interface implementation in most cases. > > Rob wrote:"The intermediary is the provider's agent..." - +++++1 ! > > Rob wrote: "ED approaches can be used at a BA level." - ++1 > > I just say that EDA is not a part of SOA, they coexist and > complement each other (I disagree with ZapThink in this point). You and I cannot agree more on this point. > Also, if an ESB sits in between consumer and provider, somebody has > to be responsible for it to the consumer. IMO, it is the provider's responsibility. In the case, the ESB is simply one of possibly multiple interface/communica tion mechanisms supported by the service provider. The provider must support each of its interface mechanisms. -Rob
