TSS' own Floyd Marinescu has started blogging. In "A brief history of EJB," has given us a discussion point on the history and placement (and success) of EJB in the Java space. There has been some dissent, including this rebuttal by Ted Neward, in which Ted refers to Floyd's history as being "revisionist."

Floyd then responded to Ted's comments with yet more counter points.

An interesting observation:

I speak at conferences fairly often, and at some point during a talk I will ask the audience how many have used EJB. Usually, 90% put up their hand. Then I ask them, how many of you have used EJB as distributed objects, meaning, where you have a separate physical tier for your business logic and a separate tier for your presentation (servlets/jsp) tier? Usually only 15% of the 90% will put up their hand. These results have been consistent at conference I've spoken at in North America, Europe, and Japan.

What do you think of the issue?

Floy wrote:
"EJB was designed to be a distributed object framework, for use on large-scale systems, but most of the audience was using it as a local framework for their small - medium sized web apps."

There is a possiblity that ... it (EJB/ORM/OMG) does not scale, that it can only runs on small scale. It is possible that in order to scale you have to have a good physical E/R model and experience w/ relational algebra and set theory, ala Celko. What if it fails on large scale in practice?

That is why we have Apache's PetStore, to have a DAO that does scale. It has been said many times that the worst part of J2EE is ejb.
Lets define small as "it fits on a laptop or in ram" and VLDB as TB+.

.V
roomity.com

The result still never ceases to amaze me, since EJB was designed to be a distributed object framework, for use on large-scale systems, but most of the audience was using it as a local framework for their small - medium sized web apps.

Vic - For the record, I re-phrased that one after being blasted by Ted Neward. :) EJB was not JUST designed to be a distributed object framework, I boiled it's features down to three areas later in the blog, framework, distribution, components.

The result still never ceases to amaze me, since EJB forces you to apply distributed semantics on your code, which is useful on multi-physical-tier large scale projects, but infact most of the EJB audience was using it as a local framework for their small - medium sized web apps.

apply distributed semantics on your code, which is useful on multi-physical-tier large scale projects, but infact most of the EJB audience was using it as a local framework

Lets ignore multi-tier for a second.

My point is that "EJB/etc." may not be scaleable (relative to other DAO's that are closley tied to physical data model) distributed or not. That may be reason that it's only seen on small projects. What if it does not scale? What if that is just marketing or theory?
Evidence is anecodtal, like Friendster going to PHP, I do not know if they were using EJB.
Lets examine this scientificaly:
"EJB's only work for small projects"
Why that is is part 2. So what you may be seeing is EJB only on small proejcts, becuase others convert to another DAO/aproach.

(Then we can say: becuase of remote interface, or becase of EQL, or becase of impedenace, or .. )

more:
http://www.adtmag.com/article.asp?id=9476

.V

of applications that are useful.

EJB is overkill unless you have a need to do distributed transactions, have massive scalability - and even then, an intelligent O/R model and KISS DAO framework go a long way.

EJB's have HUGE overhead on the development and production sides...note: when you get a huge EJB cluster up and running, the network saturation that results from session and cache replication is ENORMOUS...let's let databases do what they do - CACHE and QUERY. Session EJB's are nice in the event you need to do XA, but using EJB's to do data caching and object distribution has WAAAAAAYY too much baggage and increases project risk of failure exponentially because 1) it's complex and very few people can do it right 2) you will be hard pressed to get buy-in because of 1 and 3) if you play the odds, EJB is overkill for your project.

There is a better way, and it is writing and properly encapsulating JDBC code.

Just my 2 cents.

Bear Down.

There is a possiblity that ... it (EJB/ORM/OMG) does not scale, that it can only runs on small scale.

I applied custom ORM on my two last J2EE projects (one big and one medium size) and it scales definitely very well. I didn't used OR mapping products, but simple, custom ala Martin Fowler approach, with database mappers doing caching, (declarative) transactions and high level fetching logic and database gateways doing only plain stateless JDBC with SQLs stored in XML templates.

It's blazingly fast as there is no full blown OR mapiing layer, all SQLs are tunnable to the very bits (but also reusable due to templates), caching was piece of cake to implement (as oposed to record set oriented approach) and adding new entities/attributes/relationships was relatively easy thanks to resonable class hierarhies of database mappers and gateways.

