so what?

just because something isn't OO doesn't make
it bad!

No. EJBs are classic functional decomposition.
The question should really be are we doing OOA & OOD when building EJBs. And the answer is a definite no. From an OOA point of view, an EJB represents a business object where the behavior exists in an application server and the attributes exist in a relational database. Although EJBs may provide a great framework for scalability (for those few apps that truly need a great deal of scalability), they represent classic functional decomposition thinking, not the natural thinking of object orientation. Ultimately, they are a step backwards.

Missing the point...
I think everyone is missing the point. EJB's are not in and of themselves object oriented. They represent a component-based approach to system design. The actual construction of an EJB and its supporting framework (because if every part of your system is an EJB of some sort you're not only in violation of the J2EE Blueprints, you're also creating a maintanence nightmare) should be approached from an object oriented perspective.

This complaint isn't new, and the answer isn't either - Sun has addressed both many times over.

EJBs are a sadness upon OO
It's clear that the whole "EE" approach to designing systems is contradictory to "classic" OO. In the old timers' view of OO systems were conceived of as communities of collaborating objects, and this was a good thing; an advance over the Input-Process-Output style of programming "systems" that were simple data transformers. The early days of OO were heady with the promise of using OO as the mechanism by which the behavioural complexity of whole systems could be captured in the "types" that described the objects that would in and of themselves be the system.
Somewhere along the line the emphasis shifted and the "strategic", or "Enterprise" systems have become thin veneers for relational databases, and the vast preponderance of effort seems to have become centered on how to once again produce data-transforming I-P-O systems that have, at best, a limited and transient representation of the system's state via pretty limited functionality EJBs.
In my experience I've seen project after project after project ignore the larger-scale benefits of the OO approach to systems development in favour of the dumbed-down approach of first presuming the "only way" to save state is in a relational database, and then given that figuring out the simplest possible mechanism for dragging RDb table rows up to the UI and then flushing them back to the Db with as little fuss as possible.
I'm hoping that JDO will begin to shine some light on the dimming "whole-system" approach to OO that encourages the contemplation of systems as behaviour-rich communities of interacting objects.
My very strong preference is to design systems using "classic" OO concepts and practices and let persistence be a supporting low-level technical feature necessary to support the system's state if required across time and crashes.
In short, I lament the current fashion of designing all systems as slaves to relational databases.

EJBs are a sadness upon OO and so is JDO
JDO is just a thin veneer to present relation databases as classes. It does not support behavior in an "objectbase." I too lament the loss of OO in the current implementation of EE. I've suggested another approach entirely in my current article JDBC v. JDO on onjava.com.

Using OOP technics with EJBs
Hi from Hamburg,
I am currently trying to convert a complex ArificialIntelligence related Client-Server Application into an Enterprise environment. I 'weapond' miself with lots of OOP-Knowledge to make a good ApplicationDesign job. In the last days i became stocking in my doing because I think that there is no really good way to fit my 'Inheritance Wonder' right into the EJB Home-Remote Interface coursage. If somebody knows how to make anything more complex as filling a OnlineShop-ShoppingBasked or creating automated email-forwarding systems or that funny bankaccount-transaction stuff; please let me know! Yours, Kay Lummitsch - Hamburg

You are correct
When EJB came out, during the height of OO adoption, they were focused around the corba idea of distributed objects. When the declarative semantics and simplicity of programming(back then :) ) came into conflict with OO, the EJB designers choose the former. They seem to have figured that it was better to have a simple way to write Enterprise apps than a maintainable one. The result (despite myself being an EJB proponent) is a overcomplex system. It needs serious refactoring and in most cases the OSS community is doing it for Sun. EJB is great for certain things, but it is clearly not the original vision of acheiving all of the wonderful benefits that corba distributed objects -- transparently.

On an up note. I have been resisting trying many of the ideas that have floated around the blogsphere for some time (hibernate, aop, webwork, IoC, etc, etc). My EJB background made me take the approach that since they can do everything that you should use them for everything. I have since tried many of these things and have changed my position to that of using EJB if the requirements call for something as flexible as EJB. In other words, EJB has been relegated, in my toolbox, to glue between different types of applications or UIs.

