RESTful Webservices on Google App Engine - web-services

First of all I need to say that I'm not so experienced in Google App Engine.
I know that it is possible that we deploy RESTful Web-services (JERSEY) on GAE
And also I know that RESTLET has a version specifically for GAE.
I want to take advice from those who have worked with both approaches that which one is better.
For example is configuring the GAE application for JERSEY too difficult or struggling???
Or for example has using RESTLET any disadvantages? Or is it too thick (RESTLET)?
Thanks

I have tried Restlet and was not satisfied with it: it tries to do to much and is not JAX-RS at it's core (they have it as an add-on). I had problems make it work in various settings (request would not be routed to the method, but when only changing method order it would start working. WTF?!). Also their documentation is scarce and inconsistent.
I took a look at Jersey: there were some problems with running on GAE at that time (resolved via help on support forum). Also I found their docs to not be that good.
Finally, I went with Resteasy/Jackson: docs are superb, works with Maven out of the box, full control over config, security and error handling (exceptions thrown in code returned as JSON error object). Basically no issues. You can look at an example here: LeanEngine REST classes.
Also, if used with JSON/Jackson (make sure to force Jackson 1.9, as built in 1.7 is old) you get a lot of control over how your classes are mapped to JSON: one-to-one, wrapping/embedding, adapter-pattern, etc..

I've been using Restlet on GAE for about 6 months. I chose it in part because they also have editions for Android and GWT, which are also part of my product mix, and I thought it would be simplest to go with the same thing everywhere.
In contrast to Peter K's comment, I found the documentation to be pretty good. In addition to the online documentation at restlet.org, there is a 400-page ebook (Restlet in Action) available from Manning that goes quite in-depth. Possibly the ebook came out subsequent to Peter's evaluation.
That being said, it's a pretty big library with a lot of features, which is a double-edged sword. One the one hand, every time I want to solve a new kind of problem, it seems like Restlet already has something built-in to make it easier. On the other hand, I find it to be challenging to debug through the Restlet source when I'm trying to figure out a problem -- all that flexibility and functionality adds up to a broad and deep class hierarchy, and it's hard sometimes to see how the pieces fit together. If you're building a substantial app, I think it's worth a look, because I don't think you'll run into many limitations with Restlet. However, I haven't used RestEasy, so I can't make an informed comparison to it.

I started one year ago to develop an app with Jersey and Google App Engine. Great experience from my side, but I have never worked with Restlet ..
I try here to summarize the main difficulties I found in GAE integration:
Jersey version: 1.6 works
I suggest you to use Jackson (version 1.7.1) for json representation
web.xml fragment:
<servlet>
<servlet-name>jersey</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>***package-with-your-classes***;org.codehaus.jackson.jaxrs</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Configurator:
#Provider
public class JAXBContextResolver implements ContextResolver<JAXBContext> {
private AnnoxAnnotationReader annotationReader;
private JAXBContext context;
private Class<?>[] classTypes = new Class[] { .. all your classes .. };
public JAXBContextResolver() {
annotationReader = new AnnoxAnnotationReader();
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(JAXBRIContext.ANNOTATION_READER, annotationReader);
try {
this.context = JAXBContext.newInstance(classTypes, properties);
} catch (JAXBException e) {
..
}
public JAXBContext getContext(Class<?> objectType) {
return context;
}
.. as you can see I use Annox to avoid annotations inside my model classes!
Hope it helps!
Michele Orsi

Related

Migration from oc4j to tomEE

We are planning to migrate our Java WebApplications from OC4J to TomEE.
I need to provide an LOE for this migration
What are the key points regarding the migration?
Is there any documentation or books that I can refer to ??
First, congratulations. The lightweight nature of TomEE offers some incredible advantages. Being open source, you're also able to fix bugs on your own, without relying on your vendors slow development cycle. Plus, because it's basically Tomcat, you're tapping into a massive knowledge base and world of experience around the product.
The best advice for a migration like this is to make sure your apps use vanilla Java EE and nothing else. If your code compiles against javaee-api-6.0.jar without any OC4J libraries, chances are you're 90% the way there.
The rest of the problems usually deal with minor points on configuration and injection.
If you do strange things with EJB mappings:
#EJB(name = "NoteTakerServiceBean")
private NoteTakerService umaNoteTakerService;
#EJB(name = "GLINoteTakerServiceBean")
private NoteTakerService gliNoteTakerService;
These "named" injections are not portable.
Configuration properties on MDBs:
#MessageDriven(activationConfig = {
#ActivationConfigProperty(propertyName = "destination",
propertyValue = "com.mycompany.databunker.salesforce.model.SalesForceAgent"),
#ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "1") },
mappedName = "com.mycompany.databunker.salesforce.model.SalesForceAgent")
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public class SalesForceAgentMessageListener implements MessageListener {
....
}
The activationConfig properties are container specific.
To assist you with the migration, TomEE has the best documentation out there. See these two pages to see how to see where I got the configuration details for the above beans.
http://tomee.apache.org/examples-trunk/index.html
http://tomee.apache.org/documentation.html
Finally, another great resource is the Apache TomEE users list. There are many helpful people on there. Good luck, be sure to post there or back on SO if you have further questions!

