According to a recent survey of 150 CIOs, only 9% of them have adopted EJB as a solution, with 14% using EJB partially and 16% still evaluating it. This supports my theory that EJB is still in a fast growing market and that the true large-scale adoption of EJB is at the tail-end of the Geoffrey Moore's scale, to which we are slowly but surely moving towards.
Refer to the "Java" Section of this report from Morgan Stanley Dean Witter
That need not necessarily be the conclusion ... the 14% (partial adopters) are the watchers and these enterprises would be ready to move either way..the 16% (evaluating..) must be evaluating .NET and web-services as well !! In fact 2000 perhaps saw the biggest adoption of EJBs in the market consisting of Dot-Coms and Enterprises. This primarily was due to Dot-Coms (after all they were the high-risk takers in revenue models, technology etc :-) 2001 would not see the fast growth experience by Java community last year. So it only remains a wishful thinking that Java (EJB, etc etc) would see true large-scale adoption.
(p.s. - I luv Java, but future is still unpredictable ... we need to keep our fingers crossed :-)
It is interesting to read the "application servers" section where it reports that 47% responds using WebSpere while only 22% using BEA Weblogic. I though it should be the other way around. any body has explanation?
It is hard to tell how representative the sample used in the survey was. Perhaps this is why some of the data does not match what we see from other sources.
And the funny part is WebSphere is very faulty. It's not J2EE compliant. It requires you to use the use the IBM VM to remotely access EJBs. And I could go on forever. Long live Dynamo.
I am surprised to see Java supporter (as he says) like Sameer being so pessimistic about EJB.(Nothing personnel here)
After seeing how different is EJB and how it is different, let it be written any language it will be a success no doubt. Probably some vendors will not be able to provide an appropriate solution right away.
But there is no doubt a product like EJB, let be written in any language will succeed.
Java programmers should be worried if C++ people come up with a solution real fast before EJB finds it way into every corner. But component model rocks for the development and maintainance. It is going to make a difference in our thinking like Client/Server did few years back.
EJB should fear only of CORBA. But if they are used in different perspectives as they are now. Then nothing beats it.
".net" or MTS/COM+ should will compliment EJB in the future or follow the same path. But will not limit EJB's growth.
Let future decide the course.
Definitely wishful thinking from part of Ed Roman.
The growth is pittifully slow , compared to the deployment of Win2K as a server OS, for example.
Or, do you expect people deploying Win2K as a platform for running EJB?
The real bad sign is that media and market research organizations began to confound Java with EJB.
So as one put it here, I think "EJB shoul fear only of CORBA" is wrong.
The correct and reallistic phrase is:
" Java should fear EJB".
A possible discreditation of EJB as a platform, would do a lot of disservice to Java in general, beacuse of the irresponsible marketing efforts from Sun.
It doesn't even need to be a total ruin, even a lost of momentum to competing technologies would do a lot of harm.
After all, Sun has almost succeeded in getting Java out of the client, so I see there's at least a considerable probability of doing the same on the server.
I think EJB's are a great concept. Unfortunately, my experiences with EJB's vis a vis performance in a clustered environment have not been encouraging. In my opinion in an EJB v/s CORBA comparision, if performance is the criterion CORBA wins and if ERAD [Extra Rapid App Development :) ] is the key, EJB wins.
The way the App Server market looks right now for EJB's...its a long way to the top.
Actually, today there are much more CORBA based enterprise servers in use than J2EE.
As for performance, remember Moore's Law. It states that the processing power available at a given price doubles every 18 months. Development process, scalability, reliability advantages cost much more higher than performance gains. Instead of using C in the enterprise, you better pay for more hardware resources (It's cheap), use Java and benefit in development and maintenance. I'm sure that Java has bright future, but I can’t say the same for EJB. EJB is not distributed component technology itself. EJB will never replace CORBA. EJB is only on server side, while CORBA is everywhere: many technologies like Intelligent Agents can be build only with CORBA.
I disagree that the 14% are watchers and 16% are must be evaluating .NET and Web Services as well. The 14% likely come from large companies with multiple projects inhouse, that have adopted EJB for one of their solutions (kind of like a trial) and will hopefully move forward and begin using it again on new projects. The 16% evaluating are NOT evaluating .NET and Web Services, these technologies don't exist yet. The only other platforms they may be evaluating are Corba, MS Windows DNA, Perl or some proprietary solution. Strong arguments to use EJB exist for all of those competing technologies.
We are at the foot of the mountain now, look how far we have gotten with only EJB 1.x! Once EJB 2.0 is finalized, EJB development will get even easier the road will be paved for even faster adoption. Companies like BEA and Sun will make sure of that. :)
The two things I found interesting about the Morgan Stanley report were:
1. When asking if EJB were a standard for developing server based applications 58 percent said NO. And 53% said EJB compliance doesn't affect their selection of applications.
2. No questions were asked concerning alternatives to EJB. While 55% had standardized on a single application server platform only EJB platforms were on the list.
With over 50% of respondents saying they don't care about EJB and they're OK with applications that don't use them says to me that market penetration could be a long uphill battle.
The company I work for uses primarily NT4 and W2K servers running applications based around COM but that isn't stopping them from putting in PeopleSoft 8 based around JSP and EJB. But even then the local developers are insulated from the EJB and JSP by being able to develop in PeopleCode and then have the PS8 translate that into JSP for the web clients.
Most large corporations will be a mix of MS and Java technologies. Your best bet is to learn enough of both to be flexible and rely upon XML, SOAP and XML-RPC to bridge the gaps.
I'd have to agree with Michael here. I saw the same figures and thought I bet the people who said they had selected their application server were just responding on autopilot.
Either they have strong relationships with vendors who have a product like this, or they are avoiding a sales call - most probably both.
Anway, the reality is that 2-tier is dying - the tools just aren't progressing as the major vendors battle it out in the application server space - plus all the obvious advantages that n-tier gives and which I won't go into here.
This means that most major upgrades, and products being developed from scratch are going to utlisise an n-tier architecture - which for arguments sake can be CORBA, EJB and/or COM / .Net.
Of these, EJB has support from most of the major vendors with of course the exception of MS who are, let's face it, behind the pack here. From what I understand, VB developers are up in arms over .Net about not having an easy upgrade path for all their legacy code.
Anyway, as we all know, an MS GUI interface beats a web browser, X-Windows, or Swing interface hands down for your typical corporate environment. Unless Mac pulls a rabit out of the hat, we're doomed to support this for a while longer. ( no flame wars please )
But as Michael points out, technologies such as SOAP are bridging this GAP. So my take on all this is thin .Net based clients using SOAP to talk to a Linux based EJB middleware server(s), with really efficient, container based persistence, that will work seamlessly across different databases.
My personel experience with EJB is that it a very complex mechanism for distributed processing and prefer SOAP which uses HTTP or SMTP for distributed processing.
EJB as a framework does not really define a lot on the server implementation and hence the servers get really complex and the way Entity Beans are handled could be diff on diff servers.