About a week ago, I had an idea of porting the server part of DataSnap framework to .NET. Since then I’ve been fiddling with it in my free time, using Borland‘s C#Builder Personal Edition which is free for non-commercial development. Today, my first prototype of a (stateful) managed socket server is ready. So far, it’s able to serve the following requests:
- asGetAppServers: retrieve ProgIDs of installed appservers (thanks to Andrey Alifanov for this excellent article about using the COM Category Manager from .NET via interop)
- asCreateObject: create instances of COM appservers
- asFreeObject: release said instances
- asInvoke: call simple methods, e.g. AS_GetProviderNames, AS_GetRecords (loading a client dataset works), as well as some simple custom methods of my test appserver.
An ASP.NET equivalent of httpsrvr.dll is also in the works (asynchronous HTTP handler, using the thread pool) but first I’d like to finish the common (transport-neutral) library which is responsible for marshalling DataSnap calls across wires via data packets.
I still have to debug and test marshalling of all possible parameter types (including multidimensional variant arrays, records, enums, byref parameters and so on). It seems to be easier to debug this code within the socket server which is a simple managed WinForms application.
A lot of my current code is, most probably, terribly inefficient, with lots of boxing and unboxing going on (first, data is read from the data packet stream into managed type variables which are then marshalled to unmanaged COM appservers, results unmarshalled to managed variables and streamed back to client). At this stage, I’m focusing purely on functionality; optimization can wait ;-).
What’s the purpose of this work? Most of all, I’m doing it for my own fun and education. I’m still a beginner in .NET and this is a nice way for me to become more familiar with it. I have also acquired a bit deeper knowledge of this cool library called DataSnap.