So, in my experience, custom OR mapping is very viable choice.

I don't think anyone ever said that custom code, be it ORM, web frameworks, etc... aren't viable.

I think it is the practicality. In the last few years, I've certainly seen the benefits of using more standardized frameworks like Struts, Spring, and Hibernate. Why? Because not only do I not have to maintain the documentation needed for frameworks to be useful, but I'm able to focus more of my energy on writing the core code.

We've been able interview and hire junior and mid-level developers who were almost all immediately productive because the either came in with say Struts experience or could benefit from the various books and forums on Hibernate and Spring and ramp-up quickly. Far more quickly than some custom framework that no one outside the company is familar with. In addition, we've attracted people to our small company because we are perceived as using cutting edge tech.

The market is getting better, people. Try bringing on people with your unknown, in-house custom framework.

As long as the Springs and the Hibernates allow us to "go to the metal" when necessary, I think that they represent a superior choice.

struts tackles a very different problem than a persistence model...a MUCH EASIER problem since HTTP and HTML are relatively static.

Each project doesn't have to reinvent another transport/application protocol while each project will likely require an entirely different data model from previous projects.

You are comparing apples to oranges by calling out the usefulness of Struts as an argument for the retention of EEJB.

I was not implying that no component market => no component model. What I mean is that I don't think we'll ever see a business component market (components meant to provide business logic), so we do not need a business component specification.

There are areas like sound/image/video processing or CAD/CAM systems, which are built around components. Some components are both UI and business, some are business only, like stress analysis. On the other hand, I don't see why one would use EJB for that. So I agree, that EJBs do not need business component spec.

struts tackles a very different problem than a persistence model...a MUCH EASIER problem since HTTP and HTML are relatively static.

I would not say that problems which are solved by web frameworks are much easier than EJB-related problems. Quite contrary, with EJB, once you get it going, you just bake one bean after another. Web framework deals with UI including UI/model/persistence relationships. A large website is much more complex than uniformly written and container-handled EJBs.

Each project doesn't have to reinvent another transport/application protocol while each project will likely require an entirely different data model from previous projects.

Compare Struts with, say, Wicket and see, how different application protocol is. User experience is also improved despite the fact that Wicket uses the same old HTTP.

struts tackles a very different problem than a persistence model...a MUCH EASIER problem since HTTP and HTML are relatively static.Each project doesn't have to reinvent another transport/application protocol while each project will likely require an entirely different data model from previous projects.You are comparing apples to oranges by calling out the usefulness of Struts as an argument for the retention of EEJB.

I don't think so. I am saying that the time for custom frameworks has pretty much passed. I offer Struts, Spring, and Hibernate and my personal experiences and thoughts as reasons why. Even a different data model can still use Hibernate and Spring.

It is not like there anyone is working on a truly original problem. I think that this would require a fairly radical paradigm the likes of which we haven't seen since the birth if RDBMS.

Ubiquitousness is the single biggest advantage of frameworks like Struts, Spring, and Hibernate over the aforementioned custom ORM framework. Especially in a good job market, you will have a hard sell trying to attract new talent by touting a custom, unknown ORM solution or any application framework.

And we haven't even mentioned the effects on the project.

I didn't used OR mapping products, but simple, custom ala Martin Fowler approach, with database mappers doing caching, (declarative) transactions and high level fetching logic and database gateways doing only plain stateless JDBC with SQLs stored in XML templates.It's blazingly fast as there is no full blown OR mapiing layer, all SQLs are tunnable to the very bits (but also reusable due to templates), caching was piece of cake to implement ...

Isn't iBATIS what you are describing ? :-)

Isn't iBATIS what you are describing ? :-)

My thoughts EXACTLY.

Isn't iBATIS what you are describing ? :-)

Sort of. Our database gateways and SQL templates are similar with iBatis DAOs and SQLMaps.

Still, you do have to implement mapping layer at the top of it with caching, lazy load, declarative transactions and higher level fetching/updating logic (when you have to issue several queries/updates to fetch/update one complex entity).

And this remaining part is probably more complex.

Forgot to mention concurrency control in database mappers layer.

A nice read on the history of EJB, thanks Floyd! As to the question whether or not a standard for object persistence makes sense in the time of open source:
Well of course it does! The majority of Java developers still uses plain JDBC to interface with databases. What a waste of time and ressources! The majority will only switch after a standard for object persistence
has become mainstream. There can only be one.
--
Carl Rosenberger
Chief Software Architect
db4objects Inc.
http://www.db4o.com

