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)
Related
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.
Our team is in the design phase of a client-server database software project. We're intending to develop a single database server system, probably using MySQL with a database interface/abstraction layer, possibly written in Java. We will also (eventually) have multiple client programs talking to the server. So the question is, what do we use for communication between the server and what could end up being several totally different clients? (Think Android, iPhone, desktop, or even a Web server, forwarding to a browser.)
The two main camps right now are arguing between using:
1. completely custom socket software, because it should allow system independence,
2. exposing a Web service of some kind, because it would provide higher-level functionality
Any ideas? I know "Web service" and "Web API" are very general terms that sort of evoke nauseating buzzword-crazy five-year-old tech media, but they are definitely a valid option. Right?
Plain socket APIs have the advantage of working anywhere. The disadvantage is that they're hard to do right.
Since it sounds like you're going to end up with a database-like API over the network, you should at least consider oData.
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.
I'm working on a project of which a large part is server side software. I started programming in C++ using the sockets library. But, one of my partners suggested that we use a standard server like IIS, Apache or nginx.
Which one is better to do, in the long run? When I program it in C++, I have direct access to the raw requests where as in the case of using standard servers I need to use a scripting language to handle the requests. In any case, which one is the better option and why?
Also, when it comes to security for things like DDOS attacks etc., do the standard servers already have protection? If I would want to implement it in my socket server, what is the best way?
"Server side software" could mean lots of different things, for example this could be a trivial app which "echoes" everything back on a specific port, to a telnet/ftp server to a webserver running lots of "services".
So where in this gamut of possibilities does your particular application lie? Without further information, it's difficult to make any suggestions, but let's see..
Web Services, i.e. your "server side" requirement is to handle individual requests and respond having done some set of business logic. Typically communication is via SOAP/XML, and this is ideal if you bave web based clients (though nothing prevents your from accessing these services via standalone clients). Typially you host these on web servers as you mentioned, and often they are easiest written in Java (I've yet to come across one that needed to be written in C++!)
Simple web site - slightly different to the above, respods to HTML get/post requests and serves up static or dymanic content (I'm guessing this is not what you're after!)
Standalone server which responds to something specific, here you'd have to implement your own "messaging"/protocols etc. and the server will carry out a specific function on incoming request and potentially send responses back. Key thing here is that the server does something specific, and is not a generic container (at which point 1 makes more sense!)
So where does your application lie? If 1/2 use Java or some scripting language (such as Perl/ASP/JSP etc.) If 3, you can certainly use C++, and if you do, use a suitable abstraction, such as boost::asio and Google Protocol buffers, save yourself a lot of headache...
With regards to security, ofcourse bugs and security holes are found all the time, however the good thing with some of these OS projects is that the community will tackle and fix them. Let's just say, you'll be safer using them than your own custom handrolled imlpementation, the likelyhood that you'll be able to address all the issues that they would have encountered in the years they've been around is very small (no disrespect to your abilities!)
EDIT: now that there's a little more info, here is one possible approach (this is what I've done in the past, and I've jused Java most of the way..)
The client facing server should be something reliable, esp. if it's over the internet, here I would use a proven product, something like Apache is good or IIS (depends on which technologies you have available). IMHO, I would go for jBoss AS - really powerful and easily customisable piece of kit, and integrates really nicely with lots of different things (all Java ofcourse!) You could then have a simple bit of Java which can then delegate to your actual Server processes that do the work..
For the Server procesess you can use C++ if that's what you are comfortable with
There is one key bit which I left out, and this is how 1 & 2 talk to each other. This is where you should look at an open source messaging product (even more higher level than asio or protocol buffers), and here I would look at something like Zero MQ, or Red Hat Messaging (both are MQ messaging protocols), the great advantage of this type of "messaging bus" is that there is no tight coupling between your servers, with your own handrolled implementation, you'll be doing lots of boilerplate to get the interaction to work just right, with something like MQ, you'll have multiplatform communication without having to get into the details... You wil save yourself a lot of time and bother if you elect to use something like that.. (btw. there are other messaging products out there, and some are easier to use - such as Tibco RV or EMS etc, however they are commercial products and licenses will cost a lot of money!)
With a messaging solution your servers become trivial as they simply handle incoming messagins and send messages back out again, and you can focus on the business logic...
my two pennies... :)
If you opt for 1st solution in Nim's list (web services) I would suggest you to have a look at WSO's web services framework for C++ , Axis CPP and Axis2/C web services framework (if you are not restricted to C++). Web Services might be the best solution for your requirement as you can quickly build them and use either as processing or proxy modules on the server side of your system.
I am developing a client/server application for which I am evaluating a few options for the communications layer.
As part of this communication framework, I am contemplating using google's protocol buffer (PB) for representation of the transport data instead of re-inventing my own binary structure.
Now coming on to the actual transport, I am wondering if one should use plain sockets to send/receive these binary messages or use some form of middleware. Using a middleware has certain obvious advantages over sockets. A few that I care about include: communication models - publish/subscribe, request/response and fail over.
On the other hand, using sockets has the advantage of low overhead compared to the middleware approach and will deliver better performance.
One can also think of using the RPC libraries available with protocol buffers (third party add-ons on google's protocol buffer wiki) to communicate between the client and the server. Though it abstracts from the low level socket, it still does not support the middleware features.
At the moment, my client is an Adobe Flex GUI and two server side processes (One java and another C++). In the future, the client and server side can potentially have other services developed in other languages as well such as .NET
What do the experts feel about these choices and from experience what works well without compromising on performance. Are there other alternatives that developers go with?
Thanks
Dece
Unless it's a learning exercise, you absolutely, positively must use some middleware. There are lots of choices: AMQP, ZeroMQ, XMPP, Comet/Bayeux.
For your scenario, you probably want something web-based, so XMPP over HTTP may be a good option. However, I'm partial to Comet (though I have found Bayeux to be too complex for my needs).
Which platform?
If Windows then I have a free, simple, high performance, IO completion based pluggable server platform called WASP which is available from here.
Simply write a DLL or two and plug them in and you're done with the networking.
I don't currently have a protocol buffers based plugin example but it's on my list of things to do...