Dear H.Ozawa, you did not get my point - I said that it WAS UNREALISTIC! That is, the realistic ESB does NOT represent a service it engages on the provider side. As a result, the consumer must have a Contract with ESB but this Contract does not make sense because it does not offer any RWE to a consumer.
All together, I see that ESB does not fit into SOA infrastructure in the form ESB gets represented today. The only practical use of ESB in SOA spirit might be if ESB hosts the process exposed as a service. The process must offer concrete business value - the RWE. Only in this case, a customer does not need to know about any engaged services because process' RWE has to absorb the RWEs of individual engaged services. All these confusions with ESB have appeared because SOA service now is not viewed as only an interface, IMO. New service characteristics - functionality and RWE - are not in the programmatic realm addressed by an ESB. There is a need for another technology. So, when dealing with ESB, just step back into Web Services and keep in mind related limitations. - Michael ----- Original Message ---- From: htshozawa <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, June 24, 2008 11:28:28 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: > > 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...?) > That would be true if we assume that all SOA functionalities are to be placed in a ESB. Unfortunately, that's unrealistic. ESB are used with other software to provide a solution. > BTW, an intermediary can transform message in any way it wants w/o sender and receiver knowing about it - full decoupling. > Yes, with the limitation that it has to fulfill the each contract with each provider and consumer. H.Ozawa
