Exposing Unmanaged C++ Windows Service code as a ASP.NET service.

[Guest]

I have a C++ COM based windows service which have more than 30k lines of code
and which is stablized over years. We need to take the advantage of the
..NET framework for this project, especially the GUI for this service and the
other
windows non gui .NET clients.

What's the best migaration pattern for us considering not to rewrite the
thousands of lines of code.

The question i have are the follows.

We would like to port this service code to a ASP.NET service and expose to
the
client. Doing this way we can take best advantage advantage of the Windows
Communication Foundation (WCF) functionalities which is comming with Windows
Vista.

What will be the best way to do this. Can i make the new ASP.NET service
talk directly to the windows unmanaged service, and then the GUI and the
clients talk to the ASP.NET instead of the windows unmanaged service.

In this approch the ASP.NET service can host all the new functionalities +
the type conversion from .NET to COM and vice versa.

Thanks,
Shyam

 

[Guest]

You case is pretty interesting. First of all if your code is COM unmanged
code you can make it managed but creating wrapper class and then using Stubs
(proxy) in your code, this is beauty of .Net Interoperability. But the main
concern here is architecture. Microsoft Enterprise Architecture introduces
what we call Service Agents which works on Gateway Design Pattern. In this
case your unmanged COM service (which will become managed by
interoperability) will act as service interface and then you can create
Service Agent which will hide all communication and using details and this
service agent can be used anywhere either asp.net application or webservice
or winforms application.

Pls provide feedback whether this post is helpful to you.

 

[Guest]

Hi Alatf,

Thanks for your valuable suggestions about the service agents, it was
really helpfull for me(as i never knew such a patten exist)

After reading about that in MSDN i think i need to extract out the conversion
mechanisms(interops) from .NET to COM and vice versa in a seprate component .

That leads to another question, is it a good design decision to put this
component
in a seprate ASP.NET webservice, and make the .NET clients talk to this
service(which in turn talks to the real c++ COM service).

Can i make use of SOAP protocols here for this kind of object accesing
mechanisms?.

Thanks,
Vineeth