I have some WCF services running over HTTP and a C++ client using gSOAP to consume them. This works, but we are considering running the service host in the same process as the client, to create a fully local stack.
What is the best way to allow the C++ client to consume these services? Do we still need to use HTTP binding? Or will something like named pipes or NullTransport work? Preferably something that will work with gSOAP or something that we can replace gSOAP with.
if both are in the same process then have them "talk" to each other via direct means. i.e. accessing objects directly. otherwise going over a comms layer is extremely expensive. the same can be said for accessing files on your hard drive via a network share when really going file say c:\foo\something.txt is more productive.
c++ allows you to construct CLR types that are both native code but also CLR-aware. using this technique allows your c++.NET type so to speak from .NET proper. your .NET types will have no idea that they are invoking c++ or vice versa.
have a look in your c++ compiler settings for CLR
Related
Let's say I have a C dll with functions like:
void beep();
char* foo(char** whatever);
Now I want to be able to put this dll on one machine (server) and call it from a different machine (client). The client can be C# but the dll (and proxy server) needs to be regular C. The ideal would be something like this on the client:
MyDllAccess remote = ProxyLib.GetRemoteDll("192.168.1.10:12100", "mydll.dll");
remote.execute("beep"); // other machine beeps (uses GetProcAddress to find function)
I know I'm reinventing COM, etc, but..... is there a way? If not, why not and what is the simplest way to do what I want since I already have the dll?
EDIT: It also needs to work with Linux shared library, e.g. ProxyLib.GetRemote("192.168.10.12100", "mything.so")
If you need it to work across different OSes, you will have hard time doing it in a pretty generic manner. You can search for "platform independent APIs" in this wikipedia article: Inter-process communication to get an idea. Most of what you will find is heavyweight.
One simple way would be to write an ad-hoc HTTP REST server (possibly with JSON or XML as the interchange format). It has the advantage of being simple, and you will be able to access it using any OS with a decent HTTP stack (including mobiles).
I have a .NET \ C# class that loads a structure into memory. There's a C++ application on the same machine that need to be able to query the in memory structure.
My question is around performance. I could expose the functionality as a COM object that the C++ could call via COM ... or I could implement it as a WCF service that I believe the C++ application would be able to query via Named Pipes ...
Does anyone have any experience with performance either way? I've fond some great stats comparing WCF Named Pipes Vs. TCP vs. HTTP, but I don't know enough about COM to make an educated decision on how it'll perform. Any thoughts would be appreciated.
Thanks
Warrick
MS SQL works via named pipes (based on tcp channel, generally speaking), so I think it's perfomance is good enough.
Take a look at Choosing Communication Options in .NET
AFAIK today WCF's named pipes/tcp conversation is recommended way to do interprocessing via network (LAN or global). WCF is the successor of Remoting and supplants COM/DCOM for managed code. But remoting is not deprecated/legacy yet and can be used for cross-appdomain binary communication.
I've seen that NetNamedPipeBinding exists in C# and in C++ (source) and I would like to know if it's possible to use it to transmit datas between a C++ program and a C# application?
There's a good example here showing how to do IPC (Inter-Process Communication) between C++ and C#.
http://www.codeproject.com/Articles/34073/Inter-Process-Communication-IPC-Introduction-and-S
If your C++ compiler is a recent version of Visual C++, with all the extensions to support writing managed code, then you can use WCF easily to pass data between a C++ program and a C# application.
If your C++ compiler doesn't support managed code extensions, you can still do it but it is a lot of work, because the WCF channel stack uses some layered proprietary protocols for message framing, security negotiation and message encoding, which you would need to reimplement on the C++ side if you can't use the managed implementation provided by WCF. See for example this question for the kind of issues which arise.
If you can't do managed C++ it is often much easier to forego some of the benefits provided by WCF and, depending on your requirements, either to:
use a managed COM-visible wrapper around a C# WCF service, consumed as a COM server in the C++ code; or
roll your own IPC mechansim using a named pipe directly, calling the WIn32 APIs on the C++ side and using the System.IO.Pipes types on the C# side.
Yesterday I asked about what technology should I use to create dynamic web content here:
PHP, AJAX and Java
The suggested methods were JSP, JQuery, etc. But I thought maybe because I'm a .Net developer and I don't have any experience in web development but I have experience in WPF and C#, maybe I should go with Silverlight but the main problem here would be how can I communicate with the core part of my system which is implemented in Java?
So the main question would be: What is the best [and easiest to learn] method to send a piece of data to the Java part, get the result and use it in silverlight? A tutorial or simple example would be nice.
Thanks a lot in advance.
You should use Java Web Services as stated. Use WCF to invoke the Java WS by adding a Service Reference in Visual Studio by its url, then use the proxy classes generated automatically (located in Reference.cs) to invoke the WS. This is easy but remember SilverLight WS invocations are always asynchronous, so you must cath the OnCompleted event to get the results of the invocation. WS are slow but if the machines are in the same LAN, invocation could take a few milliseconds.
I think pipes are not your solution as SilverLight executes in a Sandbox and have many restrictions on what you can do.
This will depend on many factors, however a relatively easy approach would be to use Java Web Services. On the .NET side, WSDL will be picked up and transformed into proxy class by WSDL.exe from the Windows SDK. If, however, these two systems are on the same server (and intend on staying this way), you may decide to use pipes.
I have some .dll native C++ programs which mainly return int/double values, array structures and string values. These values should be taken by a Web Service program made in C#.
I would like to know if it is really necessary to modify my C++ programs and adapt to Web service, i.e. return values such as a XML string/file together with a XSD string,/file. Personally I think I should not modify them because I think C# can receive C++ values using interop and easily serialize using components of .Net library.
However, I would like to receive comments about the best, fast and effective way to pass C++ values to a Web Service.
Thanks!!
I think you can do it as you stated.
In the past, I achieved the same or similar by writing a C++/CLI wrapper around my native classes and consumed those from C#. This didn't incur the overhead of C# interop, which I've noticed can be quite expensive.
I think P/Invoke is what you want here. It will allow you to pass your simple and composite types between managed and unmanaged code, and you won't have to write any C++/CLI wrapper assemblies.
This (MSDN) is a good start for P/Invoke. If you scroll down here's a section called 'Specifying Custom Marshaling for User-Defined Structs'. This will allow you to pass your user-defined structs back and forth.
Look up MarshallAs and you can see all the primitive native types you can marshall. The DllImport attribute is something you will want to search for as well.
If performance becomes an issue, I would recommend serializing/deserializing into either named pipes or a local socket, but I'm not totally clear on the performance chararistics there. Good Luck!
The best, fastest, most efficient and effective way to expose your C++ application as a web service is to put C++ web service code on top of it.
See GSoap for a very fast, open source, implementation - one that is 3-5 times faster than the .NET and Java equivalents.
As long as you can return it to C#, C# should be able to return it from a web service. You should not have to do any manual serialization at all.
If you choose to go the serialization route you might want to look at 'thrift' (http://incubator.apache.org/thrift/).
From the website:
Thrift is a software framework for
scalable cross-language services
development. It combines a software
stack with a code generation engine to
build services that work efficiently
and seamlessly between C++, Java,
Python, PHP, Ruby, Erlang, Perl,
Haskell, C#, Cocoa, Smalltalk, and
OCaml.
Originally developed at Facebook,
Thrift was open sourced in April 2007
and entered the Apache Incubator in
May, 2008.