As part of a service orientated architecture (SOA) I've been asked to create a
web service which itself acquires data from a third party web service. I'm to hide any implementation specific details of the third party web service and map the data returned so as to avoid leaking any implementation details of the third party service.
I'm new to SOA. I would colloquially call this project something like "a web service bridge".
What is the correct SOA enterprise architecture pattern term for this?
I'm very confused as many of the enterprise architecture patterns seem to be describing the same thing (service facade?, message broker? message channel? proxy?). I don't think I'm quite in tune with the level of abstraction required.
Best Answer
Just by the question, one cannot pinpoint a single pattern because there are multiple aspects to a pattern. Depending on how your service is architected, the pattern can vary. In general, however, what you specified is the overarching Service Abstraction design principle.
Also, quite often a piece of software, especially at the scope of a web-service, is composed of multiple design patterns. Thus a web service may be designed with Model-View-Controller pattern while has a set of adapters, data mappers, (explained below) etc. in its various layers. You can still identify its primary business value and map that to a design pattern if that is important for your project. Thus, even though not all the patterns I talk about below may be considered enterprise design patterns by everyone, I find it more useful to use the pattern that conveys what the service does more than whether it is necessarily an enterprise design pattern or not.
From what you stated in your question, it seems most likely to be a Façade or its specialization Remote Façade. It would be a Façade if its primary purpose were to simplify the underlying API and hide the complexity (which is what you are stating). Remote Façade additionally also aims to reduce the number of calls between two systems if that's a concern.
An Adapter pattern is usually architected with an assumption that there are going to be multiple adapters (whether in present or in future). Thus, if your primary concern is to create a web service such that it would provide a consistent interface and be able to perform various operations on underlying service(s), then you are designing an adapter. A typical example would be when you are offering a new deployment service, and expose a method called
Compile(). It implements two adapters, one for MSBuild and the other for nmake. Depending on which system a particular project is written in, it will pick up the correct adapter and issue appropriate commands.A similar pattern is the Data Mapper which is mapping of a consistent set of data types to data types of various underlying data stores. Let's say if your service was exposing a
UserIdfield to its client such that it mapped to aUserNameand anUserPrincipalfield in two different data stores, then this is what you are looking at. It does not mean that you necessarily have multiple data stores, it means that you are architecting with that possibility in mind.The Bridge pattern is usually applied where there is an abstraction and its implementation, and yet both need to be varied. Typically, the implementation is achieved using an adapter pattern, so you end up with the Abstraction and its subclasses, as well as a set of adapters.
A Gateway is more around providing a consistent interface between services. So you could have a www.myservice.com which exposes a REST API, which in turn calls other services which may be using various protocols. It is the responsibility of the Gateway to ensure that clients always get the same interface, even when any of those services decides to change its protocols.