Swing based J2EE application - Suggestions req.

[Suresh Selvaraj]

Hi,
We have a new project that has a rich client (Swing).

Here is the design that we have finalised:

Swing application (deployed in IBM WAS 5.0)
|
| (invokes)
Business Delegate
|
|(invokes)
Session Facade (Stateless Session EJB's)
|
| (invokes) DB@ database for Search operations oe Entity EJB for Insert.
Entity Beans

Presently, we do not have SERVLETS as Controllers. From Swing based on Events, we invoke the Business Delegates directly.

I'd like to know if this is OK or should we open any SOCKET/URL Connection to invoke SERVLETS?

I'd like to have your suggestions incase if you have implemented similar application.

Thanks and Regards,
Suresh Selvaraj

[Eric Snell]

Why call Servlets? What would that add?

The architecture you describe sounds OK. Is there some code duplication between a web interface and swing interface you're trying to address? Otherwise, I don't know why you'd introduce more complexity if it's not needed.

[Suresh Selvaraj]

Hi,
Since the user has to navidate through several screens, how to manage the data.

Ex:

Screen 1: (Fill up all the fields)
|
Screen 2: (Fill up some fileds)
|
|
Screen 3: (Fill up some fields)

If its a JSP/Servlet application, we can maintain the data in Http Session and finally save the data when the user pushes SAVE BUTTON in SCREEN 1.

Since this is a Swing based application, I need to save the data in each screen to the database, and when I navigate from Screen 3 to screen 1, I need to read the data from database etc...

I'd like to know if there is any way by which I can maintain the data temporarily and then finally save the data to database.

Thanks,
Suresh Selvaraj

[Amirthalingam Prasanna]

I think Value objects will help you to do this. You can save your Value Object to the database after collecting all data.

[Eric Snell]

Originally posted by Suresh Selvaraj:
...
If its a JSP/Servlet application, we can maintain the data in Http Session and finally save the data when the user pushes SAVE BUTTON in SCREEN 1.

Since this is a Swing based application, I need to save the data in each screen to the database, and when I navigate from Screen 3 to screen 1, I need to read the data from database etc...

...

In the Swing based app, why do you need to save the data to the DB? Why not just maintain it on the client until you have all the data you need and then perform the one transaction? Is maintaining data in the http session so different from that? What are your failure scenarios in each situation, how do you handle them, and how is the user experience different in each case? It seems the http session scenario is a more complicated architecture since the context must be maintained across several stateless calls from a client.