Ejb Case Studies

This is obviously an area of great interest to readers of these pages. Please, please, if anyone can contribute a detailed case study (as opposed to a simple reference), do so. Or, alternately, if you can contribute a link to an externally published (free) case study, please do so.

There seems to be an unanswered demand here for real-world stories of how EJB is applied in practice. The important questions to answer in a CaseStudy? are : what aspects of the technology worked and were successful in solving the problem at hand; what went wrong or could have been done better; and what was learned from the experience.

When Time is of the Essense: http://www.devx.com/upload/free/features/entdev/2000/07jul00/de0007/de0007-1.asp -- BillDavis

The Making of Beans for Business

A series of articles by David McNerney? on how the BfB site was built completely from EJB. Application with 46 beans, EJB 1.1, Weblogic, Oracle, Apache, Linux; Application also recently ported to jboss.

http://www.beansforbusiness.com [Link to 2 articles from home page]

http://www.theserverside.com is based on EJB in WebLogic, and postgreSQL running on Linux.

Instinet fixed-income, http://www.instinet.com , a popular exchange for bonds and bond options, uses Persistence PowerTier in what is estimated to be one of the largest EJB rollouts in the world in terms of complexity and sheer hardware power.

A major international bank's securities subsidiary uses EJB session beans in the back end of its web trading interface for institutional fixed income investors.

That same bank's traders use a massive Swing-based application to trade fixed income derivatives and bonds. The back end is WebLogic, which subscribes to all the various markets & pushes market data to the clients with JMS. RMI services make up most of the server (since message-beans don't exist until EJB 2), but a few session beans can be found for stateless operations.

A major Canadian bank uses WebSphere & SessionBeansAsFacades to a domain object graph as the back-end for one of their equity trading systems.

Nike apparently uses GemStone. So does Ingram Micro.

(All serial numbers filed off to protect the innocent)

A Major investment firm uses WebSphere (EJB's, Servlets and JSP's) to provide Customer account information for 401K's and IRA's. They use SessionBeansAsFacades and a curious pattern I call BackwardsEntityBeans. They are also using CommandServlet.

Another major investment firm provides a sophisticated user interface (Swing Applets + some fancy HTML/DHTML using Servlets and JSP's) to provide up-to-the-minute updates and analysis of portfolio values and investment opportunities. Same approach with SessionBeansAsFacades, but using BMP EJB's to directly connect with a back-end Relational database. Also in WebSphere.

I've personnally been working for a Banking software editor (not in the USA)... I was their Java architect/project lead.

I, with a team of 6, have wrapped their legacy (SQL Open Server and C language, Sybase RDBMS) portfolio management system in EJBs. Entity beans (just for identity of objects, and for data security) and Session Beans (mapping to OpenServer? procedures). And it worked ! And it sells ! As far as I know (I left this company), at least 7 banks had bought the system.

Actually, different levels of implementation were available, from almost bare EJBs, to complete running web site. Some clients deployed in the context of an Intranet (for internal users only), some on the Internet... At least, these were deployment projects :-) Going to real public web portfolio management is a really big deal !

I've learnt a lot on this project... Since we just offered an EJB facade to the legacy system, most efforts were just integration and adaptation. The legacy has not been modified, even if new concepts needed to be introduced, particularly in terms of security (because the bank's client becomes a potential user of the system). Data security was a real nightmare, because when offering components like we did, you must ensure the bank cannot corrupt its own security because of potentially poor usage. Regarding performance, since you're all waiting for that... it was easy to kill the underlying OpenServer? before reaching the point where EJB performance matters... aka, the weakest point was the legacy system. And yes, we did some stress testing. All I can say is it was good enough (200 concurrent users, ie many more web users, without optimization).

We introduced very little overhead, by not trying to reinvent the weel. We used entity beans very carefully, just to identify the entities we did manipulate. Why bother with all the information contained in the Customer table, when what you need is just a way to identify this client, search for him, or follow a few relational links. So we had a Customer EJB, with 3 or 4 fields, that provided its list of portfolios, language, etc...

Finally, we obtained a real Components-based-design, that worked and hid the __enormous__ complexity of the underlying system. We could do less things, but better. We only worked on things that had added value to offer.

Only advice I could give : use EJBs on projects that matter only (because this technology can become quite expensive), and try to get the most out of it. Strive for added value. If the main interest is to open a system so that it will have 100000 customers instead of 50, just do it ! But try to respond to these 100000 users the best you can, regardless of what the 50 could want... Because they may want the new system too, except they need __much__ more than the 100000. -- SorryIwillRemainAnonymous?

I am currently working for a company where we built a trading system for clients to do automated trading through (we give them an API and they write programs to trade real-time). We started off using Weblogic because someone thought it would be good. Writing and testing the software it seemed that you sometimes had to jump through a *lot* of hoops to get simple things done. Anyway, we brought up our prototype system and quickly discovered it was too slow. Ok, we switched out our database (Sybase ASE) and switched in Postgresql. Things were a bit better, but still not good enough. Then we switched out Weblogic and used RMI instead. Again better, but not good enough. Finally we ended up whipping up our own remote messaging system over sockets and doing our own database connection pooling. Then things were fast enough. While our system requires a lot more speed than most, EJBs would not be something I would quickly decide to use again. When we threw them out our code got cleaner, easier to understand, and faster. What the EJB server did provide for us was just not that hard to write ourselves. --ITooWillRemainAnonymous

I believe that more and more programmers are discovering just this. EJB isn't the promise-land it was hyped to be. Too bad it will take several years to shake these failures out of the "system" and bring better technology to the forefront. What a waste. -- JeffPanici

I recommend we all keep up with the latest news for this reason. As time goes on, there is a very good chance that the EJB architecture will be able to live up to some, perhaps even most, of the promotional hype. Also, I recommend taking a peek at the book, "Bitter EJB", by Bruce Tate, et al. --IThreeWillRemainAnonymous

''We are looking at implementing a startup online system with ejb, however the opinions we've gotten from many app server developers in the field is that it is slow, unusable and overengineered --Call be Bob if you like''