Thursday, November 4, 2004

My Continuing Fight with .NET Remoting

So I went for the sleep option around 3:15am. I should have picked option two (coffee) because my brain was still way too active to let me fall asleep. I kept thinking about different options to try. In any case, I'm a couple of steps close to getting my solution to work. For one of our systems, we have a set of COM objects that are hosted in COM+. These objects are exported through COM+ / DCOM to several clients across a LAN / WAN environment. The clients create an instance of a broker object exposed through COM+, and then use that broker to create instances of other server business objects (SBOs). Each of these instances is intended to hold state (they connect to a variety of ERP and database systems, so opening and closing them often has a high transaction cost). Our objective with this project is two-fold. First, the client that activates these distributed components is Wonderware's InTouch 7.x. The license costs for our customer are getting a little high, so they are looking to replace the InTouch client with a .NET client written in C#. I had originally considered using XML Web Services hosted in IIS to wrap the functionality of the SBOs. This was before I learned that the SBOs held state. XML Web Services is a stateless architecture, so it wouldn't due for accomplishing our task. So that is why I chose to go the .NET Remoting route. I'm still going to use IIS to host the remoting component, as it will save me time by acting as the hosting control, provide security, and also take care of channel and load management.

So after banging my head on the wall last night, I got this far: I have a Client Activated Object (CAO) that is hosted by IIS. I've written the web.config file to expose the CAO. I used "soapsuds.exe -nowp -ia:MyRemoteCode -oa:MyRemoteCode_Proxy.dll" to generate a meta-data proxy for the remote object. I created a client that registers the remote object, and then creates an instance of it. So far so good. Here is where the trouble starts though. I create a second remoteable class that also inherits from MarshalByRefObject. This one is instantiated by making a method call on the first remoted object. However, when the client calls "firstRemoteObject.GetSecondRemoteObject()" I get a type mismatch error on the return type. Evidently, the meta-data generated by soapsuds.exe doesn't exactly match the typing information passed back by the remote call. So this is where I am stuck tonight. I spent the day working on another project, so I haven't been able to touch it yet. If I can stay concious long enough I may try again tonight. If I get it solved, I'll post sample code.

No comments:

Post a Comment