$0.02

LES
http://www.mindmeld.ws

Missing the point...
While I agree with what you are saying, the number of patterns that we had to invent to make EJB maintainable and doable is staggering. I love EJB, but I think that it needs some refactoring. It needs to become more OO and more chinese menu oriented (choose what you want, not get everthing by default). J2EE gets that, but EJB within it does not.

The way I was taught...
...was to always be aware of the relationship between your code and your data. The OOP approach is to combine the two into a single unit such that an object always operates upon itself (e.g. myString.print()). The procedural approach is to separate code and data so that an operation always performs on something external to itself (e.g. print(myString)).

Applying this concept to EJB, one can conclude that, in general, the latter (procedural) approach is used. Take for example the DAO pattern, which separates the code for loading/storing a bean in persistent storage from the bean itself. This is a procedural approach as one must call upon the services of a third-party to perform the desired task. An OOP approach to this would be to add CRUD methods to the bean. These methods may just be wrappers that call the DAO, but your code doesn't have to know that and that's the whole point -- tell the bean to load/store itself and let it worry about how to actually do it.

EJBs == hypothetical
Herez the pinch:

When you are developing in a framework, everything seems "to be at the right place at the right time". I am sure you had that feeling deep inside. Its a warm, fuzzy and safe feeling.

But, EJBs on the other hand are quite a mess.
The JCP guys have to learn the following things.
1. Most of the projects DO NOT need so much scalability.
2. What 90% of the projects need is productivity and functionality (a huge feature set, so that they do not have to develop everything from scratch)
3. The environment should not put so many restrictions on the components.
4. Fire the redundant Home interfaces. PLEASE. One component == 1 object + 1 interface
5. Giving remote access to an EJB should be as simple as setting a boolean value.
6. Try to eliminate EJB-QL (We agree you guys are VERY smart. We just don't want another language)
7. Why does Sun keep creating all these small languages with not so much functionality?? Example: EJB-QL, el (JSP) etc??? And thats the new @ sintax in J2SE 1.5. Its a nightmare.

I resisted myself from putting all the above points in CAPITALS.
I have written endless comments about the way Sun is taking forward java. I will continue to do so. I am sure i am not alone. If there is a way i can make those guys hear.....

Dushy

Only one option
It's certainly possible to do OOD/P in the context of EJBs -- EJBs are not the only "objects" in your application. EJBs were never intended to be fine grained business objects -- they are intended to be coarse grained components. A session bean facade doesn't have to be a simple procedural facade in front of your entity beans. It can (and, I believe, should) be a facade that provides security, transaction semantics, etc. in front of a your business objects . How your business objects (which is where your OOD/P is) get and process data from a datastore will depend upon your needs. They could be/use JDO, JDBC, Entity EJBs, etc. Ideally your session bean methods will be extremely short, and rely upon your object oriented business objects to do the real work, their main job providing security, transaction semantics, etc. In fact, if you don't use Entity EJBs to access the database, you can usually use your fine grained business objects outside of the application server, and give yourself a lot of deployment flexibility (e.g. the Fast Lane Reader pattern), which can help with unit testing, etc.

I personally am a fan of JDO, since it is a standard, and works really well both in and out of an application server, and provides all of the object oriented concepts that Entity EJBs can't really give you (unless you jump through many hoops).

All that said, I'm excited to see what the next EJB specification looks like, since I do think that it could be a lot simpler.

so what?
true. however i was late to join a team writing an online bank in 2JEE where the
architects had cut their teeth on oracle two tier apps and they had mainframe
guys cross training to Java hacking the code. they were all right at home with
procedural ejb style and kept on feeling like i was the one that did not "get
ejb" as it was my first look at that end of J2EE. okay this is not Sun's problem
as any technology can be mis-used but i think that they really missed an
opportunity to make something beautiful and made something that fits a
procedural mindset. it is a shame that the mainframes now only know object
based (vb, js style) programming after their brush with ejb. i used to go home
and toy with
prevalence frameworks just to keep my sanity.