15%? Seems pretty high to me.

From what I can tell, the biggest usage of EJBs(if separate tiers are used) is for their built-in remoting - it could be replaced with plain-ol RMI.

"more importantly, the "weight" of EJB is not in the API itself, but in the implementations the vendors sold us."

I really hate EJB threading strategy. EJBs best part is it's stateless beans yet it's the very place where singleton model would worked much better then what EJB has (an object per thread). EJB threading model is decent compared to say COM+ mess, but Spring' simpler solution that usually work better. This issue has nothing to do with implementation. It's an API problem.

I like EJB threading, it can let us cache the non thread-safe object in EJB instance such as JMS session. This really boost the performance and simplify the programming model.

Sure that are cases when some resources should be used in a thread safe manner, but it is usually easy enough to handle this synchronization without using EJB. One way is to use a pool of non-thread safe objects (Spring supports this for instance). The issue with EJB is that they assume that you always need that protection...

Hi,

I like the distinction framework/distribution/components.

However, IMHO some issues need clarification:

1) You write: "EJB forces you to apply distributed semantics". This is only 20% true. If you already know that your .ear will be deployed inside one JVM (as 85% of your audience), you do not have to care about the most difficult problem with distribution,
which is partial error. Also timing issues inside one JVM are a minor problem compared to WAN based distributed calls. Of course, calls have call-by-value semantics, but this is in my experience only 20%.

2) Of course you are right that there is no EJB component market. However, I do not agree to the conclusion "there is no component market => no component model (like EJB) needed". As can be seen by Eclipse, a good component model is central for the architecture, and I don't think .jar files are sufficient. So I would have liked to see something like Eclipse plugins also on the server side, providing

a) Class Namespace Support / Isolation
b) Zero-Downtime Installation & Upgrade
c) Extension Point Concept
d) Local Interfaces

Note that EJB does support a) and b), but not c) and d).
(It is beyond my knowledge, whether b) and d) are mutually exclusive).
So in summary, I do think we need a server side component model, but a better one than EJB.

3) Speaking of history: Compared to plain CORBA (or RMI) programming, EJB have been a big step forward! I'm still waiting for the next step. Saving some LOC with POJOs isn't it.


* Stefan Vaillant

Compared to plain CORBA (or RMI) programming, EJB have been a big step forward! I'm still waiting for the next step. Saving some LOC with POJOs isn't it.

Well said, Stefan. So, where are the visionaries?

I would like to see the application model (development through deployment) that is designed to run non-stop through major and minor evolutions (including language / runtime changes, i.e. Java 5, Java 6 .. Java 42, etc.), running seamlessly regardless of hardware failures, and scaling up and out to any extent necessary.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

In the realm of functional languages, we have (among others) Erlang (http://www.erlang.org/). It has supported fail over, module versioning, hot swap of modules, process watchdogs etc etc for a very long time now.

Of course, functional languages have still to reach the mainstream, if it ever will...

Per Bergman
Versant Corp.

Of course you are right that there is no EJB component market. However, I do not agree to the conclusion "there is no component market => no component model (like EJB) needed". As can be seen by Eclipse, a good component model is central for the architecture, and I don't think .jar files are sufficient. So I would have liked to see something like Eclipse plugins also on the server side, providing

I was not implying that no component market => no component model. What I mean is that I don't think we'll ever see a business component market (components meant to provide business logic), so we do not need a business component specification. The Eclipse example you provided is an example of a viable component market, because Eclipse components are utility components that can be used the same across any project. They do not embody project-specific semantics.

Just one comment into this idea of having common business components. I was once participating in IBM's San Francisco project where we tried to utilise "ready" business components by IBM (and the projects where those have been developed). I really learned it's impossible to have that kind business components or classes where your projects detailed functionality can be added by just inheriting something from common component. Why ? 'cause business applications are still so different. You can imagine an example of customer component where every company/department has so different definition of customer. Who cares if you just only can inherit addresses and names ? I believe on components where functionality is defined in very detail level (like UI components). Portlets are also starting to approach the ability to really reuse. But it means that the whole semantics and environment is very dedicated for certain cases. Business components are something boosted by marketing guys..

Before the "what now" questions, let me add a data point that the group that I've been working with used EJB for either the "framework" benefit or the "distrution" benefit, but very rarely both. The component benefit has never been in the picture. (Guess that shoot us right into the abusers' league.)

