On Fri, Jul 13, 2012 at 12:25 AM, Dulini Atapattu <dulin...@gmail.com>wrote:
> Hi Jean and all, > > The design for the api of message queue component for nuvem is as follows > (The MessageQueueService interface): > > *public QueueMessageHandle sendMessage(QueueMessage queueMessage) throws > MessageQueueServiceException;* > (Sends the queueMessage and returns a handle to the sent message) > > *public List<QueueMessage> receiveMessage(int numMessages) throws > MessageQueueServiceException;* > (Receives the number of messages specified by numMessages from the queue > service and returns a list of queue messages) > > *public boolean deleteMessage(QueueMessage queueMessage) throws > MessageQueueServiceException;* > (Deletes the message specified by the queueMessage and returns true if > deletion is successful) > > The *QueueMessage* class represents a message sent by the user to a queue, > and has attribtues: id and messageBody, that stores the id of a message and > message body text of the message. User may set the messageBody in a > QueueMessage object and pass it to the sendMessage method, then the method > return a QueueMessageHandle object, with the id returned to the message and > message body. When receiving a messages, a user has to pass the number of > messages he/ she needs to receive and pass it to the receiveMessage method. > The receiveMessage method will then return a list of QueueMessage objects, > each representing a message in the queue. The user may delete a message by > passing a required QueueMessage object received by receiveMessage method, > to the deleteMessage method and the method will return true, if deletion is > successful. > > This interface is implemented to Amazon and GAE platforms using AmazonSQS > and TaskQueue (PullQueue) respectively. I used the AWS SDK for Java > related to AmazonSQS [16] to implement for Amazon platform and TaskQueue > REST API [17] to to implement for GAE platform. The Task Queue REST API > allows consumption of messages from task queue, for the consumers that may > be hosted even outside GAE. > > The user may call the required constructor from the required implementation > and the rest of the user code may remain unchanged. > > *The Configuration and running of test cases is as follows:* > > > - Add the AWS access key and secret key of the user to the > nuvem-amazon/source/test/resources/test.properties file. > > > - Remove the following line in nuvem-amazon/pom.xml file: > > <exclude>**/AmazonMessageQueueServiceImplTestCase.java</exclude> > > - Create a queue named "MyQueue" in the Amazon cluster. > - Then run the project using mvn clean install > > *Implementation to GAE:* > > I am now on the testing stage of GAE implementation and I have few problems > related to configuring to GAE Taskqueue as I am using the REST API in the > implementation. > > I would like to receive any comments regarding the work. > > Thanks > [16] - > > http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/sqs/package-summary.html > [17] - https://developers.google.com/appengine/docs/python/taskqueue/rest > > Thanks, that helps! I've reviewed your patch and committed it under SVN revision r1361932. Here are a few review comments, suggestions and questions: - I'd suggest to keep the package names lowercase and perhaps shorten 'messageQueueService' a little. How about just 'queue'? - Also perhaps shorten 'QueueMessage' to 'Message', as there's nothing that really ties your message to a queue, and if you just want to indicate that this type of message is for use with queues, your package name already indicates that. - I'm not sure that you need the setter methods on QueueMessage, as your constructor already allows to initialize all its properties. It may be simpler to just make it immutable. - I don't think that the following error handling code: } catch(Exception e) { throw new MessageQueueServiceException(e); } actually helps the caller. Why is wrapping all exceptions in a MessageQueueServiceException better than just letting the original exceptions go through? - It seems that the only interesting property in QueueMessageHandle is the message ID returned by the queuing service after you send a message. What would you think about changing sendMessage to simply return that message ID instead of a QueueMessageHandle wrapper object (and then just get rid of that QueueMessageHandle class altogether)? - deleteMessage only needs a message ID (which you currently get from the message passed in as a parameter). How about just passing the message ID directly to deleteMessage instead of requiring the caller to pass the whole message (which forces him to keep it around in memory until he's ready to call deleteMessage)? - I'd suggest to add a few real unit tests. I mean tests that mockup the system dependencies (on EC2, SQS etc) to exercise your code without requiring an actual EC2 instance and SQS queue. That way, others in the project can verify that your code does what you intended to do when they build, without having to set up an EC2 account etc. - Did you manage to implement the same interfaces on GAE? When I initially looked at your interfaces I thought that they looked very close to the SQS interfaces and was wondering how you'd implement them on GAE... Did you run into any issues there? Thanks! - Jean-Sebastien
