How to send output of native executable programs into the world of Web Services?

Question

Hello,

I have many C/C++ old native .exe and .dll programs running on Windows servers of my company.

Some .exe programs (I will designate with E) get results on the console or into a file and most of .dll programs (D) return results in arrays of structures.

My boss has asked me for the possibility to “also” send the results generated by ‘E’ and ‘D’ to a .NET Web Service platform using WCF without modifying ‘E’ and ‘D’.

I read a little about Web Services/WCF to have an answer. However, I built a first solution scenario in my mind: create C# WCF projects which:

• For ‘E’, will read the files generated by the ‘E’ programs and will send the results to clients
• For ‘D’, will “interoperate and marshall” with the returned values before sending the results.

I have some questions here; after getting the results from ‘E’ and ‘D’, how do I send these results to the client? Is this a “must” to serialize the results before sending to the client program? I suppose the client program should have a routine to deserialize. If the value to send to the client is a simple string or a simple integer, is this necessary to serialize?

Thanks!!

Answer 1

You should read up some tutorials on web services (soap, for instance) and how to implement them in C#. Once you understand them it'll be clear how to interoperate with your programs. Your assumptions are correct. Reading files for 'E' and "interoperate and marshall" for 'D' are the most straight forward (if not most efficient) ways of doing it.

Answer 2

If you still have the source for these programs, then you should first refactor them to be less dependent on their "presentation layer". For instance, you could change the exe programs to have one layer than returns data, and another layer than formats and prints to the console.

A web service could then call the "data" layer.

Answer 3

First of all, you should be aware that there are different kinds of webservices. The most common ones are REST and SOAP. I assume that you want to use SOAP. In that case every message has to be encoded, but that will be handled by your SOAP library/framework. The same is true for the client. He will usually not decode SOAP messages "by hand". It's handled by the clients SOAP library/framework.

Your thoughts about integrating E and D are right. For D you might also have a look at CLI/C++. It might make integration easier, but that depends on your scenario and your .Net and C++ knowledge.