General J2EE: J2EE=>Death of OO?
It seems like stateless session beans and value objects are winning terrain in the J2EE world. IMHO stateless session beans are little more than remote APIs and VO little more than structs/records. Does this imply that we should brush the dust of old design principles? (Some application do not fall into this category, but standard enterprise applictions tend to just shuffle data back and forth between back-end and front-end....so I guess there just isn't a great need for object oriented techniques....and if that is the case, I guess the toolbox would need to cleaned-up?
- Posted by: Christian Hilmersen
- Posted on: September 24 2003 11:00 EDT
What patterns do you know of that is pushing for the separation of logic and data - i.e. the core of OO?
- J2EE=>Death of OO? by Ian Mitchell on September 24 2003 12:00 EDT
- J2EE=>Death of OO? by Michael Link on September 24 2003 17:26 EDT
There was a similar (brief) discussion about this a few days ago:
I think using JDO or Hibernate solves the problem.
J2EE is not OO ! It is a far too heavy specification which tries to solve all problems and fails miserably in the essential parts (especially Entity Beans). There are a lot of articles about this topic, I think http://www.softwarereality.com/programming/ejb/index.jsp is the best one.
The Java community actually takes a step back from those big-bloated technical gimmicks called Application-Servers. More pragmatic/simpler/better approaches like Hibernate surface everywhere in the opensource community. So J2EE is not the death of OO, it forces Java back to better OO !
Because oviously most people use J2EE (Servlet/JSP, JDBC) to create a web site "web application". So EJB is overkill.
Also the the whole J2EE pet store v.s .NET pet store is bs, because Suns use of the pet store is strictly for example purposes using the J2EE concepts. Of course maybe the pet store is not a good use case for J2EE...
What percentage of developpers have had to work on an application that has 4-5 web sites "web application", web services for accepting incomming client requests, 5-6 application connecting to 3rd parties and possibly other application of same maginitude requiring some capabilities of the other app.
The whole point of J2EE (EJB, JMS, JDBC, Mail etc...) Is for sharing of resources and the application servers allow for scalability when volume increases for certain resources.
Thats when patterns have a big role also. Why should an application composed of several web applications have to have different login mechanisms for each site? When each site can access the same "login module" found on the application server and of course many more examples...
J2EE is not OO !
So you think that Servlets, JSP, JMS and JDBC are not OO? J2EE != EJB.
EJB is definitely not OO, because it is component technology. You know, like ActiveX, DCOM, OLE or OpenDoc.
>It is a far too heavy specification which tries to solve all problems and fails miserably in the essential parts (especially Entity Beans).
Entity Beans are definitely not an essential part from developer's point of view. That's quite fortunate, since they are a hopless failure. You can use any "persistence" library you want instead of them. Even java.io.*, if you don't mind breaking one of the sillies (and usually misunderstood) requirement from EJB spec.
> The Java community actually takes a step back from those big-bloated technical gimmicks called Application-Servers. More pragmatic/simpler/better approaches like Hibernate surface everywhere in the opensource community. So J2EE is not the death of OO, it forces Java back to better OO!
Hibernate, however nice to use, solves only the persistence part. Usually one wants to handle also concurrent execution, deployment and security. For those issues, EJBs don't suck so much.
Which by the way! JBoss Group has announced they will use Hibernate as their container for CMP