• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Swing based J2EE application - Suggestions req.

 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 28
Mac MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 28
Mac MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic