Fitting a 3rd party web service into your application design

Question

We have a process that runs a few times a day (via a Windows Service) and can also be invoked at anytime by an administrator level user (through a web app). This process gets a data set from a partner through a web service, then we merge this data with our local copy in our own format. Simple enough.

My question is how this fits into our application design. We have an fairly straight forward Application Services layer that interacts with our repository to deal with our domain objects. The domain is persistence ignorant.

How should this process fit into this architecture? Do we,

1. Put most logic in the application service? Just have it invoke the 3rd party service, grab our local objects from the repository and do our updates/adds/etc and save back into the repository. Basically just treat the 3rd party service as another repository.
2. Have the application service grab our local data (don’t worry about data volume for now), pass that into a Domain level service that will call the 3rd party service, merge data as needed, then return a new dataset to the app service to commit into the repository?
3. Other options…

Answer 1

I would try out the Remote Service Gateway "pattern".
Below is a link to the concept, all be it, from the perspective of Ajax - not a process. However, when I first saw the concept presented at Dobbs Architecture and Design world in 2006 the example was more like your case - a service calling out once a while.

http://blog.ontheheap.com/2008/06/06/ajax-and-the-service-gateway-pattern/

The example in the link provides the basics. In that case, it doesn't have to do translation. However, the Gateway can be broken into different pieces so that it includes a translation layer or data merge layer.

I have had success with this approach.