Purchase Management System (Shopper ;-]) , Update

Welcome,
to the fourth post. This posting contains a chunk of modifications and decissions i made in the past days.
First of all i recognized that “Purchase Management System” is a pretty crappy name for this application, so I thought of a new name which should sound simple and easy. Because imo the name isn’t very important i decided just to name it “Shopper“. :-)

Google App Engine

I dived into the GAE concepts and features in the last week and came across several problems and restrictions which i will discuss now.
The Datastore: As discussed in the previous postings all the data of the Shopper app will be persisted at Google Datastore via JDO.
Somehow, my thoughts about this datastore were kinda similar to common relational databases like MySql, Oracle or whatever. This is a big mistake!
My first advice is to thrust aside the whole knowledge one has acquired about relational databases and to keep in mind that the datastore of GAE is NOT a relational database, but a schemaless object datastore with a query engine and atomic transactions.
Secondly, I regret the fact that JDO (and JPA) concerning the gae datastore haven’t actually no support for many-to-many realtions. This does not mean that such relations are not possible to implement. Quite the contrary.
One can model m-to-n relation by holding sets of the other entity in each entity, but the application is self-responsible to update and maintain these sets, and there are more problems when persisting new entities which does not have any keys yet.
Ok. Then i thought about the Shopper app and if it is really such a advantage if the member and group entities are related through a many-to-many relationship. Finally I decided that this is not the case. So I rather keep things clean and decided that these relationship has changed to a (better supported) one-to-many relationship!

RESTful Webservices

There are better words to say about the Jax-RS RestFul libraries. The Jersey specification of Jax-RS is very intuitive to use and made nearly no problems. A few Webservices are just on standby! So lets pick out some services.

Creating new Groups:
This is one of the simple service methods. One have the possibillity to create new (empty) groups by call a Restful service via the URI: http://<host>/rest/groups/new . The user simply has to call this service via the POST method with the desired groupname. The serverside implementation will handle this request and decide if the it can create a new groupentity in the datastore. Groupnames are unique, so if the user wants to create a group with a name that already exists, the Webservice will respond with a error report.

Creating a new Purchase:
This is one of the more complex service. The URI Path for creating new Purchase is: http://<host>/purchases/new.
This is of course again a POST method which consumes the application/xml MIME type.
To give an example the xml content has to look something like this:

purchase xml

To examine if the received xml document is wellformed and valid our webservice validates the receipted xml file against a DTD file:

dtd purchase

If the xml document contains content which violates these rules the server responses with a accordingly error message.
Assigning new Members to existing Groups:
For this purpose the user has to make a simple call to http://<host>/groups/<groupname>/newMember.
This Rest Method will react to POST calls which contains Xml Contents like:

member xml

The content between the <pwd> tags will be of course encrypted with a suitable encryption algorithm.
The Validation of the xml content again happens against a simple DTD-file.

One important service method will be the oppurtunity to call for current purchases of the own group in order to display it on the Android Smartphone. There is one Problem with it.
While more and more purchases are going to be assigned to a group, the xml file is getting bigger and bigger. This can cause performance problems on the Android-Platform so we have to think about a way to keep the size of the xml file small and handy.
My decision is that it would be better to load the xml file in small bunches. Consider the fact that on a common Android smartphone there is highly restricted space for displaying informations. Say there is space for about ten purchase-views on one screen,
it would be sufficient to load just about ten purchases from the server.
The idea is to introdruce a parameterized URI, for example http://<host>/groups/<group>/purchases/purchase?n=10&s=1 where “n” is the number of purchases and “s” is the “page” of the android screen.
For instance n = 10 and s = 1 would give you the 10 latest purchases of the group and n=10 and s=2 would give you the next purchases from 10 to 20… and so on…
This approach is scalable, so one could easily decide how many purchases should be displayed on one screen. (n=15 and s=5 would would provide purchases form 60th to the 75th position…)

I will describe the whole serverside implementation with an overview in my next post.
cheers,
bernd
, , , , , ,
  • 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>