So what now?

0. I gathered if I only need the framework benefit, light weighted containers like Spring seems to the answer?

1. If I only need distrution, what should I use if not EJB? On one hand as Floyd points out, things other than RMI are only maturing; on the other hand, even with the API weight of EJB, I'd still prefer that API over hand coding RMI any given day of the week. Any sugestions?

2. Seems if the application needs both the framework and the distribution benefits, using EJB -WAS NOT- a misuse "at the time". So what now? Is EJB considered a mis-use NOW if my application needs both?

I agree with Ted that it's crazy to use web services for inter-tier distribution, web services are for integration.

There is an exception to this statement. WinForm on PC connecting to J2EE Web service on server is already a viable or even better (better UI, less load on the server, more scalable, more responding, simpler to develop and maintain) alternative to the traditional browser based J2EE Web application within the corporate Intranet.

There is an exception to this statement. WinForm on PC connecting to J2EE Web service on server is already a viable or even better (better UI, less load on the server, more scalable, more responding, simpler to develop and maintain) alternative to the traditional browser based J2EE Web application within the corporate Intranet.

I would say it is a kind of integration, but what about e.g. transactions in such approach ?

but what about e.g. transactions in such approach ?

Do you control transaction in the presentation layer in a traditional browser based J2EE Web application?

Hey,

How times have changed and how the EJB spec has been patched and re-written to make it into something it is not.

Most applications I have worked on either use SOAP/HTTP or some home grown XML/HTTP to communicate between the business tier and some third party application.

This relegates the use of EJBs to Stateless EJBs for declartive transactions and MDBs when using JMS. The rest of the EJB spec is as the saying goes history. Stateless EJBs are also now being replaced by more flexible AOP frameworks like Spring which just leaves us with MDB.

To be honest the only thing EJB has going for it is the fact it is a spec that companies like IBM, BEA and Sun will push to non tech savy business people. This enables them to make mega $$ off their over engineered Portals and Integration engines.

David

the only thing EJB has going for it is the fact it is a spec that companies like IBM, BEA and Sun will push to non tech savy business people.

(So it seems no one wants to challanage that EJB's are mostly for smaller projects, they just don't scale for xyz reason)

I suggest that tech savy people use the Spring remoting and ... even Groovy, so that entire J2EE does not get a bad rap.

.V
roomity.com

Stateless EJBs and MDBs scale fine. Many large scale applications are built with them.

the only thing EJB has going for it is the fact it is a spec that companies like IBM, BEA and Sun will push to non tech savy business people.

(So it seems no one wants to challanage that EJB's are mostly for smaller projects, they just don't scale for xyz reason)I suggest that tech savy people use the Spring remoting and ... even Groovy, so that entire J2EE does not get a bad rap..

Vroomity.com

I'd rather not start a flame war, but I know of several large deployments that use quite a bit of EJB's. And it scales fine if the developers know how to use it. I fail to see how small projects would benefit from EJB's. If anything, small projects should use Spring and stay light weight.

obviously, I'm not going to get myself in trouble and state which companies are using EJB's to handle some rather nasty integration scenarios. Once a project moves beyond a single large database and into the realm of 2 dozen systems with conflicting models, it becomes pretty clear simple approaches run into limitations.

peter

I know of several large deployments that use quite a bit of EJB's. And it scales fine if the developers know how to use it.

Peter, can you share privatley the sucess story? Are you shure it's not just stateless?
netsql at roomity.com.

Becuase... I know a few huge disaters where they spent 8 digits and then pulled out EJB, and everything worked.

