TheServerSide.com is on a mission to assemble EJB/J2EE case studies. These case studies will be published online. We are looking for people who are willing to volunteer to be a case study.
This is is a unique opportunity for your firm to show the world that your software is enterprise-class, and to benefit from free marketing. This marketing could be leveraged for recruiting strong EJB/J2EE developers, for credibility during a sales process, or for obtaining new leads.
To get involved, you do _not_ need to have gone live with an EJB/J2EE system. Rather, you must have a finalized object model, and be prepared to discuss it, as well as the challenges you faced and the tradeoffs you made when designing your system. Anonymity can be preserved if necessary.
If you're interested, or know a firm that is interested, please let me know and I'll get the ball rolling.
Contact is Ed Roman, author of "Mastering Enterprise JavaBeans"
I am a developer who is interested in looking at some EJB case studies. Can we have the case study for theserverside.com as a start? Not the powerpoint slides that are there in the Resources section, although, I must agree it was a great experience going through the slides, but, we need more information. I feel that this is a good initiative and hope that a lot more people will reply to this thread with some case studies.
Also to Ed Roman, great book............
I have been a part of a successfull launch of a site built on the J2EE platform. I'll be happy to have this experience as a case study. I am already trying to share the experience and lessons learnt through talks at Java User Group and other forums. I also met Floyd at JavaCon2000 and chatted on j2ee. Feel free to contact me at pkumar at sapient dot com
I have a deep interest for working on EJB's which i have been able to may be becaz of lack of resources or proper guidance....i m working on Servlets and JSP's for a portal site and want to convert the same site on pure J2EE/EJB based environment....if this sessions gets started then its gonna be a great help for me..
Several folks have contacted me for details of my experience since my post above. I believe it'll be most effective and efficient to communicate through these threads or articles posted here rather than individual communication. Though, I will be glad to answer specific questions individually.
Here is the summary of the J2EE development experience I want to share. It is a site for managing home services - GuideStreet.com
The whole site was developed in about 5 months. This included things as varied as content strategy, visual design, information architecture, front-end technology, and core server-side technologies.
The application runs on Weblogic 5.1.
The application architecture is based on Model-View-Controller paradigm. The presentation layer consists of JSPs, the interaction controller layer consists of servlets. The model (business logic) is implemented with EJBs and JavaBeans. Stateful EJBs are not used (for performance reasons), all session state is kept in the HTTP session. Entity beans are used sparingly - only to create new entities, update entities, and to look up one entity at a time. All bulk lookup happens through JDBC. All entity beans use CMP - this was a conscious decision to enable fast implementation and to keep transaction strategy simple. The lack of table-join support in entity beans somewhat forced the choice of entity beans in the system. This was isolated from most of the system through a processing layer of stateless session beans that would manage the object graphs when there were dependent objects involved.
Lightweight data objects (value objects, plain JavaBeans) were used for passing the data around, in order to minimize RMI calls to EJBs. This used version numbering to ensure correctness of data. This design pattern has recently appeared in the ServerSide.com newsletter # 3. The design pattern: Long-Lived Optimistic PseudoTransactions(aka. Version Numbering)
Your project looks good and we are developing a project for
a publishing company called classwell.com . Here we are using jsp for frontend architecture,Bladerunner for creating content in XML format and for content management we are using Tanino. Both of them has their oun repository
and apart from that we are using oracle8i as our relational database. In developing EJB we are using cmp for each table in the 8i database and bmp for Tamino repository and we are raping stateless session beans around these entity beans and we are following Details Object Design pattern to pass the data to and fro from the JSP to EJB.
We are using the validations on client and server side on the specified architecture
Please send your comments on this
your architecture looks similar to ours, with the exception of bmp. I believe you had servlets also which you haven't mentioned. Otherwise, JSPs will be playing the role of view and controller.
This sounds like the approach we are using in our firm with the exception that we're using BMP and Container Managed Transaction. One interesting challenge that has come up recently is the issue with BULK UPDATE. Since entity beans are used for update there is an issues with the cache size. If the cache size is too low it generates the CacheFull exception and if it's too high then it creates the running out of memory problem. I can make things working by setting the transaction attributes to make sure that update happens on one bean at the time within it's own transaction so that it can also be passivated. But, I believe the best way of doing the Bulk Update is using the Stored Procedure. I tried using the stored procedure but I have problem with data synchronization. By that What I mean is that what's in the DB is not the same as in cache, so EJBs do not know about these changes and old data gets rewritten!! So far everything that I read in publications was just reading data using SPs and no update... My question for you is that have you used the stored procedure to do bulk update? based on your expertise, how do you deal with the data inconsistency??
Hi. My team has done several projects using EJBs and I would definitely like to be involved in a case study. Please advice as to next steps.
i would be interested also in becoming involved in the case study, if you don't mind someone a bit wet behind the ears. if not, and i would be more than willing to participate. i also want to take the time to publically thank you for your book, it's been a tremendous resource, as well as the assessment y'all did for us. james helped more than he'll ever realize. thanks, and i look forward to the participation.
We would be interested in participating.
This is good opportunity. I have been leading the development team of successful vertical portal. We selected J2ee platform for development. Our middle tier (business components) developed with EJB1.1 and Weblogic5.1.0. In my view design for EJB is easy job and it helps us to minimize design and implementation time. I would like to share my experiences.
We are following Ed Roman Book
My name is Marek Sadowski from Poland. I am working on the vertical portal and would love to learn from your experience of designing and implementing with EJB.
I would like to learn what tool did you use for both the design and implementation. And how many mandays did it take to deliver the beans from the design to deployment.
Are there any hidden stoppers?
in our company we focus on J2EE and XML, we both develop applications and products. For now we have developed our own EJB codegenerator based on a XML datamodel specification. It generates the complete persistence layer (the Entity Beans, some helpers as Session Beans and the scripts which create the database tables and stored procedures to access them) from this specification which is similar to a traditional E/R model.
Based on this, we developed our own online-catalog which helps to build flexible online-catalogs were fast because of the codegeneration capabilities.
There is still no live-application because the mentioned products are very recent, but we are developing now to applications which we hope will get live 1Q/2000.
There were many issues (performance, etc.) we had to fight with, which gave us the opportinity to gain a lot of know-how.
alopez at aqs dot es