I'm having a problem getting our Web Service DLL to 'recognize' the middle-tier DLL when each resides on different machines. Here's our general setup.
We have a WinForm front-end, a web service running on IIS that 'channels' user requests through to the middle-tier [and then on to SQL Server, and then back].
So if I'm in Screen 'A' and want to retrieve record 'XYZ', the winform sends up a dataset to the web service. The dataset contains info on what the user wants to run. So I'll create a dataset like so...
DsRemoteInfo: "Screen A", "RetrieveRecord", "XYZ"
and then do a ....WebService.Service1 oService = new WebService.Service1();
oService1.URL =
DataSet DsReturn = oService.PerformService(DsRemoteInfo)
The Web Service function 'perform service' takes the Dataset and passes it on to an application manager, which is sort of a 'face' module for the middle-tier. The appropriate function in the middle tier is called, and then any resulting data is passed back.
That all works fine...so long as the Web Service DLL/assembly and the middle tier assemblies/DLLs are on the same machine. However, we realize that most client installs will have the Web Service on a different machine/server than the machine/server for the middle-tier. That's where we've hit a wall.
We know that we have to use a Web Config file for the Web Service to locate the assembly for the middle-tier. We've also read some docs from MSDN on Codebases/probing, and we realize that the assembly must be strongly defined/public [as opposed to private].
However, when we try the 'recommended' approach, we get errors when the Web Service DLL tries to 'access' any function in the middle tier. We're able to instantiate the primary middle-tier DLL from within the Web Service, but when we try to access any function, it fails.
Sorry for the lengthy post, but I wanted to fully describe what we're trying to do. Does anyone have any detailed advice on how to accomplish this? Are there any web sites with FAQs that describe how to do this?
Thanks,
Kevin
