This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Well, after posting a couple of topics in the wrong forum (sorry about that, learning the ropes around here), I would like to ask for your help on finding a good solution for this scenario...
I am designing a web application that will run in online and offline modes. The idea is to use servlets on the server side for the business logic, but the problem is when the device (or notebook or desktop) cannot access the server. I was thinking on placing some of the servlets on the device, but I have not been able to find a Java Application Server Pocket PC or Palm compatible.
I would appreciate your thoughts on this.
Joined: Apr 21, 2005
BTW, the idea is also to have a mini-version of the database on the device...
Ahh, now the requirements come to light. Thanks Alfredo.
OK, so it is all about online vs offline. So here is the design. You need to have the client not know whether it is calling a Servlets, a Plain Old Java Object, or an EJB. It only knows how to call methods on a simple interface. The implementations of this interface is what will know whether it is calling a Servlet, Plain Old Java Object, or EJB. So these implementation will convert the response received from the Servlet, POJO, or EJB, into a format that the client can use. This way we have extracted out the need for the client to care whether it is working online or offline.
Now for the client to receive an instance of an implementation of this interface, it will need a Factory, and your client will simply call the Factory to return some instance of the interface. Now you no longer need a Servlet or Application Server on your PDA. The Factory will determine what you will need.
It is all about Design Patterns and what has already been done. There is a good reason why you can't find an App Server for a PDA. That is because it would be a bad design if you needed that, a PDA is not a server and should never be a server, it isn't its responsibility.
That should help a bit. Unfortunately there is more needed for the design.
So in simple terms, you want a client and server all in one?
Well I would usually say "no problem, just run the server and connect to the server via localhost", but you are putting too much stress on a little device to be able to run it as a server (let alone a client). I am guessing that you may need to write something in J2ME - which is made for "resource limited" devices such as PDAs. But to build a servlet engine is no easy task, never mind trying to deploy a database and port it to J2ME. It probably won't happen. The "offline and online" makes no difference, the requests still need to be serviced no matter what, and a response sent out. "Offline" to me means that the server will no longer be available and not be able to service HTTP requests.
If you can find a mini database (I know there are many open source ones only a few megabytes in length) and port it over, then why not just write a standalone Java application which could read the database? I'm not sure if JDBC would work in J2ME (my guess is that it won't), in which case you would need to have a flat database file (possibly XML but it would be huge strain on resources in parsing, so copy some plain text over, prehaps using CSV and parse it). Your app could mimic database I/O by reading/writing to/from this plain old file, so it no longer becomes a web application and changes to "offline". To the end user, your front end of the Java standalone app would look no different to the web application. They could query the database and your application would not need to worry about sending/reading HTTP responses/replies.
Joined: Apr 21, 2005
Thanks for the responses!
Even though I know that running the server and the client on the same device might seem "overwhelming" for a little PDA, the advantage is that I can reuse Servlets that were written for a desktop environment, simplifying the maintenance process. Complementing some of your comments, not only I need a JAS, I also need a messaging server (for sync purposes while on "online" mode) and as you mentioned, a mini-database. Actually, something like this already exists: IBM offers a framework called "Workplace Client Technology, Micro Edition", which provides all this. Actually, I wrote a little app and the performance is more than acceptable. The problem that I am facing is that licensing IBM technology is prohibitively expensive. Here is the link to such technology:
I have been looking for the components as separate pieces and actually found the DB and messaging server, but not the JAS for PDAs. Any information or feedback that you might have about this is greatly appreciated.
[ April 22, 2005: Message edited by: Alfredo Perez ]
[ April 22, 2005: Message edited by: Alfredo Perez ] [ April 22, 2005: Message edited by: Alfredo Perez ]
Joined: Apr 21, 2005
Originally posted by Mark Spritzler: Ahh, now the requirements come to light. Thanks Alfredo.
OK, so it is all about online vs offline. So here is the design. You need to have the client not know whether it is calling a Servlets, a Plain Old Java Object, or an EJB. It only knows how to call methods on a simple interface. The implementations of this interface is what will know whether it is calling a Servlet, Plain Old Java Object, or EJB. So these implementation will convert the response received from the Servlet, POJO, or EJB, into a format that the client can use. This way we have extracted out the need for the client to care whether it is working online or offline...
Mark, thanks. This was my first approach to the problem, but it means creating a specific implementation for the PDA project. I basically want to reuse the Servlets that I already have and simplify the maintenance process.
What do the Servlets do. I say that if your application code is inside your Servlet, it is too coupled to your Servlet. A Servlet should only handle the Request and Response objects. it should be a pass through (Facade) into the business services behind it, which is best as Plain Old Java Objects. So the Servlet really should just be a window to pass through. Then you can create other Facade's quickly and easily and reuse your Business services.
I still say you are going the wrong way trying to get a Servlet to run on a PDA, it is using a Servlet for a purpose that it was not intended for.
Check out PointBase database, they have a way to connect and disconnect to the data from PDA or J2ME, so you can work offline and online, and it can hook into any RDBMS like Oracle.
Please take my advice and try a different way than Servlets.
It sound to me like you need to back off a few clicks and view this as a message passing problem. If your business logic is in a class that simply gets a data structure such as a Map of input parameters and returns a Map of output values, then the same logic can be used with a servlet/jsp interface or a all-in-the-same-JVM program on a PDA. Note the convenient getParameterMap method in ServletRequest which returns a nice general Map where the values are String and the keys String. I have used this extensively - it makes developing and debugging so much easier because you can work outside the servlet environment. At a further level of abstraction you could expose the same business logic as a web service. It is just a matter of thinking in terms of messages and separating the transport mechanism from the business logic. Bill
Actually, putting the servlet engine and a browser both on a PocketPC is exactly what IBM has been telling their customers to do. The advantage is to have a consistent design and it is the basis for IBM's vision of "grid computing" on mobile devices. PocketPC with its 400 MHz processor and 64 MB RAM has enough processing power for this ...
The thing to notice is that you need a lightweight servlet engine (OSGi not J2EE), a lightweight Java database (Pointbase or HSQL as Mark mentioned) and related JDBC drivers. I talked about this design in the "Enterprise J2ME" book (see the signature).
I think I'm going more Mark's direction. Think of the HTTP client and the servlet as plumbing to get from the business function client to the business function service.
What if you just took all that out?
Life just got a lot simpler! You get some new constraints - write your service and your database so they can be used in a servlet engine or in a standalone app. That's a nice constraint that will lead you to good separation of concerns.
To make life a bit easier on the business client, we can make a Business Delegate (see SUN J2EE patterns) that knows when to use HTTP and when to use local calls.
One implementation of the interface uses HTTP to call a servlet while another implementation just passes calls through to the business service class.
I'm currently using a vendor framework that does exactly this stuff to choose different protocols - sockets, remote EJB, XML/HTTP, RMI, etc. Very slick.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 29, 2003
Oh, that probably wasn't applicable at all if your objective was to retain the browser interface on the PDA. If so, kindly ignore until another project comes along that might use it.
You might want to look into an IoC container of some sort (I would use HiveMind, but that's just me). Then, you could "plug in" a different implementation of your services at runtime, depending upon availability of the server. How does that sound?
James Carman, President<br />Carman Consulting, Inc.
Joined: Apr 21, 2005
Thanks a lot to everyone for your replies. A lot of food for thought. I will make sure to post my findings when I have come up with an architecture for this.