>I guess I'm not explaining myself very well. > > The originating *component* (which is one part of the consumer) does > not send its private message to the service provider's announced end- > point. Instead, it sends its private message to its private entry > point in the ESB. That ESB component (the other part of the consumer) > translates the private message to the the message of the service > provider--and then sends that message to the provider's "announced > end-point." This picture appears differently to me. The ESB is announced as an intermediary, infrastructural element. None of consumers may claim a part of ESB “its private point” because ESB provides service (pardon, in human language meaning) to the consumer by transforming its data. I never saw a double trip to ESB as recommended scenario; on a contrary – consumer sends 1 message to ESB, which transforms the message and transmits it further to the provider. Tell me if I am wrong. That is, we cannot really split ESB into consumer vs. provider side players. > Internal to whom? The ESB? If so, that's quite wrong IMO. > The "normalized" or "canonical" message definitions should be > explicit and the service definition should explicitly state support > for the appropriate public message definitions. I vote for this by both hands. However, dealing with legacy systems, you may have to face different message formats on their external adapters. I think, Sun tried to capitalise on this in heir Composite Application model. > Ideally, the ESB doesn't have to do *any* transformation > since ideally the consumers and providers are using the right > messages directly. Alleluia ! Steven jones, Rob and I agreed on what you are looking: no transformation, only mediation = ESB. > The only way it could stay the same is if another provider appears > (or exists) that supports the same message(s), the same operations, > and the same behaviors. Your consumer *depends* on those items, so > therefore it is *coupled* to that service via those aspects. We cannot be more disagree on this! In SOA, proper level of abstraction does not define a consumer via service provider’s message(s), operations, and behaviours. It would be absurd IMO if it does. The consumer choose if it likes service provider’s message(s), operations, and behaviours (as a part of the service interface, as a part of the Service Description). The consumer does not depend on this but use it when needed. I totally do not accept an idea that a service makes a consumer dependent. This is application-oriented concept, not SO. > Change any of those items, and the consumer will need to change. Not consumer but maybe its service related proxy. Moreover, this is the old Web Service inheritance. In “Service Reuse and Entitlement” I demonstrated how to write regular Web Service which does not require a consumer to change if the message XML Schema changes. > I go to a pub. I'm a consumer. The person that pours the beer is the > provider. The contract is that I request a beer, indicating the type > and size of beer. The provider pours the beer and gives it to me. > … > Ordering from the waitperson doesn't change the fact that I'm still > dependent on the bartender if I want to get a beer. No bartender, no > beer (the waitperson isn't allowed to "become" a bartender). I would say that you are talking fine-grained interface here. I would define a contract between me and the pub. I do not care if it is a bartender or waitperson picks up my order. The pub is the thing which provides a beer to me. I define attributes of my order - the type and size of beer. This is it. Moreover, I can send my requests to several pubs and accept the one which serves me first. I agree, this depends on the culture. I did this in the US(where I cancelled dissatisfied orders) but in Londonone barman tried to yell at me like I was obliged to buy from him (BAD service in Englandis well-known). > >At any particular moments in the market, there are a lot of > > producers with no consumers as well as potential consumers > > w/o producers.
> But we don't build software that way. And we don't create > organizations that way. Oh boy, what country you are living?.. As an MBA teaches, the most important thing in the business is the place where you put it. My uneducated guess is that 85% of American small and medium business is built in this manner. Advertising is doing the consumer (and product). > In both cases, there must be a reason to > start producing something. A "build it and they will come" approach > sometimes works out, but often we've seen that that is not the case. > … > Consumers without producers indicates demand--which will be filled if > it makes business sense. But you don't build a consumer organization > or software system without at least the high likelihood that a > producer is going to come along. I am not talking about “consumer organization”. As of SW, many new things ( like on-line market place) were created during dot-com era, there were no customers up-front, they hoped to educate and create them. Rob, I think we have overwhelmed the Group. We got a lot of agreement points and its is good. The rime will show the place for ESB in SOA. I will go in my way and I wish you the best in yours. See you later… ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, June 25, 2008 10:47:48 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: > > > 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. This is purely a terminology issue. IMO, the intent of "service" in the SOA sense is that it provides coarse-grained business capability. Data transformation is not a business capability, it is a technical activity. The word service is most decidedly overloaded and overused. In the context of SO discussions (such as this one), I try (not always successfully) to reserve the term service for business capability. But I concede the point. The use of "service" in the infrastructure context is perfectly legit, as long as we understand each other--and with your clarification, I think we do! :-) > 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… I guess I'm not explaining myself very well. The originating *component* (which is one part of the consumer) does not send its private message to the service provider's announced end- point. Instead, it sends its private message to its private entry point in the ESB. That ESB component (the other part of the consumer) translates the private message to the the message of the service provider--and then sends that message to the provider's "announced end-point." > My point, you cannot hide message transformation in the ESB unless > this transformation is neither for consumer nor for provider. I'm not sure I advocated hiding message transformation. I've explicitly stated that a component that translates a private format to the public format is best considered as part of the consumer or the provider (depending on the direction--consumer does private to public, provider does public to private; and maybe the reverse on a possible reply in a request/response scenario). A transformation that is neither for the consumer nor for the provider seems pointless to me. > 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. Internal to whom? The ESB? If so, that's quite wrong IMO. The "normalized" or "canonical" message definitions should be explicit and the service definition should explicitly state support for the appropriate public message definitions. An ESB can do all sorts of transformations. IMO, those transformations are defined and "owned" by the end-points, not the ESB. The ESB is simply the run-time environment hosting the transformations on behalf of the consumers and providers, when needed. Ideally, the ESB doesn't have to do *any* transformation since ideally the consumers and providers are using the right messages directly. > > 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. The only way it could stay the same is if another provider appears (or exists) that supports the same message(s), the same operations, and the same behaviors. Your consumer *depends* on those items, so therefore it is *coupled* to that service via those aspects. Change any of those items, and the consumer will need to change. > 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. You're describing loosely coupled, not "totally decoupled." You're correct that in theory a consumer may not need to change if a replacement exists or comes into being. But business systems typically don't include this type of redundancy (save for DR and business continuity-- but then that's a matter of cloning, not of another independent service providing the same interfaces and behaviors). Communication decoupling through the use of an intermediary is definitely a Good Thing. The provider can move anywhere at all, can be deployed anywhere, can even be unavailable for a time (if the service contract allows for such delays). All Good Things. We've collectively learned that using an intermediary allows for a great deal of flexibility (even with the added complexity). But the aspects mentioned above couple these end points, regardless of the use of an intermediary. > > 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. I disagree. It is a concrete relationship between consumer and provider. > 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? This analogy doesn't reflect the relationship I'm attempting to describe. > Does it mean that two programs written in Java are coupled because > of Java? This isn't an equivalent analogy either. If those two programs do not interact, they are not coupled. If they interact, even via an intermediary, they are. I think you feel that because a consumer and provider communicate with an intermediary instead of directly that they therefore do not interact and therefore do not have a relationship. From a communication standpoint they don't but from an interaction standpoint they do. They are interacting and that interaction is dependent upon the interface contract. > I think that the word `coupled' is too strong for those cases. Me too. I don't think those case are equivalent to what I've been explaining. I'll try my hand at a different analogy, though it isn't perfect. I go to a pub. I'm a consumer. The person that pours the beer is the provider. The contract is that I request a beer, indicating the type and size of beer. The provider pours the beer and gives it to me. I can make the request directly to the bartender. And the bartender will respond directly to me. I can't order just anything, I have to order in the manner the provider understands. The menu is my directory (sort of--its the operations supported by *this* service). Successful: "Give me a pint of Guinness." "Here you go." Unsuccessful: "Ein bier bitte." "I don't speak German." Unsuccessful: "Give me full tank of petrol." "What?" No bartender. No beer. So where did the menu come from? ;-) Or, I can interact with a bartender through a proxy, the waitperson. I indicate what I want to the waitperson. The waitperson relays that to the provider, gets the beer from the bartender, and delivers it to me. That person might translate my message. Perhaps from German to English. In this case, the ESB is acting as my proxy. Together, from the provider's viewpoint, myself and the waitperson are the consumer. Ordering from the waitperson doesn't change the fact that I'm still dependent on the bartender if I want to get a beer. No bartender, no beer (the waitperson isn't allowed to "become" a bartender). Since I'm loosely coupled to the bartender (yikes!), I can go to any bartender to get my beer. Which bartender is used doesn't matter but it does matter that it *is* a bartender. The waitperson might hide from me which bartender it is and do the legwork of getting to another bartender on my behalf. As long as I get a beer, I don't care. But I can't go to the barbershop. Nor to the car rental place. I'm dependent on a bartender. If none exist, anywhere, no beer for me. I do know and should know that I am dependent on a bartender, even if I don't directly communicate with one. This describes a request/reply interaction. So here's another scenario: I place an order to be delivered to someone else. I might specify that someone else. Or I might not care who the someone else is. But I do make the request, and I do rely on it being fulfilled. Otherwise, the someone else is going to come pound on me (if he can find me!). > At any particular moments in the market, there are a lot of > producers with no consumers as well as potential consumers > w/o producers. But we don't build software that way. And we don't create organizations that way. In both cases, there must be a reason to start producing something. A "build it and they will come" approach sometimes works out, but often we've seen that that is not the case. Consumers without producers indicates demand--which will be filled if it makes business sense. But you don't build a consumer organization or software system without at least the high likelihood that a producer is going to come along. > The relationship between them I would described as > intention or interest. This relationship is too weak to be called > coupling, IMO. They are coupled on the message format. They are coupled in the fact that they interact via an agreed upon mechanism. The fact that the mechanism is implemented in an ESB is immaterial. Perhaps someone else can chime in here. Are Michael and I really agreeing but don't know it? Are we tripping ourselves up on terminology? -Rob
