My company is emparking on an ERP project ,this project well be java based solution for SMEs and the anticipated number of users well be 20-200 and remote access from branches is expected to be implemented.
the technology proposd for the projects are
1-Swing interface for the client side
2-hibernate for or/mapping
3-RMI objects to encapsulate business logic in
4-web interface for remote access(optional)
5-J2ME for order entry
the issue in my openion seems that using EJB instead of Hiberanate and RMI would be a better solution where the argument on the other side is that since we are developing for SMEs there will be no need for J2EE container in such case .
my concern is that would RMI be able to scale .
there also might be an extension to support integration between this ERP and other CRM system also for SMEs .
Actually the question might be how much RMI can scale -I have searched and saw many aricles in that regard butI need more concrete examples or advice for such system .
I have been working as a consultant in about ten Java/J2EE project over the last five years, and based on that experience I really want to post a reply here.
I really don't recommend anyone to use RMI directly. I my world, RMI is a low level protocol you simply don't want to touch.
And I really recommend you to use en EJB container för the business logic! It solves so many basic problems for you. For example:
- Clustering (if you run into performance problem or requirements on up-time)
- Resource pooling
- transaction monitoring (you don't want to build that!!!)
When using an EJB container, the Swing and J2ME clients can talk directly to the EJB container. No container on the client side! (I was responsible for architecture and design in a system where we built this solution in 2001, and it worked really fine.)
The web solution requires a web server anyway, so using a J2EE Web container instead will not make things worse.
I don't know hibernate, and therefore I cannot make any comments on the OR mapping stuff. The only thing I can say is that I - personally - don't like entity beans. But this feeling comes from an EJB 1.1 project where we didn't have the CMR possibility. A fiend has used CMP/CMR from EJB 2.0 together with JBuilder, and he really likes it.
Finally, I can really see your frustration in the discussions in the project!
Why not use a mixture of EJB and Hibernate?
You could encapsulate your business logic in domain objects (POJOs) and use Hibernate for persistence of the domain objects. This is a much simpler solution than full blown entity beans if all you need is persistence.
You could create a Service Layer consisting of Session Beans that would interact with your domain objects.
All access from the client side Swing interface would go through the Service Layer, i.e., the client interface would not talk directly to any of the domain objects.
If you need to put a web interface on the system at a later point you can add a Struts/JSP layer (or something similar) that communicates with your Service Layer. You can even wrap the Session Beans with Web Services if you need to.
Have you looked at Fowler's book, Patterns of Enterprise Application Architecture? It may help you find some answers.