To me, yes, it does. However, a service provider who encapsulates ESB in its service offer may not point to the ESB provider as an excuse for not delivering the service.
I am fine with invisible ESB. - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Monday, March 23, 2009 4:03:41 PM Subject: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > Please, find my comments in the text. > - Michael > > > > ____________ _________ _________ __ > From: Rob Eamon <rea...@...> > To: service-orientated- architecture@ yahoogroups. com > Sent: Monday, March 23, 2009 4:53:07 AM > Subject: [service-orientated -architecture] Re: Joe on SOA without > service-enabled apps > > --- In service-orientated- architecture@ yahoogroups. com, "Udi Dahan" > <thesoftwaresimplis t...@...> wrote: > > > > > > Does this make SLAs part of the service, or its interface? > > MP: I still hesitate tying SLA with any INTERFACE because SLA is > provided via the interface, not by the interface. I think that SLA > always belong to the service. Another thing when you specify an SLA > and (mandatory) mention which interfaces support it and which not. > I think, this is more accurate and clear approach. I do understand > a sort of slang you use when talking about 'SLA is a part of > interface', but I am afraid that many would take it literally and > end-up with confusion - dropping value of service itself, i.e. the > entity that provides the SLA in reality. I agree, that is a clearer way to present it. > > > > Does any of the above change when the consumer is a subscriber to > > events the service publishes? > > IMO, no. > MP: as I explained in my first answer, IMO, yes. However, the only > difference caused my 'yes' is that there is a possibility that in > the pub/sub the publisher, i.e. service, may be substituted by an > intermediary and subscriber, i.e. service consumer, has to arrange > Service Agreement (including SAL) with this intermediary instead of > the service/publisher. I've come to the conclusion that the intermediary never has independent contracts of its own. Any facility above communication (e.g. transformation, etc.) is as an agent of an end point (provider or consumer). The use of an ESB shouldn't change who has the service contract. For example, say a provider exposes a SOAP interface for its operations. Somewhere in the software mix is an HTTP server, whether external or built-in with the provider in some fashion. The agreement isn't with the HTTP server in either case, correct? So too should it be with the ESB. It is simply the communication path in the simplest case. If it does more, then it is doing so on behalf of the provider or the consumer and those implementation/ configs "belong" to the provider and the consumer. Does that simplify things? -Rob
