Separate WCF Service Instance For Different Host Instance and Endpoint?

Question

I have two applications using the same wcf service instance. These two applications will always be started in pairs, so I can have a second, third, or fourth instance of these two. Does this mean I need to have one wcf service being hosted by say a Windows Service, IIS, or console app using a common endpoint address for all four of the instance pairs? Or if I dynamically hardcode the endpoint addresses such that each individual pair has it's own and self host in one of the two applications, does that mean each pair has access to it's own service?

I could probably benchtop test this, but I figure someone with experience could save me quite a bit of coding time just trying to figure it out.

Update (for clarity):

The reason for this question is due to the particular situation I'm working with. The scenario is that the two applications involve one client exe that I am developing and a third-party exe that I have no control over. I can develop a dll that the third-party exe can load. Between my third-party app dll and the client exe the WCF service is intended to bridge the process space to allow the two to communicate transaction information. This will allow the client exe to control the third-party exe and the files it manages.

Answer 1

This is partly an answer partly a long comment. :)

One way to think of a WCF service is that it passes messages back and forth between two separate applications. At a very general level, although there are plenty of good reasons to make a stateful service, it is generally accepted that it is better to be stateless. This means that each time you call it you pass all the info it needs to do what it does, and the service does not need to remember what was done earlier.

The fact that you are worried about separate instances suggests to me that your service has state. I do not think multiple endpoints is the way to go for your situation.

I would suggest that when an application "pair" starts up the first thing it could do would be to request a unique ID from the service. From that point on all messages to the service would contain this ID and the service would process them accordingly. If the service application is maintaining state it would use this ID as a key to identify what information to access to process the call.

At this point you end up with One service application on one server and multiple client applications which is how most WCF systems are designed.

Updated, I think you should google "WCF: Instance Management Per-Call and Per-Session" Your client should be able to open a connection from the client and keep it open. WCF will automagically create a new instance on the server for you. This would mean you don't need the "application pair ID" but you would need to keep the session open.