Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Best practices for retreive/edit EJB system  RSS feed

 
Pieter-Jan Malfait
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i'm developping an ERP packet and i will probably use EJBs on JBoss for this. the first part of the project involves creating the funcionality to add/edit/remove all kinds of business objects (like Clients, Articles, ArticleGroups, etc). So no complicated business logic is needed at this point.
The interface is a Swing client.

Are there any best practices known for this approach? I have a lot of questions like : do we model each object as a EJB? is it possible to mix EJBs and regular objects? can regular objects be persisted using the application server? where do we create a business object instance, on the client or on the server?

I guess the answer to all these questions would be a best-practice for this common problem..

thx a lot in advance!
[ September 15, 2005: Message edited by: Pieter-Jan Malfait ]
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By regular object I think you menat POJO. To persist such objects OR framework like JDO or Hibernate will be useful.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With a Swing client I'd be sorely tempted to make a rich stateful object model in the client and use the server only to get & put persistent data.

For any EJB server I'd consider a single Stateless Session Bean as a gateway to a variety of POJO services. Hibernate would be high on my list of candidate technologies, too.
 
Pieter-Jan Malfait
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
With a Swing client I'd be sorely tempted to make a rich stateful object model in the client and use the server only to get & put persistent data.


would there exist fe Article POJOs on the client and Article entity beans on the server, with periodic syncrhonization ? i'm not sure what you mean with rich stateful object model...

Originally posted by Stan James:
For any EJB server I'd consider a single Stateless Session Bean as a gateway to a variety of POJO services. Hibernate would be high on my list of candidate technologies, too.


so i could use a SSB to persist POJO objects using hibernate, and i don't model the objects as entity beans ? how do i use these objects on the client then? also i will in a later stage of the project need more functionality for most domain objecets, they will have to be transaction-safe and authentication will be an issue too.

Also, are these two different kind of suggestions or can they be combined ? Thank you very much for the responses!
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A rich stateful object model in the client can be the primary place you work with all your objects and their relationships. This is in strong contrast to web applications that often have no object model at all (beyond the HTML DOM) in the client browser, and an "anemic" stateless model on the server that by and large matches the database model.

With your "fat client" all the "interesting" stuff goes on in the client, and the server just has CRUD (create, retrieve, update, delete) actions for individual objects or whole graphs of objects. I think this makes the client much more fun and rewarding than web programming, but we're in the business to deliver maximum functionality for the dollar so fun doesn't count that much.

I'll take back the "single SLSB" in the server ... I use an architecture that does that now, but it was pretty high effort to build the communications protocols between client and server. A handful of Facade pattern SLSBs would do fine, and line up better with common industry practices.

I don't think there are many people doing the architecture you propose: fat client and EJB server. Anybody?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think there are many people doing the architecture you propose: fat client and EJB server. Anybody?

Yep, spent a lot of time working on such systems. You need to use transfer objects and coarse-grained method calls. Once you invoke an EJB method from a client thousands of miles from the server, you don't want to make many more calls!

The EJB design I like is a stateless session bean as a session facade, thus hiding the business logic implementation from the client. This implementation might be other session beans possibly in combination with POJOs. The facade will take a course-grained method call and invoke the relevant EJB method(s).

AS for transactions: they begin in the beans, and I always use CMT beans if possible. One of the worse things to do is to start transactions from a remote client, though I'm sure someone's done this ...
 
Pieter-Jan Malfait
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
I don't think there are many people doing the architecture you propose: fat client and EJB server. Anybody?


are there any other well-known structures to create a scalable enterprise application with a fat client ? i've thought about using only a swing clients with hibernate that connect to a common remote database, but wouldn't i lose a lot of functionality like autorization, transaction-management, resource pooling, etc?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!