0

I have an application that consists of a web application, and mutliple windows services, only one windows service is installed depending on what version of the backend sofware is used.

Currently, Data is saved by the web app in a database, then the relevant service is installed and this picks up the data and posts it in to the backend system that is installed.

I want to change this to use WCF services so the resulting data is returned directly to the web app.

I have not used WCF services before but Im assuming I can do something like this.

WebApp.Objects.Dll - contains Database objects, eg PurchaseOrder object

WebApp.Service.Contracts.dll - here I can describe the service methods, this will reference the WebApp.Objects.dll so I can take a PurchaseOrder object as a parameter

WebApp.Service.2011.dll - This will be the actual service for the 2011 version of the backend system, this will reference the WebApp.Service.Contracts dll

WebApp.Service.2012.dll - This will be the actual service for the 2012 version of the backend system, this will reference the WebApp.Service.Contracts dll

So, my question is, does the web app need to know the specifics about what backend WCF service is used? I just want to call a service with the specified Interface and not care about how its implemented or what it does internally, but just to return the purchase order that was created in the backend system (whether it return an interface or a concrete class)

Will i be able to create a service client without needing to know whether its the 2011, or 2012 WCF service being used?

WraithNath
  • 17,658
  • 10
  • 55
  • 82

1 Answers1

1

As long as you are able to use the exact same contract for all the versions the web application does not need to know which version of the WCF service it is accessing.

In the configuration of the web application, you specify the URL and the contract. However, besides the contract there might be other differences between the services. In an extreme example this might mean that v2011 uses a different binding as v2012 of the backend - which is not very likely from your description. But also subtle differences in the configuration or the behavior of the services should be addressed in the configuration files. E.g. if v2012 needs longer for an action as v2011 does, the timeouts need to be configured so that the longer time of v2012 does not lead to an expiration.

Markus
  • 20,838
  • 4
  • 31
  • 55
  • Hi, thats great thanks, I was thinking of having a single dll to store the contracts, and all versions of the services reference this to ensure they are the same, the multiple back end services all do the same thing, and have the same parameters, they just use a different set of references to the back end software which is why I dont want the web app to reference them direct. If all the web app needs is a contract and an address that will work great! – WraithNath Jun 22 '15 at 10:15
  • 1
    @WraithNath: I don't know all the details, but maybe you don't need WCF at all (would reduce complexity of deployment and configuration, request times). A reason for WCF is, if you want to deploy the services to different machines. Just declare a common interface for all the backend versions (the contract). Implement the interface in a separate assembly for each version of the backend. In the web application, configure the concrete instance that you want to use and create it using Activator.CreateInstance. – Markus Jun 22 '15 at 10:43
  • thanks, I do currently have some dlls, that I drop into the bin directory depending on what version it is, and it loads them via reflection if they are there. This does work quite well but it does mean the back end system needs to be installed on the web server which is sometimes not want the end user wants, our application is deployed across servers in some instances already where the web server is publicly accessible so the back end finance system doesnt want to go on the same box ideally. Thanks! – WraithNath Jun 22 '15 at 14:25