File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes live customer project involving entity beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "live customer project involving entity beans" Watch "live customer project involving entity beans" New topic
Author

live customer project involving entity beans

Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
We have so many of us in Javaranch. How many have actually worked on projects and have got the customer live with an application using
Entity beans? Do we have people who have opted for an alternative option like JDO? On an average how many entity beans were used?
What was the ratio of entity beans to the database tables that you had in the system. I do understand that link tables need not be modelled as entity beans but there are cases when we end up storing data specific to the links.
Did you have a bean to model that? It w'd be great if you c'd let us into the obstacles that you faced and ofcourse how you overcame it.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'm working on a project which went live with some entity beans about a year ago. The entity beans were used per table and there are less than 50 of them (for comparison, there are some 200 session beans and a dozen or two message-driven beans). The design, I believe (that part of the system was coded by a subcontractor) was data-driven. I'd love to share more details but I really don't know much about the details. There haven't been major obstacles but then again, the most intensive database operations have been implemented with raw JDBC and/or stored procedures.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
nobu taku
Greenhorn

Joined: Aug 06, 2003
Posts: 17
I'd love to learn more about real production applications using entity ejb. I think ebay uses j2ee.
Lasse, what kind of application did you work on? 50 entity beans and "some 200 session beans and a dozen or two message-driven beans" just sounds crazy to me. Can you educate me on why you used so many ejbs? How long did a full application build take?
mathew mathews
Greenhorn

Joined: Aug 06, 2003
Posts: 7
Lasse do you think that application with 50 entity and 200 session beans
is a good design.I mean Ofcourse it depends on the size of the application.
Use ejb for projects having lot of transactions because application server will take care of this part.
mathew
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
nobu:
I'd love to learn more about real production applications using entity ejb. I think ebay uses j2ee.
Lasse, what kind of application did you work on? 50 entity beans and "some 200 session beans and a dozen or two message-driven beans" just sounds crazy to me. Can you educate me on why you used so many ejbs? How long did a full application build take?

Yes, eBay does use J2EE. There was a thread about it at TheServerSide.com some time ago. The reason for having that much EJBs were not good -- the project was a real mess when we came in, and unfortunately continued as such a mess because the client wanted to have so many vendors doing things together. Personally, I think the gigantic process (or the lack of enforcing it) was the primary cause. Then again, most of the session beans and message-driven beans are used quite appropriately in the boundaries of sub-applications (we have dozens of those as well).
Our application is in total almost 1.4 million lines of code, which is without a doubt more than would've been necessary.
The full build takes anything between 5 and 30 minutes, depending on how "clean" the build is (i.e. how much stuff can be skipped with a timestamp check).
Mathew:Lasse do you think that application with 50 entity and 200 session beans is a good design.I mean Ofcourse it depends on the size of the application. Use ejb for projects having lot of transactions because application server will take care of this part.

Good design. Part of it is, part of it isn't. You should've seen it before we migrated the earlier version from ASP to J2EE two years ago... We're doing a lot of things (credit card operations, buying stuff, downloading billable content, processing SMS messages, etc.) benefiting from declarative transactions and have many applications (i.e. separate .ear files) so using EJBs to interface with each other is not such a bad choice in my opinion. Most of us have explicitly agreed that what we have is more or less crap but that's what we have and what we don't have is budget to redesign (besides, we don't have the right to touch most of the 1.4MLOC anyway, legally or otherwise). We're just concentrating on doing the best we can on every new feature we're adding.
Nagendra Prasad
Ranch Hand

Joined: Jul 11, 2002
Posts: 219
Lasse,
That was a nice explanation of what is and why it is so! 50 Entity Beans.. We have a similar project.. but not the same numbers.. though we might end up hitting those levels if proposed developments keep their place.
What kind of hardware platform are u using to run this application on??
If you could share this info at all, it would be great!
And for your build, do you plan out hot deployments? do u go through a clean install each time??
If there are details you can share, I might ask a few more ;-)!
Thanks for your time.


Best Regards,<br />Nagendra Prasad.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
What kind of hardware platform are u using to run this application on?
A cluster of very big Sun boxes running Solaris. That's about all I can say.
And for your build, do you plan out hot deployments? do u go through a clean install each time?
Plan out hot deployments? I'm not sure if I follow but if you're talking about whether we hot deploy during development, then yes, always when possible. Unfortunately, one of the big screw-ups we have to suffer is that most of the stuff is loaded by the system classloader and thus cannot be redeployed by our appserver.
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Lasse Koskela:

The full build takes anything between 5 and 30 minutes, depending on how "clean" the build is (i.e. how much stuff can be skipped with a timestamp check).

Am not sure if this is too specific. But did you actually mean that you spend most time on "ejbc" ing your beans. I mean is that the reason your build takes so much time to execute?. Unless the tables are real huge with really complex CMRs, i kind of think that even 15 minutes is too much for "ejbc" ing 50 beans.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
But did you actually mean that you spend most time on "ejbc" ing your beans. I mean is that the reason your build takes so much time to execute?. Unless the tables are real huge with really complex CMRs, i kind of think that even 15 minutes is too much for "ejbc" ing 50 beans.

Actually, we're not even ejbc'ing anything during the build but deferring it to deployment time... Anyway, I am running a small subsection of the full build script because I am the "SMS subsystem developer" and the codebase I deal with is pretty compact and doesn't have too much dependencies to the rest of the system (this script takes about 30sec to finish). Due to this shortcut I only need to do the 30-minute build once a day on average (usually during lunch).
By the way, I forgot to mention that the 30-minute build also consists of generating a lot of source code based on XML documents so that takes some time as well. If these files don't need to be generated, the build time drops to 10 minutes or so.
Nagendra Prasad
Ranch Hand

Joined: Jul 11, 2002
Posts: 219
Lasse,
So, what do you do when u have to deploy to your 'live' application server?
-stop/Install/Start or something else?
(Well this could be diff. it it is just a single EJB jar or so..)
We are struggling to find a workable compromise where the customer does not suffer a loss of service while an application install is going on.
what we do not have (and therefore manage this action smoothly)is a backup domain which can continue to run the 'old' version of the application while a new one is being installed.
Do u manage similarly or is it different?
Thanks.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
So, what do you do when u have to deploy to your 'live' application server?
We are struggling to find a workable compromise where the customer does not suffer a loss of service while an application install is going on.
what we do not have (and therefore manage this action smoothly)is a backup domain which can continue to run the 'old' version of the application while a new one is being installed.
Do u manage similarly or is it different?

We have almost identical QA and Production environments (mainly the number of CPUs differs I think) that are completely managed by the hosting provider. We don't have any "write" access to those servers, only read-only SSH accounts for reading log files and such. Deploying a new build happens by transferring an "image" (tar.gz file) into a certain location and sending a request for an update to the hosting provider.
We don't have a backup domain either but we can update one server at a time if necessary (drop one server from the cluster, update it, add it to cluster).
It should be possible to update the cluster's servers using the cluster administration tools but for some reason we cannot use them. I'd suggest you take a look at whether it's possible for you guys (let the appserver vendor deal with how to deploy stuff without downtime).
Nagendra Prasad
Ranch Hand

Joined: Jul 11, 2002
Posts: 219
Thanks for the response Lasse. Much appreciated.
You have given me a very important point to chew over... the fact that cluster nodes are taken out of the cluster and added again.. that might be
the solution.
Don't know if websphere cloning allows for this.. but again.. thats not for this forum... but something to think about all the same.
 
 
subject: live customer project involving entity beans