aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Outside Forces and EJB's demise. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Outside Forces and EJB Watch "Outside Forces and EJB New topic
Author

Outside Forces and EJB's demise.

Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Everyone discusses how EJB development is not practical in a real environment. You hear them mention that there is a lot of overhead associated with EJB development that leads to more overhead during deployment and even more overhead during runtime. The biggest gripe is Container Managed Persistence of Entity Beans.
Here is my theory. EJBs (especially Entity Beans) were never intended to be developed in-house. If one takes the time to read the EJB specification, it speaks of two development roles: the application developer or assembler; and the EJB developer. The spec goes on to say that the app developer and EJB developer can be one and the same; but the ideal scenario according to the specification would be the EJB developer being a separate company providing functionality in a component that can be integrated into an existing application or an application being developed.
Essentially, Sun realized that Microsoft had established a strong component market around the COM framework and was looking to grow a similar market in the Java arena. Take ipworks from Nsoftware for instance. Using COM, a web developer can access an array of Internet tools from ASP pages or from other COM objects being used by the ASP pages. The developer would not have to worry about implementing and maintaining the various internet protocols, he could just use the COM framework and a purchased package to provide that functionality to the company's application. There are tens of thousands of similar products available to Microsoft developer and thousands of companies whose business model is to provide tools for the Microsoft developer.
This was Sun's goal with EJB; that tool developers would create EJB components that provide pluggable functionality to the Java enterprise developer. CMP would give the EJB access to a database in multiple environments without the EJB developer knowing how the runtime database would actually look.
Unfortunately, the EJB market never took off like the COM market because people just didn't get it! Companies used the abstraction of CMP that took more effort than necessary since they had control of the database and could embed JDBC code directly into the EJB if they wanted. Developers complained about how difficult it was to create and test entity beans. This was good for the IDE market because they could provide tools that helped the developer create Entity Beans easier and charge a premium; but the EJB market never took off as it was hoped.
If EJBs had been used as expected by Sun, the technology would be praised. Developers would be able to purchase tools that would shave months off development time and focus on the problem at hand: implementing the company's business logic.
A good example would be a credit card processing suite that knew how to communicate with several clearinghouses and could use the database for managing single-click purchasing. A tool vendor could create an EJB package that provided this functionality callable within a web application. All the customer would need to do is configure the tool using the instructions provided by the vendor and they could call that functionality within their web app. This is where the portability of EJBs will be utilized. The tool can work with any application server and will provide a marketable service to many customers who no longer have to worry about implementing credit card processing within their application.
Instead people embraced the technology as a tool for everyday development. In the Microsoft world, this is the equivalent of writing your business logic in C++ using the COM API. Believe me no one would use Microsoft tools if developing a web application required that amount of work and I'm actually amazed that J2EE has survived as a viable solution as long as it has. Hiring EJB developers (or worse consultants) is expensive. Just like hiring COM developers is expensive on the MS side of the fence. Developing and testing EJBs is a time intensive task and deploying them every time you change them requires even more effort.
So let's get the word out. EJBs ARE FOR TOOL DEVELOPERS! Maybe the market for EJB components will grow as people grasp on to this fundamental tenet of the EJB specification. I will get off my Soapbox for now.
Michael
[ February 16, 2004: Message edited by: Michael D. Brown ]
Ed Bicker
Greenhorn

Joined: Oct 14, 2003
Posts: 12
Here..here...Excellent. I could not agree more. Very good insight.
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Thank you,
I was hoping to inspire a full conversation on the topic but I guess everyone here already knew that
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
May be everybody is already started using tools like TopLink(after reading your post ) and agree with what you said.
Also it is possible that they are all making good money with full job security(and no chance of outsourced to India or replaced by some one on temporary visa)
Dan.


Kishore
SCJP, blog
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
Is not EJB a simplification of CORBA that tool creators/developers could not manage to get their arms around? Does toplink simplify the development of high scalability and availibility systems?
Could you post a link to toplink?
[ February 17, 2004: Message edited by: Rufus BugleWeed ]
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
toplink used to be offered by webgain(they bought it from objectpeople I think). Now it is owned by Oracle. You can get it from Oracle.
Dan.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Outside Forces and EJB's demise.
 
Similar Threads
Interview story
Resources for WAS
Test 484 ... LONG POST
Software Developer
long post IBM.158