+1 Michael
________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Thursday, May 14, 2009 4:06:51 PM Subject: [service-orientated-architecture] Re: JP on defining SOA I'm not saying one has to have an intermediary either. But when one is used it is conceptually part of the consumer and/or provider, not an independent entity. It is an implementation component of the provider or consumer. -Rob --- In service-orientated- architecture@ yahoogroups. com, "l.wil...@.. ." <l.wil...@.. .> wrote: > > I am not saying you *must* have an 'intermediary' , just that it is a useful > pattern in many scenarios. > > Lawrence > > --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon" > <reamon@> wrote: > > > > --- In service-orientated- architecture@ yahoogroups. com, "l.wilkes@" > > <l.wilkes@> wrote: > > > > > > Perhaps I used the wrong term, sorry... > > > > > > But if the intention is to isolate the service from changes to the > > > implementation, then some form of 'intermediary' is useful. Call it > > > facade, wrapper, what you will. > > > > The service interface is the piece that isolates the service implementation > > from the rest of the world. > > > > > Often the 'intermediary' can be something like an ESB, where most > > > ESB products can host the service endpoint, and act as the > > > intermediary to the implementation, providing the transformation > > > and mapping technologies to marry the two together. > > > > I think it is important not to view the ESB as an independent actor. > > ESB-hosted components should be viewed as a part of the consumer or the > > provider. Consumers do not have a contract with the ESB, they have a > > contract with the service, which is accessed via the ESB. The ESB might be > > but one of multiple interfaces a service exposes. > > > > The ESB most times will host a service interface (a single ESB will host > > interfaces for multiple services). It might also host consumer helper > > components. > > > > For example, the service interface exposes a particular message format on a > > particular communications path (e.g. the ESB). To use the interface a > > consumer *must* use the particular message format on that particular path. > > The consumer might need help to create the necessary format and can use the > > ESB to do so. Thus, that ESB component that does the mapping is part of the > > consumer. > > > > > More often than not, this is exactly what we find many of our > > > clients faced with when providing service interfaces on top of > > > existing implementations. > > > > > > But equally, given that change is a constant, it seems a good > > > pattern to adopt when implementing any service. > > > > I'm with Michael. Calling the service interface a "facade" seems odd. It > > implies something additional is present but in reality it is already there. > > All service interfaces are facades--the face of the service. > > > > -Rob > > >
