File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes One servlet, many platforms Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "One servlet, many platforms" Watch "One servlet, many platforms" New topic
Author

One servlet, many platforms

Alfredo Perez
Greenhorn

Joined: Apr 21, 2005
Posts: 7
Hello!

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.

Best Regards

Alf
Alfredo Perez
Greenhorn

Joined: Apr 21, 2005
Posts: 7
BTW, the idea is also to have a mini-version of the database on the device...

Thanks again!
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
K Riaz
Ranch Hand

Joined: Jan 08, 2005
Posts: 375
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.
Alfredo Perez
Greenhorn

Joined: Apr 21, 2005
Posts: 7
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:

http://www-306.ibm.com/software/wireless/wctme/

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.

Best Regards

Alf

[ April 22, 2005: Message edited by: Alfredo Perez ]

[ April 22, 2005: Message edited by: Alfredo Perez ]
[ April 22, 2005: Message edited by: Alfredo Perez ]
Alfredo Perez
Greenhorn

Joined: Apr 21, 2005
Posts: 7
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.

Any additional comments are more than appreciated

Best Regards

Alf
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.

Thanks

Mark
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12678
    
    5
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


Java Resources at www.wbrogden.com
Michael Yuan
author
Ranch Hand

Joined: Mar 07, 2002
Posts: 1427
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).


Seam Framework: http://www.amazon.com/exec/obidos/ASIN/0137129394/mobileenterpr-20/
Ringful: http://www.ringful.com/
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12678
    
    5
HTTP and servlet servers have been created for small Java environments. This site gives an example. A web server / servlet interface makes sense for many embedded Java applications such as sensors that use Ethernet for connectivity. The Dallas Semiconductor TINI boards are examples. I have one of these on my desk right now - astonishingly small.
Bill
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
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.
Alfredo Perez
Greenhorn

Joined: Apr 21, 2005
Posts: 7
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.

Best Regards
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: One servlet, many platforms
 
Similar Threads
Newbie-communicating with wireless devices
is there a better way for address book application
using EJB and JMS from J2ME
Mobile JavaFX and Flash Lite
Push Registry: how to get the device IP