wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes architecture Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "architecture" Watch "architecture" New topic
Author

architecture

karl koch
Ranch Hand

Joined: May 25, 2001
Posts: 388
hi everyone
what would be a good architecture if i plan to have a web-client and a java client app (providing more features than the web-client, eg. sorting of tables, context sensitive menues...) and want to avoid EJBs ?
on the server side there is the business logic along with the DB.
for the web-client i would go for struts/jsp/servlets but what would be the good way to connect the app-client to the system ?
i hope i could make clear what i want to do
...if not, please ask.
thanks k
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Uhhh... this sounds like a perfect time TO use EJB's -- it's a perfect repository for shared business logic callable by both your struts application and your thick client. Why do you feel you need to avoid EJB's? This is one of the few problems SOLVED by object distribution, which is exactly what EJB's are for.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
karl koch
Ranch Hand

Joined: May 25, 2001
Posts: 388
hi kyle
i have the feeling that EJBs might be to heavy, thats the main reason. but i agree with you: thats what ejb are good for :-)
what about making the app-client using http and have the controller returning something else than html (eg. xml describing the result) if the user-agent is an app-client ? is this bad practice ? this would be to avoid rewritting the controller for different clients.
thanks,
k
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
We're interested in doing something similar - we have a somewhat complex UI (I've not yet seen a good UI for letting non-DB savvy users build database queries) which we'd like to connect to a web application. Proposed solution thusfar is to use a distributed controller. Typically the controller handles both the calling of the business logic and then the handoff to a particular view. Our (servlet) controller on the web side would handle the business logic. Our controller on the UI side would handle calling the servlet controller, and doing the appropriate handoffs to the UI. We're looking at the Struts/Turbine sets of MVC tools, but haven't yet figured out if/how they'd fit (other than Turbine's really cool Fulcrum service set).
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
FYI, there's something that sounds similar to what you need in Java's Pet Store example. Their admin client is a rich client that uses web services to connect to the server. A prelim look at the way it's architected makes me think that it'd be easy (for at least my case) to provide a ServletPetStoreProxy implementation of the PetStoreProxy abstract class, and use it instead of the web services implementation. Theoretically, you could then use your same servlet to drive views for Swing and for JSP.
karl koch
Ranch Hand

Joined: May 25, 2001
Posts: 388
Tina: thanks!. I'll have a look on the PetStore architecture.

k
 
wood burning stoves
 
subject: architecture