October 9, 2008
Together with one of the senior developers on my team I gave a speech at the the first Berlin Java conference called Berlin.JAR. The topic was about how to develop applications for the web without a (traditional serverside) web framework. There is a wave towards rich AJAX applications with GUI logic in Javascript. Two forays are SOFEA and SOUI. The speech covered examples of how to design web applications without a web framework with rendering in Javascript and a client side message bus, using REST, Jersey, OpenAJAX, PURE JS and jQuery. My slides in an English version can be found on SlideShare or here.
The really nice thing is that backends can be written - independently - with Ruby, Python, Javascript, Java, Clojure, Scala, Erlang, OCaml or any other language. As integration doesn’t happen on the server but in the browser (late and lazy integration), it’s faster (asynchronous) and easier than on a server.
Thanks for looking.
September 18, 2008
How to generate Json for REST? If you’re suspicious of automatic generation like me?* I’ve created a markup builder which can be used with Json and made a look into the future in my post “The best Markup Builder I could build in Java”:
“Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like.”
* For a discussion on why you might not want to use JAXB and XStream see the comments on “REST: Lean JSON and XML from the same code”
Let’s have a look at this quote again. I didn’t use Groovy but with some interest in Scala - because it might be more maintainable than Java after 5-years project life time as it is more concise but not riddled with the Ruby-problems or unreadable for most as Haskell is - I looked at my JsonBuilder code and tried it with Scala.
I went back to the “Experiments to nicely generation JSON” post and did adapt it to Scala.
@Path("/hello")
class HelloWorldResource {
@GET
@ProduceMime(Array("text/html"))
def hello() = "Hello"
@Path("/world")
@GET
@ProduceMime(Array("text/html"))
def helloWorld = $(
$("id", 128),
$("name", "stephan"),
$("roles", roles.map(r => $("name", r.name))),
$("adress", $(
$("street", "mine!"),
$("city", "Berlin")
))
)
}
The generating code looks the same as in Java, with the possibility to include functions for generating nodes. My Java code did need anonymous inner classes to achieve the same - with more noise and less power. The methods are shorter and the focus lies more on generating the JSON data, not the method boilerplate code. Next will be WebBeans or Guice integration.
Ive struggled with some Scala constructs, the JsonAdapter which implements MessageBodyWriter was a little hard to write, especially:
def writeTo(node:Node, aClass:java.lang.Class[_],
typ:Type,
annotations:Array[Annotation],
mediaType:MediaType,
stringObjectMultivaluedMap:MultivaluedMap[String,Object],
outputStream:OutputStream):Unit = {
val writer = new OutputStreamWriter(outputStream);
writeTo(node, writer)
writer.close()
}
[...]
def isWriteable(dataType:java.lang.Class[_], typ:Type, annotations:Array[Annotation]) = {
classOf[json.Node].isAssignableFrom(dataType);
}
But everything works now and I can move on to adapt and learn how to do it better in Scala.
The migration wasn’t that hard, some problems exists and my Scala code looks more like Java than Scala, but it’s a beginning. One of my fears is to translate between Seqs, Lists, Arrays and Java Lists and Iterators all the time when interfacing with Java libraries. Not sure yet how to fix that, perhaps with some wrappers. Scalaz might help too. We’ll see in my future adventures into Scala.
Thanks for listening.
July 20, 2008
This post was too unscientific and was updated. Jetty is an excellent container and the container of choice whenever I do something with servlets. Ever since we’ve developed SnipSnap some years ago I love Jetty. Glassfish has some very promising features like the admin console and I´m eager to try Glassfish in a project sometimes in the future.
Reading about another story of Rails performance, I grabbed JMeter to benchmark one of my current projects. Not so much as a comparison for Ruby - which managed 320 requests per second - but more as a comparison of Jetty and Glassfish.
The application is a small REST server which reads data from a JDBM storage, transforms it with my own framework to Json and delivers the result with Jersey.
Both servers were started with their default configuration through their maven plugins (wonderful easy to use mvn glassfish:run). Unscientific as it may be, the numbers are:
- around 1000 requests/sec for both containers
Both with 200 threads and 50 requests per thread. Both numbers are great for my MacBookPro and good enough for me. They also are so close to each other so they are not a deciding factor for either Glassfish or Jetty. At the risk of comparing apples to oranges I have no fear of deploying this to a production system and scaling cheap (and even better with E-Tag caching), keeping in mind the requests per second with 25 servers in the Rails example.
Thanks for listening.
Update:: Another Rails application which thinks it did scale - at least with Merb, to 650k page views per day, well that’s “650K hits per day is ‘only’ around 8 per second (assumed a 20 hour day to spike it a little). This doesnt actual seem all that much?”.
The JMeter speed and 1000req/sec (for an admittantly simple REST GET) results in … 86.4M requests per day. Uh. On my MacBookPro.
April 4, 2008
Generating JSON and XML with the same code is difficult. One can create the semantically richer XML and convert it to JSON, but JSON notations for XML like Badgerfish look quite ugly to JSON advocates.
The problem at the core is that XML is typed whereas JSON is not. Every node in XML needs a type - it’s name - for example <item><id>123</id><item>. JSON doesn’t need such a type, { id: 123 } is fine for an item. { item: {id: 123}} looks too verbose. Especially getting to the data in Javascript: var id = item.item.id. The same goes for accessing arrays with var id = items[0].item.id; instead of var id = items[0].id;. The problem exists with other dynamic languages and data structures too, see Cobra vs. Mongoose for Ruby.
As I currently develop a REST based Jersey application in Java I needed a way to generate lean JSON and XML. Wouldn’t it be best to have one code for both? DRY. My previous solution for generation JSON worked fine. The $(...) method calls create a node tree with nodes and lists. With a JsonRenderer and the Visitor pattern I generate JSON from the node tree. The problem was that this Java code
$(
$("id", listId),
$("items",
...
)
);
creates nice JSON like { id: 123, items: [ ... ] }, but was unable to generate XML. As written above, the outer list has no type and a XmlRender therefor cannot render <shoppinglist><id>123</id>...</shoppinglist>.
The solution I thought about is to add type information to nodes which have no names.
$( type("shoppinglist"),
$("id", listId),
$("items",
...
)
);
The implementation uses a simple static method and a Type class.
public static Type type(String name) {
return new Type(name);
}
The type is attached to the node and if the node has no name but a type, the XmlRender uses the type instead of the name. The JsonRender doesn’t use the type information and renders the same JSON as before. The piece of Java code now generates XML
<shoppinglist>
<id>123</id>
<items>
<item><id>234</id><price></price><shop></shop>
<description>Apple</description></item>
<item><id>233</id><price></price><shop></shop>
<description>Banana</description></item>
</items>
</shoppinglist>
and lean JSON where neither shoppinglist nor item has a type
{ id: "123", items: [ { id: 234, price: "", shop: "", description: "Apple"}, { id: 233, price: "", shop: "", description: "Banana"} ]}
Next thing is to automatically apply the right renderer, toXml and toJson from within Jersey. The content negotiation then choses the accepted format for the client. Attributes (Meta-Information?) are not solved yet and I’m not sure if they are needed, or how to nicely add meta information to the $(...) tree. There is some discussion in the context of markup builders and attributes on James blog.
Probably the code will be released as an open source RESTkit if someone is interested.
Thanks for listening.
March 22, 2008
UTF-8 is always a problem. Unbelievable. 2008 and we still haven’t fixed this. One of my current projects is a Javascript frontend with a REST backend. The backend stores to MySQL (a famous UTF-8 trouble maker) and creates JSON to REST calls. The problems starts with UTF-8 characters. Somewhere in the callchain - as always - characters don’t get correctly written. MySQL and the JDBC driver should work, the JSP page is UTF-8 (@page and meta-equiv), jQuery - which does the AJAX - and JS do know UTF-8 and Jersey should be UTF-8 too. But with some experiments now I’m quite sure that Jersey (JSR 311 REST framework) is to blame. I’m not sure how to specify UTF-8, this
@ProduceMime("text/plain;charset=UTF-8")
doesn’t help. Funny, every major project with several frameworks along the call chain and several languages (JS, C, Java) makes UTF-8 problems somehow. I’m so fed up with this, it’s 2008.
Update: Jersey uses InputStreams for all encodings, especially StringProvider is relevant to me (se above). Does this work with Unicode?
March 18, 2008
I’ve been experimenting with ways to nicely generate JSON. There are many ways to generate JSON in Java, like XStream with Jettison, with JAXB or directly with REST API implementation Jersey. Often you don’t want to serialize objects or work mith maps though. Taking code from “The best Markup Builder I could build in Java” I’ve tried a builder approach.
@GET
@ProduceMime("application/json")
public String getList() {
ShoppingList list = service.getList("123");
return toJson(
$("items",
new List<ShoppingItem>(list) {
protected Node item(ShoppingItem shoppingItem) {
return $("description", shoppingItem.getDescription());
}
})
);
}
The generated JSON would be
{ items: [ { description: "Apple"}, { description: "Orange"} ]}
To create nodes for a JSON tree I first tried a node function. But having lots of node calls makes the code quite unreadable. Luckily Java allows $ as a method name. Using $ makes the code much more readable. The List object creates a list of nodes, taking input from a collection, Iterable or Iterator and calling item() for every element.
To reuse generation code one can create semantic methods like an items method:
public static Node items(Node... nodes) {
return $("items", nodes);
}
The nice thing is, with another render mechanism the tree of nodes can also be rendered to XML with a toXml() method, if XML works better for some REST calls. Next thing to add is support for XStream and Jettison to mix serialization in e.g. $("employee", employeePOJO); and experiment on how to make the code even nicer and shorter.
I also wonder how to remove the toJson() call with Jersey and to use a Jersey writer. Any ideas?
Thanks for listening.
February 25, 2008
Base64 in XML? Multi-mime? See the question, add a comment if you have an answer, the Google results are not very satisfying. Someone clearly solved the problem. But all REST discussions I’ve found do not adress the problem. Even the “RESTful Web Services” bible is mostly silent on the topic (And I don’t want to declare the binary object a resource and PUT binary data into it).
While playing with Web Beans I thought it would be nice to add Web Beans support to Jersey. Jersey is a JSR 311 implementation for RESTful web services in Java. Though it has taken some flak, I - and others - think it’s easy to use. Because it’s easy in Jersey to control the creation of objects by writing your own servlet with a Jersey ComponentProvider, I finished a quick hack in no time. Some help was the integration examples for Spring.
public class WebbeansJerseyServlet extends ServletContainer {
private static class WebbeansComponentProvider
implements ComponentProvider {
private WebBeansContainer webBeans = WebBeansContainer.create();
public Object getInstance(ComponentProvider.Scope scope, Class c)
throws InstantiationException, IllegalAccessException {
return webBeans.getObject(c);
}
public Object getInstance(Scope scope, Constructor contructor,
Object[] parameters)
throws InstantiationException, IllegalArgumentException,
IllegalAccessException, InvocationTargetException {
return null;
}
public void inject(Object instance) { }
}
protected void initiate(ResourceConfig rc, WebApplication wa) {
wa.initiate(rc, new WebbeansComponentProvider());
}
}
Having defined this servlet, a REST resource example for the UuidService from my last post about Web Beans, looks like this
@Path("/uuid")
public class UuidResource {
@Named("uuid")
UUIDService service;
public UuidResource() {
}
@GET
@ProduceMime("text/plain")
public String getUuuid() {
return service.getValue();
}
}
Works like a charm. The UUIDService is injected through Web Beans and the scopes from Web Beans, @RequestScope and @SessionScope seem to work. This takes a big burden from the developer.
I hope to implement a SOFEA web application with Javascript parts which communicate with the backend via REST. For performance reasons it would be nice to populate and render the Javascript on the server. Therefore I would wish I could resolve REST calls to Jersey internally like
jersey.get("/helloworld/3");
to pre-populate pages with REST calls in them.
Thanks for listening.
Update:The Jersey lead wrote about a Jersey client API which perhaps does what I want. Splendid.