Choosing a good asynchronous solution for Django projects

I'm currently using Django served on Apache (mod_wsgi) for developing my apps. One of my favorite things is to 'fake' async requests with JavaScript's setInterval() function and AJAX to retrieve new data from database. For example:
// javascript
function someFunction() {
// do some stuff
setInterval(function() { fetchNewStuff() }, 1000); // run fetchNewStuff() every second
}
function fetchNewStuff() {
Dajaxice.main.fetch_new_stuff(fetch_new_stuff_callback, {'id':$(this).attr('user_id')});
}
function fetch_new_stuff_callback(data){
// append new stuff to my table, list or whatever in HTML page
}
As far as I am aware, this is perfectly fine for my needs. However, as my apps are growing bigger and more complex, this will eventually become too much hassle for both, my server and my clients, no matter how much I try to minimize transported data. Also, I cannot settle with the thing that in today's world I'm still 'faking' this :) So, I'd like to find some 'real' solution with push capabilities for my current and future projects.
I did try to google my problem and I have found many interesting stuff (Tornado, Nginx, Node.js, Twisted, etc.) but most of tutorials/articles/blogs are at least 6 months old and I believe that many things changed in that time. So far, I have tried to test Tornado and it was successful test, but I had some problems with setting it up on my production server. I also tried Node.js which is extremely simple since I know JavaScript very good, but then again, I'm not sure if it is a good solution.
My question here is - what would be the best thing (server, platform, framework, whatever) to implement in my current and future apps depending on this conditions:
easy to use (e.g. Node.js could fit in here)
eliminate 3rd party stuff as much as possible (some out-of-the-box solution, e.g. Django+Websockets and that's it [this was really just a silly example])
good documentation in use with Django (it would be perfect to have some real examples with my new technology and Django since I'm pretty much n00b for web servers and related stuff)
has a good perspective and future (I'm really looking to learn something which I will use a lot and which I wouldn't have to re-configure very often)
Thank you for your thoughts and any kind of help about this (links to some good, recently updated readings are more than welcome :)
You should have a look at django-socketio project, a Django app providing the features required to use websockets with Django via Socket.IO.
It uses gevent library along with socket.io.

javax.ejb.Stateless class undefined

I am currently trying to implement a web-service assignment given by my college.
My Assignment is..,
Consider a case where we have two web Services- an airline service and
a travel agent and the travel agent is searching for an airline.
Implement this scenario using Web Services and Data base.
For that as a newbie I tried to follow the steps given in this link.
I opened the Netbeans beta 2, and exactly followed the steps as given in that link.
But while trying the steps,
Deploying and Testing the Web Service, I tried to run the CalculatorWSApplication, I noticed that javax.ejb.Stateless is undefined.
And I have three questions,
I have a basic knowledge of , JSP, HTML, WEBSERVICE. Please give me some basic idea/basic schema of the assignment such that I could proceed with the next steps and implementation.
How could I get rid-off from the missing ejb file.
Generally .java files will refer to the libraries present in jre and why in this program, CalculatorWS.java refers in this path C:\users\MuthuGanapathy\.netbeans\7.0beta2\var\cache\index\s3\java\14\gensrc\javax\
Let me try to answer your questions:
First of all: You don't really need knowledge of JSP and HTML for creating WebServices. If you are interested in additional knowledge rather have a look in subjects like SOAP, WSDL or XML (on which SOAP and WSDL files are based). You can find good informations at w3schools.
As said in your assignments requirement you'll have combine your service with a database, therefore you'll have to face the fact that WebServices aren't able to send every kind of data. For example, if you intend to use some kind of JPA you wont be able to send entities between Client and Server via WebService easily (though its possible).
For the reason of that my approach would be to send simple datatypes between client and server and, on server side, build my complex objects.
This would force me to code at least 3 classes (one for each webservice and one for communication with the database).
Airline WS:
#WebService
public class Airline {
#WebMethod
public String stuffToDo {
// do your stuff
persistOrSelect(complexObject);
return "success";
}
private boolean persistOrSelectData(Object complex) {
// Database stuff here
DBdao.doStuff(complex);
return true;
}
}
TravelAgent WS:
// same structure as shown above
DB class:
public class DBdao {
public static doStuff(Object complex) {
// get DB connection and INSERT, SELECT, UPDATE
}
}
In this scenario you didn't even have to use a class out of the javax.ejb package but I understand that this could be necessary :).
I don't really use Netbeans and therefore I can only speculate. I think that your problems 2.) and 3.) relate to each other.
The javax.* package normally is located in your JDK and should be specified in your IDE inside the server library/target runtime your using.
Do you have assigned the server library to your project?
Have you tried to point your Netbeans installation to your JDK path as shown here and here?
It could also be possible that your project do not have a reference to the Java System library.
Last but not least:
There are several ways for testing your webservice:
You use Netbeans therfore I assume that you deploy your project on an Glassfish server.
After deployment you can navigate to your project inside the admin gui and click the link pointing to view endpoints. In the next window your able to either follow a link pointing to the generated WSDL or to a tester
You can write your own client by either following the tutorial provided or, for a more general approach you can use this.
Use soapUI for testing (it's available as standalone application or as IDE plugin)
I hope this helpes, have Fun!

Microframeworks for Squeak/Pharo web service

Lots of languages have microframeworks for writing very tiny websites or web services, such as Flask for Python, or Sinatra for Ruby. On Squeak, there doesn't seem to be any equivalent; Iliad, Seaside, and AIDA are all very heavy for just having a little service. What's the preferred way to accomplish this? Directly injecting a hanlder into Comanche or Swazoo?
"In this particular case, I literally have three URLs that need to do stuff via HTTP POST; that's it."
For really simple cases, you can just register with (or subclass) Kom's HttpService like so (from the class comment, see for more info/options):
(HttpService on: 8080 named: 'Example Http Service')
onRequestDo: [ :httpRequest | SomeGlobal processRequest: httpRequest ];
start
You can also use teapot. Teapot is micro web framework on top of the Zinc HTTP components, that focuses on simplicity and ease of use. It's under 500 lines of code, not counting the tests.
Teapot on
GET: '/hi' -> 'Bonjour!';
GET: '/hi/<user>' -> [:req | 'Hello ', (req at: #user)];
GET: '/say/hi/*' -> (Send message: #greet: to: greeter);
start.
(ZnEasy get: 'http://localhost:1701/hi/user1') entity string. "Hello user1"
There are available mustache templates, output transformers, before filters. The framework is well documented.
I would like to share what I think is more up-to-date information (as of end of 2012).
Zinc Components
Currently in Pharo 1.4/2.0 the de-facto standard for HTTP client/server seems to be the Zinc HTTP Components. And the latest Seaside version (3.0) switched to Zinc as well.
You can of course use Zinc directly to implement web-services or serve web-pages.
Take a look particularly at classes ZnServer and search for classes like Zn*Delegate (like ZnDefaultServerDelegate or ZnStaticFileServerDelegate)
Seaside REST
Latest versions of Seaside include support for RESTful web-services. This can be used to implement web-services or serve web-pages. It's pretty straightforward.
For more information look at the "REST Services" chapter of the online Seaside book. This chapter centers about implementing web-services, but it works for web-pages as well.
Ratpack
I have also been told about Ratpack, a sinatra-like web-framework developed by Tim Felgentreff. There are two repositories. I think the github one is more recent. See here:
http://ss3.gemstone.com/ss/RatPack.html
https://github.com/timfel/ratpack
This information comes from a similar question I posted recently.
You can subclass a SwazooSite in Swazoo for such a micro website, but I think you will soon end needing more functionality, so starting directly on one of those three frameworks are better bet long-term.
That they are heavy is maybe just an impression and lack of better documentation of usage for such simple websites. Also, if you look at the framework as blackbox, which is complex internally but simple externally, then I'd say all Smalltalk web frameworks are quite simple comparing to other web frameworks.

web services api: to wrap or not to wrap?

When providing a web services API (well, let's say SOAP), do you provide a library wrapper along with it to make it "easier" for people to use? Or do you just package up a WSDL and documentation for it and let people figure out what to do with it?
What are people doing usually? I've seen a bunch of examples where the wrapper is provided, but it has always seemed counter-productive to me.
WSDL is easily discoverable (all functions & types as declared), so there is usually no need to offer any package with it, and minimal documentation (apply an XSL to the WDSL and it's usually enough :) ). My theory about the appearance of libraries/wrappers is that it is directly related to security measures / needed authentication & hashes (usually: concatenating some fields with a secret & hash it), about which one simply doesn't want to answer every single question anymore.
Audience matters I think: if you want you run-of-the-mill hobby coder to be able to use your service, providing a package can get you that much more users. If you're more in business to business services, the webservice usually has to be integrated in some larger package and most libraries would be futile.
That being said, I'd say of the webservices I came across: about 60% of the libraries provided were hopeless spaghetti code fit for the bin, 30% were not the code I'd use, but could clear up some questions not answered by the documentation, and only about 10% were fit enough to integrate in a project (or the project small and/or worse enough to be no worse for it).
How you going to support multiple web-service stacks - JAX-WS, AXIS2, CXF etc? My choice - WSDL/XSD. In practice I got service built with JAX-WS and a client with AXIS2. And I don't want to build a client wich you are going to use. I don't even know your preferable web-service stack and your JVM version limitations. For example, I can call web-service from java 1.4 - there are no annotations and not possible to use client lib built with annotations for java 1.5. So WSDL is right way to build ws-client instead of providing generated client library.