I'm using GWT-RPC to get the client data and my requirement is to parse the payload to retrieve the data inside. I need to log or persist this data for metrics/monitoring purpose.
I'm using the Servlet Filter to intercept the HTTP requests. I can see that the request looks something like this -
5|0|7|http://localhost:8080/testproject|
29F4EA1240F157649C12466F01F46F60|com.test.client.GreetingService|
greetServer|java.lang.String|myInput1|myInput2|1|2|3|4|2|5|5|6|7|
Is there any standard mechanism to parse this data? I'm afraid writing my own code to parse this is not a good solution as this request payload is going to be complex when we pass custom objects to/from RPC and GWT-RPC internal parsing mechanism could change in future, which can break my code. I came across this, but not sure if it is robust/maintained.
Is there any alternative? Any pointers will be appreciated.
Use the RPC class from GWT.
You'll have to provide the serialization policy, whose strong name is passed in a request header.
Decoding responses is harder. You can use com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.ResponseReader along with a com.google.gwt.user.client.rpc.impl.ClientSerializationStreamReader but you'll need to have the JsParser from gwt-dev.jar in the classpath; and you cannot have gwt-dev.jar in a web application as it contains the servlet API (among others); so you'll have to extract the relevant classes from gwt-dev.jar to use them in your web app.
Note that in both cases, you'll reconstruct the same objects as will be deserialized for processing the request "for real", or were serialized as the result of the request processing.
All-in-all, you'll probably have better luck and better performances with using AOP on the methods of your RemoteServiceServlets.
I'm not sure, if that is what you're looking for, but a standard way to log the parsed parameters would be to override AbstractRemoteServiceServlet's onAfterRequestDeserialized(RPCRequest rpcRequest): RPCRequest contains the service method, with all its parameter values, the parsed RpcToken etc. in the form of nice Java objects.
Related
I'm writing a JAX-RS API, and am using the Response class as the return type of each method. However, I'm trying to figure out the "best" approach to validate parameters.
I've written some REST APIs before, and would usually have custom validation routines in the method and then have a custom return object with validation messages in it. I'm thinking I want to do the same here, but is that "preferred"?
I know there are annotations like #NotNull, etc. that you can apply and provide custom validation messages, but I don't really like the way that ends up looking.
So, what I did is that I wrote a return object bean that I'm using as the .entity() for my JAX-RS response, and I'm putting all of my validation messages in there. I use the same return object for Successes and Failures, but it's just a matter of which parameters I populate in there depending on the scenario. This is an internal API, so there won't be any external consumers. I just wanted to standardize the return type so it always returns the same "object".
Does that sound like a good approach? I'm a little rusty on REST API best practices, and I've been googling around like crazy but haven't really come to any best practices conclusions.
Input validation for RestAPI is not straight forward. There are a lot of internet resources, but none covers an elegant way of doing this.
As you mentioned the trivial input validations can be done using the annotation of different implementations of jax-rs library.
These annotations can be sophisticated as regex is supported. Which will help you cover more validation cases than #NotNull, #size , etc.
Theses annotations also accept message as input, which will help you customize a message that has to be returned to a user.
Those annotations may not look sexy (specially when regex is involved); but I would still prefer it over writing my own validator.
The other concern of validation which is a little bit tricky is when you want to validate constraints (more like a logic),
say for example you have this requirement: if parameter A has value X, Parameter B must have not be empty, otherwise it is OK to have parameter B empty.
This is not something you could handle using the usual javax.validation.constraints.*. I didn't find a good library that could handle this.
take a look at
javax.validation.ConstraintViolation
you could write your own custom validation logic that will be called whenever the library intercepts call to your API.
I do want to build a generic gateway from a nested map (generated from binary data stream) to SOAP- clients.
Background: a non-java-application which needs to call SOAP-Services can't generate json or SOAP/XML, but easily generate a custom protocol (which is under our control).
So a proxy is needed. That proxy should not be rewritten on every change of the WSDL or rollout of the next Webservice.
My plan is:
to have url, port and service-name (url:port/service-name) as "strict" defined parameters of that proxy,
to have the SOAP Action as a "strict" defined parameter
to request (possibly cached) the wsdl of url:port/service-name?wsdl and initiate the stub-call dynamically (cached),
to fill the values, which are present in the nested map, to that stub
call the SOAP-Service
convert the answer back to that binary protocol.
If some necessary values are missing it should send the equivalent of a SOAP-Error.
All that of course with small (affordable) latency, high stability, absolute minimal deployment downtime (for updates) and quite some load.
I see several possibilities:
a) Using a ESB like WSO2ESB. There I would implement the stream format as a special input format adapter, convert it to internal XMLStream (at least the json-adapters seem to work that way) and send it to mediator. That mediator would try something like in
http://today.java.net/pub/a/today/2006/12/13/invoking-web-services-using-apache-axis2.html "Creating a Dynamic Client" and call the SOAP-Service directly.
b) using a MOM-Middleware like ApacheMQ with Camel,
c) reduce it to something like Apache Karaf and CXF
I'm a bit lost between all those possibilities, and those are just more or less arbitrary samples of each kind.
Thoughts to a):
minus: It feels a bit odd to have no ESB-Target, since the mediator would directly call the given SOAP-Requests
minus: I wonder if internally converting into XML-Stream would not cost extra time and resources
minus: changing the code needs restart of the WSO2ESB as far as I got it
plus: instead of url, port, service-name I could define symbolic names which are resolved using the ESB -- iff that doesn't take extra milliseconds.
For b) I have not yet checked how easily those format conversions are in Camel and if SOAP-Service-Requests fit into Message Sending and Queueing.
I did already some searches to that topic but it's really confusing because of the overlapping scopes of quite different products. I thought it to be a standard problem but apparently there are no obvious solutions - at least I didn't find them.
I do hope to get a clue which of those solutions could lead into trouble or much work (and which into easy success), and I hope that there is some reason in my approach.
Thanks for any qualified comments!
Marco
I'm looking at implementing a JSON-RPC based web service in Scala using finagle. I'm trying to work out how best to structure the RPC invocation code (ie. taking the deserialized request and invoking the appropriate method).
The service needs to be able to spit out a help page on all the possible requests accepted and their parameters. In Java, I would simply use annotations (to both expose and document functions) and then have the RPC service reflect on the appropriate classes, detect all exposed methods and then use the reflected MethodInfo's to invoke the functions where appropriate.
What is the idiomatic Scala way to achieve something similar? Should I use a message-passing approach (ie. just pass a request object into an actor, have it determine if it can invoke it, etc.)
We had success doing something similar to the approach suggested by #Jan above. More specifically, we defined a parent class for all request objects which takes the expected return type as a type parameter. Going one step further, we're generating our protocol IDL and serialization bindings by reflecting on API objects (little more than sets of requests).
In the future, the experimental typed channels feature in Akka may help with some of the mechanics.
which one best for iphone application ? JSON is different from these three webservice methods ?
could you please suggest me..
JSON is just a serialization format, whereas SOAP and XML-RPC are more like request-response exchange protocols. This basically allows you to invoke remote methods.
In other words, you cannot really compare these. If you're building RESTful applications, serialization to JSON (or plain old XML, for that matter) should be just fine. And please for all good there is in the world (this is subjective, inflammatory and argumentative) do not use either SOAP or WS-* unless it's absolutely neccessary.
Agreeing with Anton, JSON is a serialization format (like XML or CSV). JSON is typically lighter weight than XML, but there are some data structures that don't lend themselves to JSON serialization.
If you're using a RESTful interface you can, but not recommended, alternate between JSON and XML depending upon the service call. I've found using XML for the serialization method to fit nicely into the iPhone SDK since it provides native XML stream parsing in NSXMLParser.
JSON could be one of the formats a REST request gets its answer into.
JSON, being directly parsable in a browser environment, is the best format to communicate in a web application heavily interactive. REST is a way to define a clever GET or POST request to a server than can reply in various formats: xml, plain text, json.
For a web app or an iPhone app, I'd go with it.
It needs the less libraries (or none at all) goes well with async http requests, has the smallest overhead and doesn't go great lengths like SOAP and XML-RPC resolving problems web apps usually DO NOT have: strong typing, mainly.
Hessian is much better communication protocol than XML and/or JSON. Being a binary format it is even more compact, and with a strict format parsing is much faster. And it also consumes much less memory. As a bonus a simpler parser also means your application is more secure.
As a bonus there are already frameworks for Java, .NET and PHP to expose a web service. Truly easy. Asume you have this Java interface:
public interface Test {
public String getGreeting();
int addNumbers(int a, int b);
}
Then implementing it on the server using Hessian is a snap:
public class TestSevlet extends HessianServlet implements Test {
public String getGreeting() { return "Hello World!"; }
public int addNumbers(int a, int b) { return a + b; }
}
The server can also with just as easily be implemented in .NET or PHP for example. There are numerous of Hessian implementations available.
On the iPhone side the Java interface need to be translated into an Objective-C protocol:
#protocol Test
-(NSString*)getGreeting;
-(int)addNumbers:(int)a :(int)b;
#end
And then using [HessianKit][2] for getting a proxy for the service is almost as easy:
id<Test> proxy = [CWHessianConnection proxyWithURL:serviceURL
protocol:#protocol(Test)];
NSLog(#"Greeting: %#", [proxy getGreeting]);
NSLog(#"The answer: %d", [proxy addNumbers:40 :2]);
In this short answer the method names are not quite Obj-C-ish. This is because by default HessianKit uses Java's naming conventions. This can be overriden in HessianKit by providing method, and type name translations. So that both the Java and the Obj-C sides on the connection feels 100% at home. For example:
[CWHessianArchiver setClassName:#"com.mycompany.Test"
forProtocol:#protocol(CWTest)];
[CWHessianArchiver setMethodName:#"AddNumbers"
forSelector:#selector(addInt:toInt:)];
I'm developing a new application for the company.
The application have to exchange data from and to iPhone.
Company server side uses .NET framework.
For example: the class "Customer" (Name, Address etc..) for a specific CustomerNumber should be first downloaded from server to iphone, stored locally and then uploaded back to apply changes (and make them available to other people). Concurrency should not be a problem (at least at this time...)
In any case I have to develop both the server side (webservice or whatever) and the iPhone app.
I'm free to identify the best way to do that (this is the application "number ONE" so it will become the "standard" for the future).
So, what do you suggest me ?
Use SOAP web services (XML parsing etc..) or user JSON ? (it seems lighter...)
Is it clear to me how to "upload" data using SOAP (very long to code the xml soap envelope ... I would avoid) but how can I do the same using JSON ?
The application needs to use date values (for example: last_visit_date etc..) what about date in Json ?
JSON has several advantages over XML. Its a lot smaller and less bloated, so you will be passing much less data over the network - which in the case of a mobile device will make a considerable difference.
Its also easier to use in javascript code as you can simply pass the data packet directly into a javascript array without any parsing, extracting and converting, so it is much less CPU intensive too.
To code with it, instead of an XML library, you will want a JSON library. Dates are handled as you would with XML - encode them to a standard, then let the library recognise them. (eg here's a library with a sample with dates in it)
Here's a primer.
Ah, the big question: JSON or XML?
In general, I would prefer XML only when I need to pass around a lot of text, since XML excels at wrapping and marking up text.
When passing around small data objects, where the only strings are small (ids, dates, etc.), I would tend to use JSON, as it is smaller, easier to parse, and more readable.
Also, note that even if you choose XML, that does not by any means mean you need to use SOAP. SOAP is a very heavy-weight protocol, designed for interoperability between partners. As you control both the client and server here, it doesn't necessarily make sense.
Consider how you'd be consuming the results on the iPhone. What mechansim would you use to read the web service response? NSXMLParser?
How you consume the data would have the biggest impact on how your serve it.
Are JSON and SOAP your only options? What about RESTful services?
Take a look at some big players on the web that have public APIs that are accessible by iPhone clients:
Twitter API
FriendFeed API
Also, review the following related articles:
How to parse nested JSON on iPhone
RESTful WCF service that can still use SOAP
Performance of REST vs SOAP
JSON has following advantages:
it can encode boolean and numeric values ... in XML everything is a string
it has much clearer semantics ... in json you have {"key":"someValue"}, in XML you can have <data><key>someValue</key></data> or <data key="someValue" /> ... any XML node must have a name ... this does not always make sense ... and children may either represent properties of an object, or children, which when occuring multiple times actually represent an array ... to really understand the object structure of an XML message, you need its corresponding schema ... in JSON, you need the JSON only ...
smaller and thus uses less bandwidth and memory during parsing/generation ...
apart from that, i see NO difference between XML and JSON ... i mean, this is so interchangable ... you can use JSON to capture the semantics of SOAP, if you want to ...
it's just that SOAP is so bloated ... if you do want to use SOAP, use a library and generators for that ... it's neither fun nor interesting to build it all by hand ...
using XML RPC or JSON RPC should work faster ... it is more lightweight, and you use JSON or XML at will ... but when creating client<->server apps, a very important thing in my eyes, is to abstract the transport layer on both sides ... your whole business logic etc. should in no way depend on more than a tiny interface, when it comes to communication, and then you can plug in protocols into your app, as needed ...
There are more options than just SOAP vs JSON. You can do a REST-based protocol (Representational State Transfer) using XML. I think it's easier use than SOAP and you get a much nicer XSD (that you design.) It's rather easy for almost any client to access such services.
On the other hand, JSON parsers are available for almost any language and make it really easy to call from JavaScript if you'll use them via AJAX.
However, SOAP can be rather powerful with tons of standardized extensions that support enterprise features.
You could also use Hessian using HessianKit on the iPhone side, and HessianC# on the server side.
The big bonuses are:
1. Hessian in a binary serialization protocol, so smaller data payloads, good for 3G and GSM.
2. You do not need to worry about format in either end, transport is automated with proxies.
So on the server side you just define an C# interface, such as:
public interface IFruitService {
int FruitCount();
string GetFruit(int index);
}
Then you just subclass CHessianHandler and implement the IFruitService, and your web service is done.
On the iPhone just write the corresponding Objective-C protocol:
#protocol IFruitService
-(int)FruitCount;
-(NSString*)GetFruit:(int)index;
#end
That can then be access by proxy by a single line of code:
id<IFruitService> fruitService = [CWHessianConnection proxyWithURL:serviceURL
protocol:#protocol(IFruitService)];
Links:
HessianKit : hessiankit
I would certainly go with JSON, as others already noted - it's faster and data size is smaller. You can also use a data modelling framework like JSONModel to validate the JSON structure, and to autoconvert JSON objects to Obj-C objects.
JSONModel also includes classes for networking and working with APIs - also includes json rpc methods.
Have a look at these links:
http://www.jsonmodel.com - the JSONModel framework
http://json-rpc.org - specification for JSON APIs implementation
http://www.charlesproxy.com - the best tool to debug JSON APIs
http://json-schema.org - tool to define validation schemas for JSON, useful along the way
Short example of using JSONModel:
http://www.touch-code-magazine.com/how-to-make-a-youtube-app-using-mgbox-and-jsonmodel/
Hope these are useful