Shopper app #5 – server side overview


to the 5th posting about the shopper app.
This time, we will take a little look at the server side implentation of the Restful Services which are running inside the google app engine.
At the time the serverside code is structured into six packages:


The com.berndwarmuith.shopper.jdo.entities package is the place for the JDO entities which are:

Group, Member, Purchase and Item.

Let’s pick out one of these entities, say the Member entity:

It simply contains some fields, which are annotated with the @Persistent annotation to make clear that those fields are going to be persisted in the datastore. The purchases list has a special annotation:
“@Order(extensions = @Extension(key = “list-ordering”, value = “date asc”, vendorName = “datanucleus”))” which tells the datastore to keep the list ordered by the date field of every purchase. This is essential because finally our data will be presented in such an order on the android app. So as we see it is incredibly easy, cause instances of are now just ready for getting persisted to the datastore.

For getting access to an instance of the JDO PersistenceManager I created a simple static class as a singleton which hands out the PersistenceManager instance:

So, to access the PersistenceManager instance one havetomake a call to the static method get();
PersistenceManager pm = PMF.get().getPersistenceManager();

One of the most important package is the package, which contains all the converter-code to construct a XML document out of an Java Object. To do this, I make use of JAXB which works with annotations and isvery easy to use. Let’s take a look at some of the classes in this Package,

This class acts as a “wrapper” for the purchases which were requested via REST. It represents the root element of the XML document and offers aset of another converters, the PurchaseRequestConverter, which represents the XML data of the purchase. Here you can see, that in one converter class JAXB will grab to a set or a list of another converters. All the converters are organized this way, e.g. offers a set of Memberconverters which again gives access to a set of PurchaseConverters and so on. So this is the way how a huge xml file with information about a whole group is going to be constructed.

Let’s take a look at the class which is offered by the PurchaseRequestWrapper above:

This will construct the XML document which will be the most requested one. Every field which is going to represent a XML element is annotated with the @XmlElement annotation. To tell JAXB that it should vonvert a list or a set of elements, I make use of the @XmlElementWrapper annotation.

So this is how a set of purchases in xml form is constructed which will be processed and displayed on the android smartphone.
The XML file, for example, with just one purchase looks like this:

As explained ina previous posting, to tell the shopper-server how much purchases we want to retrieve, we add some parameters to the Rest URI.
http://localhost:8888/rest/purchases/get?group?group1&number=10&page=2 will give us the first ten purchases of group1. By “first ten” I mean the latest ten purchases of a group in timeline, because just these informations are interesting for the user. If the user wants to get more purchases, he can switch to the next page on the android phone, which causes a Rest call to http://localhost:8888/rest/purchases/get?group=group1&number=10&page=2, which provides the next ten  purchases. So this is the way purchases are loaded in  heaps, instead of simply load the huge xml file and send it to the client.

Now let’t take a look at the codesnippet which is responsiblefor receiving new Purchases andpersisting themto the datastore. The responsible code isplaced in the PurchaseResource class.

This code will still change here and there but here is an overview: The method saveNewPurchase() is responsible for receiving new purchases from the android client as a XML document in an inputstream. The @Consumes(“application/xml”) annotation tells JAX-RS that it is a “application/xml” MIME type what is expected here. The method is accessible through http://<host>:8888/rest/purchases/new.
Fist of all we have to make sure that the received XML document is wellformed and valid. For this purpose I wrote a class called DOMValidator which takes the inputstream and validates the xmlfiles against the DTD-files stated at the DOCTYPE of the Xml file. In case of an error the service returns a Responseobject with “text/plain” MIME type to inform the user that there is something wrong with the XML document. If everything is all right it’s time to extract the informations out of the XML document, which happens simply with Java DOM.  Informations like owner, groupname, participants, etc. are cached in local variables for later use. When every informations are extracted it’s just time to make the informations persistent. First the requested group is searched. If no group with the given groupname exists, the server again responses with a Responseobject and the responsestatus 500 indicating that this groupname does not exist. The code will change a little bit in future. For example the whole datastore access will be included in a JDO Transaction to assure that everything is consistent.

There are some other services on the serverside for example, creating new members, creating new groups, requesting all groupinformations, delete a user, delete a purchase, …..They all works similar to this quick overview i gave in this posting. There are JAXB converters  which transforms the objects into Xml documents, which are provided by a Rest-resource. I will finish the serverside stuff in the next few days and make a final posting about it in post #6. :)

What’ next? Finally, the next step is to implement the android client :-) The funny part!



, , , , ,
  • Delicious
  • Facebook
  • Digg
  • Reddit
  • StumbleUpon
  • Twitter

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>