--- In [email protected], "l.wil...@..." <l.wil...@...> 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