So my belif continues to be "EJB for small, Spring/Groovy/iBatis for large" (it's my belief and other can have their belifs). It's just that simpler is easier to maintain and runs faster, and being close to they phsycial model is key.

.V

Stateless EJBs and MDBs scale fine. Many large scale applications are built with them.

Peter, can you share privately the success story? Are you sure it's not just stateless? ... So my belief continues to be "EJB for small

was discussed on the TSS that statefull session EJB2.1 scales same as the HTTP session;

sometimes is good to keep the state closed to DB in app server, sometimes is good to keep the state in client. Stateless service is not the best solution for everything.

also was discussed on the TSS that BEA CMP EJB2.1 can be faster than Hibernate

So it seems no one wants to challenge that EJB's are mostly for smaller projects

Spring/Groovy/iBatis for large"

but using EJB's to do data caching and object distribution has WAAAAAAYY too much baggage ... There is a better way, and it is writing and properly encapsulating JDBC code.

I prefer to use DAO and combine O/R (e.g. CMP EJB21, JDO, Hibernate) + JDBC SQL (e.g. iBatis) + JDBC SP (e.g. also iBatis) in one app. O/R mappings are ideal for a small amount of data cached the whole transaction. Some O/R frameworks allow to cache data across transactions. Some CMP implementations offer the read only CMPs. Also O/R mappings allow RAD and DB independence.
   
So ignoring of O/R frameworks in your apps has to force you to use some other type of caching to get similar performance/scalability.

I know a few huge disasters where they spent 8 digits and then pulled out EJB, and everything worked.

This is usually caused by:
- too big HTTP or statefull session EJB session data
- using remote communication/interfaces with the fine grained component model or in one JVM
- using CMP entity EJB O/R framework as only one DB access framework

In this way will suck EJB2.1, but EJB3 and Spring also.
I do not believe that rewriting the EJB21 app to EJB3 or Spring/Hibernate app will bring a dramatical performance / scalability benefit

I offer Struts, Spring, and Hibernate

Stateless EJBs are also now being replaced by more flexible AOP frameworks like Spring

IMO the enterprise mainstream is going to be JSF + EJB3. JSF offers couple of implementations and GUI RAD tools already. And also JSF offers the component model, what is a huge benefit for RAD. Hibernate3 is going to implement EJB3 O/R API anyway. And the easiest migration is going to be from EJB2.1 to EJB3. I also do not believe that Spring/Hibernate is going to be superior to EJB3, especially because EJB3 will offer at least about 10 implementations.

EJB is overkill unless you have a need to do distributed transactions, have massive scalability

I do not believe that rewriting the EJB21 app to EJB3 or Spring/Hibernate app will bring a dramatical performance / scalability benefit.

Also IMO this migration will improve a developers productivity for about 10-15 percents. I just will not implement the ServiceLocator.

The biggest EJB21 disadvantage is that it does not support the rich OO domain model, but in my case I do not use it, because of the relational DB. I want to be a good friend with my DBA.

and even then, an intelligent O/R model and KISS DAO framework go a long way.

was discussed on the TSS that BEA CMP EJB2.1 can be faster than Hibernate

also Oracle implements the CMP entity EJB21 by TopLink, SUN by JDO

of course you should always combine the O/R and KISS JDBC frameworks inside of your DAO implementations

EJB's have HUGE overhead on the development and production sides.

I fail to see how small projects would benefit from EJB's.

I am able to implement a CRUD for one table in 10-20 minutes. JSF + EJB21. SUN Java Studio + SUN Java Creator.
I do not believe that EJB3 and right tools will boost significantly my performance. If you implement EJB21 with VI than I understand your concern.

the network saturation that results from session and cache replication is ENORMOUS...let's let databases do what they do - CACHE and QUERY

you do not need to replicate the session. If your app does not go down very often and session data are not too critical, you can just go for the load balancing.

Anyway the motivation for that is that DBs are not still able to scale horizontally very well. App servers can scale horizontally almost infinitely. So we are trying to move as much load / work as possible from DB to app server.

"there is no component market => no component model (like EJB) needed"

The EJB component model is good for the manageability. You get nice statistics about your EJBs and it helps you to optimize / trouble shoot your up. It is not so strong as profiling, but you can not use the profiling for the everyday production monitoring

We've been able interview and hire junior and mid-level developers who were almost all immediately productive because the either came in with say Struts experience or could benefit from the various books and forums on Hibernate and Spring and ramp-up quickly.

IMO the biggest amount of people, which are offered by job markets now, are skilled in EJB21 area. And they will and it will be the easiest for them to migrate to EJB3.

The JSF with a right tool like the SUN Java Creator requires much lesser study curve than Struts

Damin wrote:
.... the enterprise mainstream is going to be JSF + EJB3.

On Studio Creator I assume.
They desrve it then. I think that is shortest road for them to convert .NETv2.

Is there JSF+EJB large sites after 2 years of JSF?


.V
http://roomity.com

Damin wrote:.... the enterprise mainstream is going to be JSF + EJB3.

On Studio Creator I assume. They desrve it then. I think that is shortest road for them to convert .NETv2.

Nope. JSF with drag and drop IDEs are an answer to MS VB easy of development. Now you can have same RAD and productivity as VB developer, but still you are going to have a mature, scalable and open standart J2EE architecture.

Is there JSF+EJB large sites after 2 years of JSF?.V

well, JSF drag and drop IDEs are on the market only for last 6-12 months. It will take some time. Anyway JSF is pushed by SUN, Oracle and IBM at least. They also offer their RAD IDEs. We will see ...

BTW, you quoted my "I offer Struts, Spring, and Hibernate" without understanding the context. I was responding to the custom ORM framework, not EJBs.

We've been able interview and hire junior and mid-level developers who were almost all immediately productive because the either came in with say Struts experience or could benefit from the various books and forums on Hibernate and Spring and ramp-up quickly.

IMO the biggest amount of people, which are offered by job markets now, are skilled in EJB21 area. And they will and it will be the easiest for them to migrate to EJB3.

Perhaps. I guess we'll see. EJB3 is a direct response to the popularity of Spring and Hibernate. And JSF has yet to be a slamdunk. As I've said before, Struts, Spring, and Hibernate demostrate pretty clearly that software doesn't have to be a standard to be popular.

Being a standard doesn't guarantee success. I submit that people care less about standards and more about interoperability.

In addition, I doubt that the EJB2.1 people you list will have an easier time using EJB3 than the Spring/Hibernate people. The concepts of EJB3 are lifting from concepts popularized by those two pieces of software. This isn't just an issue of incrementing from 2.1 to 3. EJB2.1 is nothing like EJB3, but if you've used Spring/Hibernate, you've probably used DI, pojo-based persistence, and annotations.

In addition, I doubt that the EJB2.1 people you list will have an easier time using EJB3 than the Spring/Hibernate people. The concepts of EJB3 are lifting from concepts popularized by those two pieces of software. This isn't just an issue of incrementing from 2.1 to 3. EJB2.1 is nothing like EJB3, but if you've used Spring/Hibernate, you've probably used DI, pojo-based persistence, and annotations.

Should the concepts of EJB3 have been lifting from something like Spring? Should concepts popularized by Hibernate have gone to something like JDO?

EJB3 is only another mess after EJB2.

In addition, I doubt that the EJB2.1 people you list will have an easier time using EJB3 than the Spring/Hibernate people. The concepts of EJB3 are lifting from concepts popularized by those two pieces of software. This isn't just an issue of incrementing from 2.1 to 3. EJB2.1 is nothing like EJB3, but if you've used Spring/Hibernate, you've probably used DI, pojo-based persistence, and annotations.

Should the concepts of EJB3 have been lifting from something like Spring? Should concepts popularized by Hibernate have gone to something like JDO?
<br/>
EJB3 is only another mess after EJB2.

Why spring people not on EJB3 board, hibernate people not on JDO board? Are there better reasons than political reasons?

Only the marketing machine of IBM and BEA can turn EJB3 around. Will that happen soon?

To be precise, only the marketing machine of IBM and BEA can turn the fortune of EJB3 around, even an ill positioned EJB3.

Perhaps. I guess we'll see. EJB3 is a direct response to the popularity of Spring and Hibernate.

I agree

And JSF has yet to be a slamdunk.

Fair anough. It is havily pushed by SUN, Oracle and IBM. We will see. IMO I do not see Struts to be superior to JSF.

As I've said before, Struts, Spring, and Hibernate demostrate pretty clearly that software doesn't have to be a standard to be popular.

IMO it is not quit popular in the corporate area.

Being a standard doesn't guarantee success. I submit that people care less about standards and more about interoperability.

Standarts offer stability and investment protection. On other side very often they are not high-tech. My problem is that Struts, Spring, and Hibernate are only one implementation and you have to stay with them. E.g. JSF offers at least 4 implementations now. I like this type of cempetition.

In addition, I doubt that the EJB2.1 people you list will have an easier time using EJB3 than the Spring/Hibernate people. The concepts of EJB3 are lifting from concepts popularized by those two pieces of software. This isn't just an issue of incrementing from 2.1 to 3. EJB2.1 is nothing like EJB3

I do not see a big difference between EJB21 and EJB3. Just minor improvments. What do you mean?

Perhaps. I guess we'll see. EJB3 is a direct response to the popularity of Spring and Hibernate.

I agree

And JSF has yet to be a slamdunk.

Fair anough. It is havily pushed by SUN, Oracle and IBM. We will see. IMO I do not see Struts to be superior to JSF.

As I've said before, Struts, Spring, and Hibernate demostrate pretty clearly that software doesn't have to be a standard to be popular.

IMO it is not quit popular in the corporate area.

Being a standard doesn't guarantee success. I submit that people care less about standards and more about interoperability.

Standarts offer stability and investment protection. On other side very often they are not high-tech. My problem is that Struts, Spring, and Hibernate are only one implementation and you have to stay with them. E.g. JSF offers at least 4 implementations now. I like this type of cempetition.

In addition, I doubt that the EJB2.1 people you list will have an easier time using EJB3 than the Spring/Hibernate people. The concepts of EJB3 are lifting from concepts popularized by those two pieces of software. This isn't just an issue of incrementing from 2.1 to 3. EJB2.1 is nothing like EJB3

I do not see a big difference between EJB21 and EJB3. Just minor improvments. What do you mean?

It is not a question about superiority. Struts became ubiquitous WITHOUT being a standard. Being a standard is not a holy grail.

Of the three(Struts, Spring, Hibernate) Struts is FAR more popular in corporations than JSF. Both Oracle and BEA now offer direct support of Spring and Hibernate was so popular that it for the creation of EJB3.

How much more popular do these tools need to be? As for the number of implementations, more is not exactly better.

As for the differences between EJB 2.1 and 3, I guess "big" is subjective. The ability to run entity beans outside of the container is a huge departure from 2.1 as is the annotation and basic DI support, IMO.

Struts is FAR more popular in corporations than JSF.

I am not surprised. Firstly, struts has been around for a long time and there is a lot of investment in it. Secondly, newer approaches can take a long time to appear in corporations - just look at how long the latest JDKs take to be widespread. I have no doubt as to JSF's future success - having it both JSF and struts, I could never go back to struts. (Also, JSF, with its DI features, integrates very nicely with Spring).

Personally, I am a standards guy - I have used JDO in preference to Hibernate even though it lacked many of the features. I am prepared to make an exception for Spring because it is so non-intrusive on my code (and so useful).

The ability to run entity beans outside of the container is a huge departure from 2.1 as is the annotation and basic DI support, IMO.

Agreed.

Struts is FAR more popular in corporations than JSF.

I am not surprised. Firstly, struts has been around for a long time and there is a lot of investment in it. Secondly, newer approaches can take a long time to appear in corporations - just look at how long the latest JDKs take to be widespread. I have no doubt as to JSF's future success - having it both JSF and struts, I could never go back to struts. (Also, JSF, with its DI features, integrates very nicely with Spring).Personally, I am a standards guy - I have used JDO in preference to Hibernate even though it lacked many of the features. I am prepared to make an exception for Spring because it is so non-intrusive on my code (and so useful).

I have no problem with standards. I just believe that the talk that being a standard automatically ensures quality or success simply isn't true. Heck, how many people still use Log4j over JDK logging and which came first? :-)

I'm not married to any of the technology I use and pick things that allow me to jump ship should a superior solution(define superior) appear.

We've been looking at view technologies such as JSF and Tapestry with JSF as the lead not only because it is a standard, but after Struts, there is no clear lead and JSF appears to be gaining ground on everyone else.

I'm pretty comfortable with the migration path that Hibernate appears to offer to EJB3 and and very comfortable that Spring will integrate with EJB3 in its usual exceptional fashion.

I just believe that the talk that being a standard automatically ensures quality or success simply isn't true.

I agree that just being a standard doesn't automatically ensure quality, but being a standard that is implemented by several (or many) vendors (as with JDO and JSF, and, soon, EJB3) really helps.

Perhaps. I guess we'll see. EJB3 is a direct response to the popularity of Spring and Hibernate.

I agree

Another example of revisionist?

Perhaps. I guess we'll see. EJB3 is a direct response to the popularity of Spring and Hibernate.

I agree

Another example of revisionist?

Sure. The EJB3 spec team just happen to come with features that Spring and Hibernate had *before* the spec.

I think that Ted is a nice and smart guy but when he comes to Java and Distributed Systems....He is a good speecher.

(note I dont say he is a good developer/architect/designer)

Floyd, you started your blogs very recently. I did not know about your blogs because I was busy w/ my schedule.

But, somebody as busy as him kept an eye on your blog postings, and immediately jumped on one of your postings to publish remarks. First of all, these remarks are written in "inappropriate" style by that somebody.

About TSS: That somebody simply "used" TSS in order to gain some hype (in whatever possible and desperate way) in this process.

About Floyd: Floyd, then you wasted your important time in handling this affair (in your replies). So, let us now learn to ignore some people (ignore as in 'ignore', you see). I can still see Ed's vision as - TSS is for sensible people.

Floyd mentions that only 15% of EJB users actually deployed web and business tiers on physically separate tiers and says his book should have been called "EJB Distributed Design Patterns". But I've always had a hard time seeing in what cases you would ever want to split the web and business tiers at all. You're always going to be adding network and serialization overhead, and I just don't see the scenarios where you get that back. If you need to cluster, cluster the whole vertical stack. If you have long-lived business processes that use up resources, just move /those/ to another machine (say, via JMS), and keep your web tier talking directly to the business logic that it needs.

I've looked for studies or examples that demonstrate the benefits of splitting these tiers, but I haven't found any. If there are any such benefits, I'd like to understand them. Any pointers?

There is a Folwer person who put it as a "law" #1 - Don't distribute it. And I have similar feeling about why would you ever....

But what if you /have to/? Like, your webapp has to consume a service exposed as EJB by someone else, hosted over the network? Similarly when you want to expose something to someone else over the network that you know for sure is a Java client vs web services?

There is a Folwer person who put it as a "law" #1 - Don't distribute it. And I have similar feeling about why would you ever....But what if you /have to/? Like, your webapp has to consume a service exposed as EJB by someone else, hosted over the network? Similarly when you want to expose something to someone else over the network that you know for sure is a Java client vs web services?

IMO the most important is to implement any remote communication (if you have to ..) with the coarse grained component model (DataValueObject and reduce the communication frequence as much as possible). E.g. SOA (as the integration implemented by remote communication) is about high level communication of business processes (coarse grained) and not about low level component communication (fine grained)

Floyd mentions that only 15% of EJB users actually deployed web and business tiers on physically separate tiers and says his book should have been called "EJB Distributed Design Patterns". But I've always had a hard time seeing in what cases you would ever want to split the web and business tiers at all. You're always going to be adding network and serialization overhead, and I just don't see the scenarios where you get that back. If you need to cluster, cluster the whole vertical stack. If you have long-lived business processes that use up resources, just move /those/ to another machine (say, via JMS), and keep your web tier talking directly to the business logic that it needs.I've looked for studies or examples that demonstrate the benefits of splitting these tiers, but I haven't found any. If there are any such benefits, I'd like to understand them. Any pointers?

I agree with you. I also do not know any technical benefit of splitting of web and ejb tier. It is usually a non technical requirment. It is very common EJB21 mistake to implement finegrained component model communication as remote especially inside of the JVM. But this will suck even with EJB3 or Spring.

At about the same time (late 1990s) as the EJB spec was being written people (like me) involved in distributed systems were on to our second generation architectures which did not in general expose distributed object graphs to clients directly. We had all already been burnt by first generation distributed systems that exposed objects graphs as navigatable remote references and performed and scaled dreafully as a result.

It was bassically obvious to everyone at this time (except evidently the EJB spec designers) that distribution of "business objects" was a complete non starter. What later became knows as Martin Fowlers first law of distributed objects, do not distribute your objects, was common knowledge.

The second lesson that the EJB spec designers completely ignored was the huge body of knowledge surrounding OO databases and the fact that mapping objects into a persistent store is a *hard* problem and not one that can be trivialised into a simple object-database row mapping.

The third lession that the EJB spec writers ignored was the movement towards POJOs thorough unit testing and refactoring which would obviously require that business logic had a low dependency on framework APIs.

In short the EJB spec designer obvious had no real world distrubuted system design experience.

Paul.