I am looking for GWT to C++ communication solution.
Currently I am trying to figure out how to run WSDL in GWT, but actually, have absolutely no experience in WSDL, and only little in GWT.
So, my question is about feasibility of working with WSDL in GWT (and how?) and other approaches would also be interesting if exist.
I am trying to avoid coding Java on the server and coding JavaScript on client.
GWT Side:
RequestBuilder and com.google.gwt.json.client.JSONObject for quick and really not that dirty marshaling api.
Overlay types require you to know your data configuration at compile time. With JSONObject (and it's JSONValue's), you can treat it like a slightly unwieldy key/value map.
Set your RequestBuilder to POST and serialize your payload by pushing it into a JSONObject and calling toJSON();
C++ side..
Find a favorite JSON library (may I suggest from the fine choices at http://www.json.org/)
(You'll have to build a method dispatching scheme, but if your app is simple, just use some simple if ()'s)
Send back a response with mime-type of text/javascript;charset=UTF-8.
Back in your GWT code, you read back the results using something like so:
if (Response.SC_OK == response.getStatusCode()) {
try {
String txtResponse = response.getText();
if (txtResponse != null && txtResponse.length() > 0) {
JSONObject result = (JSONObject)JSONParser.parse(testResponse);
//Do something useful...
}
} catch (......)
Now you can talk back and forth with no magic. (And goodness know, no WDSL!!!)
Thrift may be the best solution for you. A specific portage for GWT is available at : http://code.google.com/p/thrift-gwt/ .
You can expose a JSON-based API on your server and use GWT's RequestBuilder and JavaScript Overlay Types to consume it in the client.
You could also use an XML-based API, but JSON will be easiest because of overlay types.
I found Thrift is almost the only choice that includes code-generation-based data-binding solution with RPC support that works on C++ side (original Apache Thrift compiler) and GWT side (gwt-rpc-plus solution).
That is a coincidence, but Thrift is actually a good JSON data-binding solution.
The only problem I see with Thrift (and it's rather inconvenience) - it doesn't support structure polymorphism, which is Ok for JavaScript (Thrift supports it), but bad for real object-oriented languages like C++ and Java.
Related
I am building a server-client application that involves heavy signal processing (e.g. FFT). I have a working application written in C++/Qt, where everything (signal processing and other calculations) is done in client and server just sends raw data. Now I feel it would be easier to implement these features on the server. So, that maintenance becomes easier.
As I am doing signal processing, I think I should stick to C++ for performance. But I am open to new ideas.
Constraints:
I need type checking so javascript is out of discussion.
Scaling includes adding more server and each server will have at the max
10-12 users. So, Hardware cost is important. I cannot use x number of
i7 processors.
No option of using cloud services.
So, right now my question is as follows:
How can I create web services using C++ for Linux server? (Although cross platform is not important, I would appreciate if I can achieve it.)
EDIT [02:09:2015]
Right now, I think the choice is between poco and C++ Rest SDK. I feel I should go for C++ Rest SDK. Mainly because it has only those features that I need. And Also it is supported by microsoft and uses boost internally. So, I feel in future, this might be well integreated with standard.
You could use cross-platform Poco library to implement HTTP server, it is really straightforward with this framework, and they have a lot of examples. You can also use JSON serialization (like rapidjson library) to implement REST service on top of HTTP - this way your Web service will be accesable by most of the modern Web frameworks.
You might want to take a look at the C++ Rest SDK, an open source, cross platform API from Microsoft.
Like #nogard suggested, I also recommend POCO for now. It's the most serious and feature-full solution. Given you mentioned Qt, I suggest you to take a look at Tufão.
EDIT:
I forgot to mention one comparison of mine on the C++ HTTP server frameworks.
If you directly handle HTTP requests, you might loose the functionality what Web Servers does well what it was build to do. I had a similar issue, what I did was wrap up my Qt c++ code inside a PHP extension. In your case you can do the same. Wrap your logic inside what ever technology you are about to use, doesn't matter it's PHP, net , Java or anything else.
I have a some web services that my app needs to communicate with by sending json with REST over HTTP POST/GET. The only way I can see to do this is with the iXMLHTTPRequest2 framework but geeze oh man is it uglier than I want to deal with.
Is this the only option I have to look at with c++?
Would this be easier with c#? I know most of the things are the same across the languages, but if c# has a better way to do this, I'd be willing to make the jump.
You should also look into Project Casablanca - it's a fully native C++ library that also is adapted for use with Metro apps (I believe it wraps IXHR2). I've been using it to perform http REST calls and to parse JSON very successfully.
That's the interface you have to use in C++. It is more difficult than in C#. Given that, there is a good sample that will make using that interface a bit more bearable.
I come from the .NET and Java world, and my impression of SOAP is that it always involves lots and lots of generated boilerplate code. Is this a priori necessary? Or have other languages or libraries found a way to do away with this?
With Spring WebServices you can end up with JAXB generated classes (from XSD) only and use your own implementation which just uses these classes as method parameters and endpoint types.
SOAP itself can be seen as cumbersome protocol which requires expensive/heavyweight tools. It can also be seen as a thin wrapper of XML payloads which has great advantage - WSDL as a description language (which can also be seen both as heavy or as ubiquitous) which describes operations and parameters.
Back to Spring Web Services, here's the roadmap:
you have only XSD
you use XJC (or some maven plugin) to generate classes
you write your own endpoint with methods which use these classes as parameters
here's sample endpoint:
#PayloadRoot(localPart = "myMethod", namespace = "http://example.com")
#ResponsePayload
public MyResult myMethod(#RequestPayload MyRequest req)
{
}
I've written many big web services and writing by hand ~50 such methods is much more pleasant and effective then relying on generated code.
I think a lot of the junk is necessary for SOAP, but the RESTFul stuff looks promising.i think the WCF Web API is worth a look as it implements a lot of the standard http stuff, but the WCF dataservices side of things looks cool too (OData?).
http://wcf.codeplex.com/wikipage?title=WCF%20HTTP
http://msdn.microsoft.com/en-us/data/bb931106
hope that helps
In case you want implement or consume simple WEB-services and do not generate tons of DTO objects, validate them etc, you may use groovy-wslite. It is primary intended for use from Groovy, what make it even more easy and attractive, and you off course may use it in just Java application.
Simple example of client WEB-servise consumption:
import wslite.soap.*
def client = new SOAPClient('http://www.holidaywebservice.com/Holidays/US/Dates/USHolidayDates.asmx')
def response = client.send(SOAPAction:'http://www.27seconds.com/Holidays/US/Dates/GetMothersDay') {
body {
GetMothersDay('xmlns':'http://www.27seconds.com/Holidays/US/Dates/') {
year(2011)
}
}
}
assert "2011-05-08T00:00:00" == response.GetMothersDayResponse.GetMothersDayResult.text()
assert 200 == response.httpResponse.statusCode
assert "ASP.NET" == response.httpResponse.headers['X-Powered-By']
I want to call a rest service written in WCF (which can support both XML and JSON Web Message Formats) from my C++ application.
What is the best solution to achieve this ? I have seen some utilities (gsoap) which create proxy classes for you to be used to call web services.
Can I achieve the same functionality without using any intermediate utility ? As its a rest service and it works using GET/PUT functions which are basic HTTP functions, is there any C++ library/Solution which could be used to invoke these function directly from a c++ application ?
On Linux, you probably could use curl library (and I guess it is ported to Windows). Curl is a library providing HTTP client functionality to a C or C++ program.
Use Casablanca. This should be helpful for people looking for this answer in 2013. CURL is perfectly appropriate but if you're doing C++ in Windows and using MS stuff, Casablanca seems fit.
Hope the following articles might be of help to you
1. Accessing an XML Web Service Using C++
2. SOAP client for C++
I tried gsoap myself but it became difficult to maintain cross platform versions of my app.
Instead i went the HTTP request route.
For cross platform and C++ i found this Call Rest Web Services from C++
If XML serialization with your REST approach is really not needed then curl is perfect to use. However, if you want type-safe XML serialization in C or C++ then it would become cumbersome to use curl, since you will have to use something that runs on top of curl to process XML such as with a DOM parser (slow and not type safe). If you have a WSDL, then I recommend gSOAP 2.8 which provides integrated REST and XML serialization capabilities (and JSON when you need it).
okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.
We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.
What is the exception thing a web-service gives over simple http response?
At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.
For simple web services, a servlet is adequate (I'm writing one of these as we speak).
When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.
A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.
Contrast this to something like this from Java EE:
#WebService
public Person getPerson(String personId) {
Person p;
...
return p;
}
The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.
In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.
So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.
It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.
It depends. If your web service needs to answer a simple yes/no question like "does this username exist?", then return yes, no, 0, 1, etc may be enough. If you have one that returns all the faculty attributes, XML or JSON may be appropriate because of the structured nature. It's a little less prone to parsing errors than trying to parse plain text.