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 [email protected], "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 [email protected], "Rob Eamon" <reamon@> 
> wrote:
> >
> > --- In [email protected], "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
> >
>


Reply via email to