RESTful Web Service and Signed Java Applet

[mauihoosier]

I have a signed java applet that is calling a RESTful resource to insert values into a DB. I have a requirement to compose a list of what was inserted and present that on another page as a sort of audit that the user can print out. I am thus far unable to carry that list forward to my 'audit' page. Reading the documentation I see that conversations aren't really supported yet using the REST services, so I am looking for suggestions on how I can accomplish this task. This is my first SEAM project after being a java developer for 11 years so be gentle :)

Any help is appreciated...

[cpopetz]

Two possible solutions include:

(1) Add a column to the data you're inserting that represents the id of the batch in question, pass the id to the audit page as a request parameter, query the list of records there based on the batch Id.

(2) If it's not memory intensive, create a Manager component in the Session like:

@Scope(SESSION)
@Name("auditManager")
public class AuditManager { 

   List<Thing> insertedThings;
    //getter and setter here

}

and use that to store the data you inserted for the audit page to use.  If the audit page can conceivably be loaded while the applet is still running, or if multiple applet/audit pages can be open at once, this isn't a good idea, but it could be managed wih a concurrent HashMap of batchId -> List<Foo>.

My preference is for (1) because it scales better and is decoupled, so other things can use it, like reports on how many people used the applet, and how many files did each transfer on average.

-Clint

Clint Popetz

http://42lines.net

Scalable Web Application Development

[mauihoosier]

Thanks for the prompt response Clint.

My applet is scanning in bar codes which are validated and sent to the db either for look up or creation. Thankfully the audit page cannot be loaded while the applet is reading in data. Technically the user could open up multiple applets, but could not access the bar code scanner to read in more data while it is in use by another applet(serial port in use). This hopefully will avoid the scenario of multiple audit pages being spawned by the same user. Whew, hope that makes sense.

I agree that number 1 is the better solution, and is likely the one that I will implement, but what if regarding solution number 2 List<Thing> insertedThings could be set to null once the navigation moves away from the audit page? Or better yet, is there a way to remove the object from the session once the user navigates off of the audit page, and add a new instance back to the session when the use moves to the applet page to begin scanning new codes?

Thoughts?

Thanks so much for your excellent suggestions. I appreciate your input

-Brent

[cpopetz]

I agree that number 1 is the better solution, and is likely the one that I will implement, but what if regarding solution number 2 List<Thing> insertedThings could be set to null once the navigation moves away from the audit page?

Arranging to do things when a user navigates away is tricky and error prone and dependent on javascript.  What if they just close the window?  Or leave it open forever doing nothing?  That is of course one reason why conversations were created, so that they could be timed out sooner than the session :)

Or better yet, is there a way to remove the object from the session once the user navigates off of the audit page, and add a new instance back to the session when the use moves to the applet page to begin scanning new codes?

Again, doing anything on navigate away is hard.  But you could add a clear() method to the AuditManager which clears the list, and call it from your restful resource when the applet starts its work.

[mauihoosier]

Very helpful..thanks!

-Brent