This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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 ]
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.
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 ]
Joined: Jul 10, 2001
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.