I have a WCF service that uses duplex contracts via a netTCP binding. It's basically a chat server that relays the messages it receives to the connected clients. The service, and the C# client work great.
What I want to do is create an unmanaged C++ client for the service. Is this possible? And if so, how is this achieved?
I'm ok with using 3rd party libraries, just no .Net
use the little-known WWS - Windows Web Services. This is basically WCF but native code. Its much smaller in size and much faster - MSDN magazine shows some benchmarks (yeah, ok) that say WWS handling SOAP is faster than WCF's Net.TCP. WWS net.tcp calls are several times faster than WCF :)
WWS also runs with a much reduced working set, 500kb vs 4.5mb for the simplest of simple services.
That link has sample code for you.
I think you get this library for free in Windows 7. You can get it for XP as a separate download.
Related
My application it's C++ service. And I need to add API for it. I consider that it will be XML/JSON RPC based API. How should I design a program for reusing existing code base and provide API.
I see following options:
My application will work via RPC layer. Seems that it's bad option due to low performance;
Before starting of service I will fork it and run my application in the first process and RPC server in the second; Seems ok, but how to restart RPC server in this case?
I guess there is a well known pattern for such issues.
Thanks.
If you can use a web server, then the FastCGI concept might be what you're looking for. One of the main duties of FastCGI is to allow you to put on a public API (from the web server) that internally calls the "real" application, in your case the resident C++ service. So all work is done at the web server to create the public API using any technology you wish, and little or no code changes done in your C++ service.
Assume I have simple program (executable compiled from a C program)that provides text information running as Windows XP service. AFAIK Windows service can communicate with any external process running on the same PC but not with remote processes. How can I convert this windows service to SOAP Web service so that it responds to any any SOAP requests from any remote host?
What are the steps for this like what library to use (not .NET) ?
There's no magic library that will do it for you, you have to create a Program yourself and expose a SOAP endpoint with the service functionality.
Windows processes can communicate with other processes if those process offer a way for that communication to happen (inter-process messaging, reading system event queues, etc), so assuming your C program do offers a way for that communication to happen, your new program can feed that program the input, get the text information and return it to the client consuming your web service.
If you don't want to use .NET maybe you can use some other high level language like Java, Ruby or Python than can help you get your service up un running faster, but you have to create a program yourself, there's no magic library to wrap a program in and make it a SOAP web service.
We have to communicate with a C++ component from a Java EE web application and my proposal involved using JMS server to communicate with the C++ component which is located on other machine.
However the developer of the C++ component wants me to open up TCP/IP sockets from the webapplication and communicate over XML. My view is that socket programming in web application is error prone and will not scale well since there is a limited amount of sockets that can be opened up.
Please let me have your architecture/design preference on using JMS vs TCP/IP sockets.
Thank you
Of course it's case by case. But give HTTP a serious chance. It is a good way to cross platform boundaries. It gives you ways to swap out the backend easily and there are many ways to scale it. I've used it from various platforms to hit centralized authentication service written in modern language. I've also done the opposite by putting frontend to a legacy code by turning it into a web server.
The best part about HTTP is that it's a standard protocol, so almost any platform is able to serve it and consume it out of the box. HTTP(S) or TCP takes care of many of the issues like reliability and security.
Our company wants to transform our current user interface to a web client. We are considering to use Microsoft's Silverlight for this, but it will need to communicate with our legacy C++ server application (native C++, not C++/CLI). I am wondering whether it would be feasible to write such an IPC library by hand, our otherwise whether there are ready-made IPC protocols available both as a C++ and a Silverlight library.
Update: I emphasize the programming languages used because they determine which libraries can be used. For example, a library written for .NET's intermediate language cannot be used by a native C++ application.
You can certainly do this -- on my desktop right now, I'm running a C++ server application in one instance of Visual Studio, a Silverlight application in a second instance, and the Silverlight app is talking to the C++ server over sockets. However, there are several significant caveats:
(1) Silverlight will only talk to a small range of ports (4502-4532), so you may need to modify the server (or insert a proxy of some sort) to allow Silverlight to talk to it;
(2) The server has to serve up a socket policy file on port 943; and
(3) You can't easily use traditional higher-level access mechanisms like RPC or what-not. If the C++ server expects a particular protocol, you're going to have to write all the stuff yourself in Silverlight/C#. That's not necessarily rocket science, but if you're not familiar with sockets programming, there's a learning curve. Expect to spend a lot of time dealing with byte[] arrays, Buffer.BlockCopy(), BitConverter.GetBytes(), and what-not.
An alternative would be to wrap the C++ server with a WCF server, and then call the WCF server from Silverlight. WCF is generally a lot slower than sockets, but it's also a lot easier to call in Silverlight.
You can use TCP sockets or WebServices to connect to your application. You will probably need to write a gateway application (one that connects the socket based clients with your C++ server application) for this though.
You have at least 3 ways to do it:
Direct socket communications - lots of C++ libraries around (Winsock, wxWidgets)
Web-services - not that pretty in C++ compared to Java/C# but there are tools like gSoap
Simply use plain old HTTP requests. GET/POST from Silverlight (easy), and send back some XML or JSON data (or XAML) which you build manually in C++ (or there are bound to be C++ libs for this too)
In a normal client/server design, the client can execute functions implemented on the server-side. Is it possible to test a gSOAP server by connecting an extra client to it?
I have not used gSOAP, but from reading the documentation it allows you to write both clients and servers so you can write an test client to test the service.
However if you are planning to offer the service to clients written in .net or java I would recommend that you write the test client in one of these. This way you will know for certain that it is possible to use the service from one of these clients. You might also find that .net or java clients are easier to write if you server is designed in a specific way, your test client will help you find this out.
Sure it is, use SoapUI to generate client connections and data. Its free.
To add to the other comments: testing a gSOAP server can be easily done offline using IO redirect. When you invoke soap_serve() without any sockets set up prior to this call, the server engine will simply accept data from standard input and write data to standard output. This is a great way to hit an offline server implementation hard with XML data patterns for testing before deploying the server online. The gSOAP tool even generates example XML messages that you can use for this purpose.