In Is it ever best to use EJB components without facades in service oriented architectures? the EJB Advocate evaluates using various forms of "facades," including POJOs, HttpServlets, session EJB components, message driven beans, and entity EJB Home methods, in an attempt to get at the heart of what makes up a good service oriented architecture implemented with J2EE components.

The article is written as a simple dialogue between an EJB Advocate (Geoff Hambrick, in this case) and engineers in the field, and for intermediate programmers. The intent is mostly to show when and where certain access patterns for EJBs might be used - with a careful eye toward not making broad statements.

What do you think?

I really like the article. To sum up:

1. If you are using J2EE with EJB (SB, EB, ...), just use them, no need to *shield/hide* them with POJO/Delegates/what so ever. You are still independent since you are using those specified interfaces from JSR. They are standard, remember? You can also port them (with some efforts, of course ;-)) to run within other app servers which support J2EE spec...
-> Dependency to J2EE standard spec since you use those interfaces (Home, etc.) ;-).
-> But this makes you independent from different frameworks and you are independent from any products/implementations.

2. If you don't want to use EJBs because you think it is more easier to use POJO with Spring, Hibernate, ..., just use them, as they are. You are also independent (if you are using Open Source products) since you can install those frameworks (Spring, Hibernate) within all different app servers...
-> Dependency to frameworks/products/implementations (Spring, Hibernate).
-> You are independent from many app servers since you can easily install those frameworks within the app servers you will use.

What solution should you choose? No simple answer... ;-)

Check this thread from Will Hartung about this matter which is I really agree:
http://www.theserverside.com/news/thread.tss?thread_id=34541#174553

Cheers,
Lofi
EJOSA - OpenUSS

Well for entity beans and the like to really work yr db design(aka ER stuff) should be strong. As a developer you don't have much of a choice on some projects to go correct an existing DB with mind-boggling relations done by a novice. What works in such cases would be session ejbs hooked via a DAO called directly in yr struts application in such cases.
Even when using Hibernate yr relations in the DB should be good. (1-many, many-to-many, one-to-one plus non-redundancy for DB is all a must...I have come across dbs that simply violate everything you ever learned in school:)
Session ejbs called via struts scales well too.
I can't sometimes understand all the hype and time wasted about EJB patterns et al. They are simply an overkill if you ask me. Use POJOs instead of entity beans people and get on with thine life:) Screw session facades for entity ejbs and such ignoramous stuff...all an overkill.

...why use them at all? Discussion about
EJB patterns sometimes looks like trying
to resurrect a mummy ;-).

I agree EJB 1 and 2 were rubbish. EJB 3 is a totally different concept, and many have argued that it is sad they kept the EJB name, instead of calling it something different.

Stateless and stateful session beans are a relatively simply RPC mechanism. Stick SOAP on the front and they become the entry pt to your 'services'. No one ever really had a problem with stateless session beans. Stateful do create religious debate though.

Message Driven Beans (MDB) are very simple, and app servers seem an ok place for them to live.

Injection (IOC, Dependency ala Spring) is good, and embraces test driven dev (or agile, or whatever it will be called next). EJB3 does injection.

So, J2EE is now a new beast, they have kept the SLSB, SFSB and MDB. They have ditched EJB with rubbish XML config. They have sadly kept the complex JNDI stuff (config is way too hard for normal usage). And they have stuck in dependancy injection with a very simple OR technology (sadly called EJB3).

So the old J2EE patterns of Value Objects (DTO's) and the problems of where the biz funcs go (SLSB v's rich EJB) is changed.

I'd say J2EE is massively revitalised, and many of the older open source projects should fall on their swords and clear the field a bit. Even modern frameworks like Spring are going to struggle - why use their APIs when EJB3 provides a simple OR with injection, and SLSB provide simple RPC, and MDB provide simple messaging.

The field is opened up - look at Oracle's time to market with an EJB3 impl - in or outside the app server. Time to learn those annotations and investigate a new load of implementations.

Jonathan

Even modern frameworks like Spring are going to struggle - why use their APIs when EJB3 provides a simple OR with injection, and SLSB provide simple RPC, and MDB provide simple messaging.

I'm sure Spring won't struggle, because Spring provides a lot more than just dependency injection, and because dependency injection (and other parts of frameworks like Spring) are used for more than just being part of J2EE.

Spring is about hiding implementations. I can use OR and largely not care in my code if it is Hibernate, JDO or EJBs. I can use Remoting and not care if it is implemented as SOAP, RMI etc., the same for messaging etc. Spring does not compete with other frameworks like those you have mentioned, it enhances and integrates them.

<steve>
I'm sure Spring won't struggle, because Spring provides a lot more than just dependency injection, and because dependency injection (and other parts of frameworks like Spring) are used for more than just being part of J2EE.
</steve>

The point is that why you would use those extra API from Spring if you can use standardized API from JSR?
- Why should I use timer/scheduler capability of Spring with Quartz instead of using standardized MDB?
- Why should I use the remoting capability of Spring instead of using SSB Remote?
- Why should I use those Spring "templates" for Hibernate, JDBC, iBatis, etc. if I could use standards like EJB3, JDO, JDBC (I'm sure it's just a matter of time to see JDBC offering easy to use interfaces - again like I said: a process -> life cycle, see my thread above).

I think this is what Jonathan is trying to say... Like I said before, Hibernate will be an implementation of EJB3 but what will Spring be? An implementation of J2EE API (app server)? I don't think so... :-)

Cheers,
Lofi.

FYI: Did you see the JDBC RowSets in java 5?

It's on http://java.sun.com/developer/technicalArticles/releases/j2se15/.

eg:

WebRowSetImpl wrs = new WebRowSetImpl(); wrs.setCommand("SELECT COF_NAME,TOTAL FROM COFFEES"); wrs.setUsername("postgres");
wrs.setPassword("");
wrs.setUrl("jdbc:postgresql:test");
// executes command and populates webset all coffees wrs.execute();
// moves cursor to the first row of wrs
wrs.absolute(1);
// reset total field to 10
wrs.updateInt(2, 10);
// finishes edits to this row
wrs.updateRow();
// writes new total to the data source
wrs.acceptChanges();
// also exports rowset in XML format
wrs.writeXml(System.out);
wrs.close();

Sorry for the bad format above!

FYI: Did you see the JDBC RowSets in java 5?

Its about time. I used to do this kind of stuff with Visual Basic 6 ADO components back in the mid 90's.

Disconnected RecordSets (oops I mean ResultSets). What a concept.

Now give me a full-fledged web/swing grid component that can take a CachedRowSet or WebRowSet and I'll almost be back to the UI productivity of yester-year. Back when you could get a full-featured front-to-back client/server app up and running in a matter of days - not weeks. Oh yeah, give me a report writer that can do the same thing.

Could it be that someone has figured out that there is a whole sector of Enterprise apps that don't have to scale to Amazon size but do need to be whipped up quickly and be easily maintainable? Will it be possible to finally ween some companies off Microsoft Access and Visual Basic 6?

<steve>I'm sure Spring won't struggle, because Spring provides a lot more than just dependency injection, and because dependency injection (and other parts of frameworks like Spring) are used for more than just being part of J2EE.</steve>The point is that why you would use those extra API from Spring if you can use standardized API from JSR? - Why should I use timer/scheduler capability of Spring with Quartz instead of using standardized MDB? - Why should I use the remoting capability of Spring instead of using SSB Remote? - Why should I use those Spring "templates" for Hibernate, JDBC, iBatis, etc. if I could use standards like EJB3, JDO, JDBC

Because Java is more than J2EE, and because abstracting from the details of a specific API (providing you don't lose power) is a good thing. The Spring APIs are good because they hide complexity without losing power. Standards come and go in terms of popularity and use. Spring does not replace JSR standards, and does not prevent you using them. Instead, it wraps them, integrates them and hides their complexity.

I am a strong supporter of the use of such standards. I use JSF and JDO, but I would find development harder if I could not use Spring with these APIs.

I guess you are saying you prefer Spring API's. I've moved through many java projects, each with different approaches favoured. Hardly ever do people simply use the standard API's. Usually this comes down to boredom - it's not very exciting using the standard API's.

However, the selected API's and flavours that are selected are never the same from place to place. It all comes down to the first 3 techies on the project who had great fun, creating a nightmare for all who follow.

Exposing the standard API's is a far more 'empowering' approach. Let all the developers learn and benefit, and reduce the training times etc.

I admit that spring at the moment is brilliant. I hope that the small, free app server which does slsb, mdb, ejb3 entities will also be brilliant. One which comes with no legacy api's and clients. One focused on being small, and open, and just implementing the standards and nothing more.

Jonathan

It all comes down to the first 3 techies on the project who had great fun, creating a nightmare for all who follow.

That is a gem! I will have to remember it the next time I am one of the 3.

Kit

I guess you are saying you prefer Spring API's.

No, I'm not - some of them are pretty messy IMO. I'm saying that I like the ability to use alternative standard APIs. If I want to be able to easily switch between RMI and SOAP for example.

I hope that the small, free app server which does slsb, mdb, ejb3 entities will also be brilliant. One which comes with no legacy api's and clients. One focused on being small, and open, and just implementing the standards and nothing more.Jonathan

I don't understand the 'and nothing more' argument. If there are great tools to allow easier use of standards, why not use them? I think my point about abstracting from standards is made by your mention of 'legacy API's'. Todays standards eventually become legacy. Abstracting from them protects code.

<jonathan>
I guess you are saying you prefer Spring API's. I've moved through many java projects, each with different approaches favoured. Hardly ever do people simply use the standard API's. Usually this comes down to boredom - it's not very exciting using the standard API's.
However, the selected API's and flavours that are selected are never the same from place to place. It all comes down to the first 3 techies on the project who had great fun, creating a nightmare for all who follow.
Exposing the standard API's is a far more 'empowering' approach. Let all the developers learn and benefit, and reduce the training times etc.
I admit that spring at the moment is brilliant. I hope that the small, free app server which does slsb, mdb, ejb3 entities will also be brilliant. One which comes with no legacy api's and clients. One focused on being small, and open, and just implementing the standards and nothing more.
</jonathan>

Jonathan, I'm with you! Since I come from education/training area, I see Java: J2SE, J2EE, J2ME as a whole: Learn Once Use Everywhere and not only Write Once Run Anywhere!

<steve>
I don't understand the 'and nothing more' argument. If there are great tools to allow easier use of standards, why not use them? I think my point about abstracting from standards is made by your mention of 'legacy API's'. Todays standards eventually become legacy. Abstracting from them protects code.
</steve>

Ahm... todays frameworks can also become legacy, so that we have the same situation here and using an abstraction layer which can become legacy means: double legacy (framework API + standard API)! :-) So, I see here much more trouble... Abstraction level is good, but not in this case... If you want to add your abstraction level use MDA (which is also standardized, at least they try to do so) or so...

Cheers,
Lofi.

<steve>I don't understand the 'and nothing more' argument. If there are great tools to allow easier use of standards, why not use them? I think my point about abstracting from standards is made by your mention of 'legacy API's'. Todays standards eventually become legacy. Abstracting from them protects code.</steve>Ahm... todays frameworks can also become legacy, so that we have the same situation here and using an abstraction layer which can become legacy means: double legacy (framework API + standard API)! :-) So, I see here much more trouble... Abstraction level is good, but not in this case... If you want to add your abstraction level use MDA (which is also standardized, at least they try to do so) or so...Cheers,Lofi.

I disagree. The sort of abstraction that dependency injection (as in Spring) encourages is very robust against the tendency of things to become legacy. Firstly, dependency injection forces separation of logic and concerns, secondly Spring works in the background, using XML configuration files which describe the wiring, proxying or aspects of components. It is in the nature of XML that it is declarative and transformable - it describes relationships in a portable way. A well-written program just won't use that much of the Spring API - most of the work will be done transparently through the wiring and configuration.

As for MDA, well, I admit I don't know much about it. From what I have seen it does look suspiciously like the failed attempts to design software at very high levels that I saw in the 1980s - the 'fourth generation languages'.

<quote>
I disagree. The sort of abstraction that dependency injection (as in Spring) encourages is very robust against the tendency of things to become legacy. Firstly, dependency injection forces separation of logic and concerns, secondly Spring works in the background, using XML configuration files which describe the wiring, proxying or aspects of components. It is in the nature of XML that it is declarative and transformable - it describes relationships in a portable way. A well-written program just won't use that much of the Spring API - most of the work will be done transparently through the wiring and configuration.
</quote>

Steve, remember EJB3 offers you the same... what I meant is the rest of the APIs...

<quote>
As for MDA, well, I admit I don't know much about it. From what I have seen it does look suspiciously like the failed attempts to design software at very high levels that I saw in the 1980s - the 'fourth generation languages'.
</quote>

You should check AndroMDA for introduction: http://www.andromda.org. A good place to start... ;-)

Cheers,
Lofi.

Steve, remember EJB3 offers you the same... what I meant is the rest of the APIs...

Well, to be precise, EJB 3 will offer a fairly small subset of the IoC and AOP features that Spring has offered in a production release since March 2004.

<quote>
Well, to be precise, EJB 3 will offer a fairly small subset of the IoC and AOP features that Spring has offered in a production release since March 2004.
</quote>

yes, this is true and I think there will be always a place to make a better thing, no doubt on this. The question is that whether we will always have to play dog and cat? Catching each others? (see my thread above: life-cycle):
- spec is out -> better solution, offering a framework.
- taken the idea of the framework into spec.
- spec is coming out with that better solution.
- and so on...

Is it not better to join JSR (spec) to make the better solution directly integrated into the spec? So, we don't have any dog-and-cat-catch-me-game? Just like what Groovy and Hibernate did? Like Jonathan said, long term security in knowledge management is an important thing (long term code management, long term developers education). And this is where Java (J2SE, J2ME, J2EE) makes the different with all those standards, IMO. I also know that every consultants, devs, have to make a distinction in their career (especially in very competitive area like our industry), but IMO always build a new framework for this purpose just don't bring us any further...

Rod, if you think that Spring is a very good solution why don't you join and put Spring into JSR (J2EE, EJB, what so ever)?

Cheers,
Lofi.

Hi all,

I was asleep while the discussion moved on. Lots of good points here.

I still think that the branding of EJB3 is sad. Basically it's hibernate and spring IOC without XML config. They should have called it OREE or something. Would avoid lots of confusion.

Jonathan

Steve, remember EJB3 offers you the same... what I meant is the rest of the APIs...

EJB3 certainly doesn't offer all that Spring does, and even if it did, not all Java is on J2EE.

I guess you are saying you prefer Spring API's. I've moved through many java projects, each with different approaches favoured. Hardly ever do people simply use the standard API's. Usually this comes down to boredom - it's not very exciting using the standard API's.However, the selected API's and flavours that are selected are never the same from place to place. It all comes down to the first 3 techies on the project who had great fun, creating a nightmare for all who follow.Exposing the standard API's is a far more 'empowering' approach. Let all the developers learn and benefit, and reduce the training times etc.I admit that spring at the moment is brilliant. I hope that the small, free app server which does slsb, mdb, ejb3 entities will also be brilliant. One which comes with no legacy api's and clients. One focused on being small, and open, and just implementing the standards and nothing more.Jonathan

+1

You are perfectly right!
Although I haven't checked all of it yet
it looks quite easy to work with from the
developer's standpoint.

I think the former EJB approach was just too technology centric. It looks bright in theory but is
a nightmare in practice.
The makers fell so in love with their vision of
distibuted objects that they totally forgot
the poor developer who should find his way through
those interfaces, deployment descriptors and stuff
in addition to the inevitable permanently changing
customer requirements, time pressure and the like.

The choices seem to be:

1. Use J2EE Patterns (choose a wheel from many vendors)
2. Use some Open Source framework's patterns (choose a special wheel from one vendor).
3. Design your own framework and use it's patterns (build your own wheel).
4. Screw patterns and hack away happily (who needs wheels, this is a raft we're building).

Choice 1, as described quite well in the article, covers pretty much every scenario the most twisted architect can come up with. Barrier to entry is high due to learning curve, but once over this you gain a security and transaction contexts and a managed environment.

People who say J2EE is nonsense don't understand the concept, and luckily for them there's lots of work (my aunt wants a website)- but I'd wrangle a guess that the big dollars are in J2EE projects (my company wants to securily integrate multiple systems and use system-spanning transactions).

J2EE - Just Use It!

People who say J2EE is nonsense don't understand the concept

I believe that most people do not understand Enterprise development in general and that is why J2EE (and .NET) seems so complex.

People who say J2EE is nonsense don't understand the concept

I believe that most people do not understand Enterprise development in general and that is why J2EE (and .NET) seems so complex.

+1

That's why I am would like to see the line between a Java Developer and a Java Enterprise Developer

People who say J2EE is nonsense don't understand the concept

I believe that most people do not understand Enterprise development in general and that is why J2EE (and .NET) seems so complex.

... to them, at least. :-)

There are no simple solutions to complex problems. But there is a tendency to use the tool with the most features even for simple jobs, when a more lightweight tool would be fitting better.

When people complain that J2EE (and more specifically, EJB) is too complex, what they really mean is: "I could have solved my specific problem easier." The real problem is that they do not know their toolbox yet, and pick the most shiny, powerful and (possibly) overhyped tool they can afford.

Just my 2c,
Lars

There are no simple solutions to complex problems. But there is a tendency to use the tool with the most features even for simple jobs, when a more lightweight tool would be fitting better.

A fair point, but I would argue that there is an increasing tendency to use the most lightweight tools in a way that can cause great problems if the application needs, at some future date, to grow to deal with larger problems and more demand.

[...] I would argue that there is an increasing tendency to use the most lightweight tools in a way that can cause great problems if the application needs, at some future date, to grow to deal with larger problems and more demand.

I agree that the hype of lightweight tools ("Better, Faster, Lighter Java") is inherently as evil as the hype of EJB was five years ago. The decision what kind of component framework to use (lightweight IoC-Container vs. heavyweight EJB-Container) should be made by an experienced architect (not a markitect) on behalf of technical reasons.

On the other hand, though, it is impossible to anticipate every demand that an enterprise will have to face in its long lifecycle. A lightweight solution can be more lean and mean than a fully-fledged EJB solution, and has the potential to grow as versatile as the required modules (message queue, transaction manager, etc.) are added when needed. However, you're not going to be on the safe side regarding the compatibility of the deployed software modules -- might be that your message queue solution won't cooperate with the transaction manager.

So its a bit like the trade off between shopping for a PC from Walmart or configuring your own by buying the required parts from the local electronics store... :-)

'Nough said,
Lars

Disclaimer: Currently, I work on a long-running project where EJB technology is absolutely required and used thoroughly. On the other hand, I already have ported a complex EJB-based project towards JDO, and have worked with Hibernate as well, so I'm biased against neither approach.

On the other hand, though, it is impossible to anticipate every demand that an enterprise will have to face in its long lifecycle. A lightweight solution can be more lean and mean than a fully-fledged EJB solution, and has the potential to grow as versatile as the required modules (message queue, transaction manager, etc.) are added when needed. However, you're not going to be on the safe side regarding the compatibility of the deployed software modules -- might be that your message queue solution won't cooperate with the transaction manager.So its a bit like the trade off between shopping for a PC from Walmart or configuring your own by buying the required parts from the local electronics store... :-)'Nough said,LarsDisclaimer: Currently, I work on a long-running project where EJB technology is absolutely required and used thoroughly. On the other hand, I already have ported a complex EJB-based project towards JDO, and have worked with Hibernate as well, so I'm biased against neither approach.

I would say that some lightweight solutions do have the potential to grow. Others don't, or at least can make it very difficult. This is where, I believe, Spring really helps (I am a recent convert, which is why I am so enthusiastic). By abstracting your code from the APIs that do things like messaging and persistence, you can switch relatively easily between different approaches.

The choices seem to be:1. Use J2EE Patterns (choose a wheel from many vendors)2. Use some Open Source framework's patterns (choose a special wheel from one vendor).3. Design your own framework and use it's patterns (build your own wheel).4. Screw patterns and hack away happily (who needs wheels, this is a raft we're building).Choice 1, as described quite well in the article, covers pretty much every scenario the most twisted architect can come up with. Barrier to entry is high due to learning curve, but once over this you gain a security and transaction contexts and a managed environment.People who say J2EE is nonsense don't understand the concept, and luckily for them there's lots of work (my aunt wants a website)- but I'd wrangle a guess that the big dollars are in J2EE projects (my company wants to securily integrate multiple systems and use system-spanning transactions).J2EE - Just Use It!

Fanboy with slight spelling problem.

Loser with nothing of value to add to discussion.

Fanboy with slight spelling problem.

Please indicate the spelling problems.

Grammar possibly, but not spelling.

People who say J2EE is nonsense don't understand the concept

So in your opinion everybody who has critical notes on J2EE doesn't understand the concept?
That is, appart from a lame argument, a very naroow minded remark. So let's come with some real arguments:

J2EE is nonsence because it's an invasive concept. For instance your Entity beans have to extend EjbHome. Furthermore your attributes have to be declared public making it imposible to reuse the objects.

Statefull session beans are most of the time useless. Because we are working in tiers sessions are managed on a higher level.

So yes, pretty much of J2EE is useless :)

People who say J2EE is nonsense don't understand the concept

So in your opinion everybody who has critical notes on J2EE doesn't understand the concept? That is, appart from a lame argument, a very naroow minded remark. So let's come with some real arguments:J2EE is nonsence because it's an invasive concept. For instance your Entity beans have to extend EjbHome. Furthermore your attributes have to be declared public making it imposible to reuse the objects.Statefull session beans are most of the time useless. Because we are working in tiers sessions are managed on a higher level.So yes, pretty much of J2EE is useless :)

I think not. J2EE is far more than EJBs. There are some very high-performance commercial sites that make use of virtually all of J2EE.

<blockquoteI think not. J2EE is far more than EJBs. There are some very high-performance commercial sites that make use of virtually all of J2EE.So, that's doesn't tell us a slightest bit whether it's good practice. There are other ways to get from A to B. And as stated there are enough arguments to use a different road.

Usually "the bigger the company, the older the techniques" applies. This because of the low risc and good service contracts. But not because it's a dazzling technique.

Ejb's are poorly testable, maintainable and reusable. It's a poor technique that has helped Enterprise developers in the right direction. No it's simply time, as always, to move on :)

<blockquoteI think not. J2EE is far more than EJBs. There are some very high-performance commercial sites that make use of virtually all of J2EE.

So, that's doesn't tell us a slightest bit whether it's good practice.
I would suggest it does. It shows that J2EE (even using EJBs) can work as intended and provide high-performance and scalable applications.

There are other ways to get from A to B. And as stated there are enough arguments to use a different road. Usually "the bigger the company, the older the techniques" applies. This because of the low risc and good service contracts. But not because it's a dazzling technique.

Who cares about dazzling technique? In my opinion there is a worrying trend to think that server-side applications are simple, and simple tools and APIs can be used to develop them. I have seen too many projects fail because there was not enough architecture or planning to make the applications scalable and extendable.

J2EE is nonsence because it's an invasive concept. For instance your Entity beans have to extend EjbHome.

What? I believe entity beans do not have to extend anything. All they have to do is implement EntityBean.

Furthermore your attributes have to be declared public making it imposible to reuse the objects.

This was a requirement circa WWII. Now, an entity bean only declares abstract getters and setters for persistent fields. Attributes on entity beans are no longer needed.

So in your opinion everybody who has critical notes on J2EE doesn't understand the concept?

You're proving the point quite well. :)

You're proving the point quite well. :)I'm not interested in this type of childish discussion techniques.

And why do I want to implement an interface for my entities?? Stil not reusable.

Mark...take a close look at EJB3. Nothing extends EJB framework interfaces anymore; it's just your business interface for session beans and your POJO entity object for entity beans. (And actually entity beans haven't had public attributes for over four years...)

Randy

Mark...take a close look at EJB3. Nothing extends EJB framework interfaces anymore; it's just your business interface for session beans and your POJO entity object for entity beans. (And actually entity beans haven't had public attributes for over four years...)Randy

Maybe I will. But I fear the come to late. Other frameworks are becomming defacto standard. I just follow the mainstream trend, and ejb simply isn't it :)

It's very easy to read some articles and join the crowed, give final judgements!!!

It's very easy to read some articles and join the crowed, give final judgements!!!

That's not the case. I think it's pointless to use an application server. The only real advantage of an application server offers is standard remoting.

Portabilty?
I don't care, it's an enterprise application, you can write platform specific code.

Persistence?
Enough defacto standard framework around (ibates, hibernate) that does the job better.

IoC is good, POJO persistence is also good, but standards take time to change.

You mentioned remoting, what about JMS?

Portabilty?I don't care, it's an enterprise application, you can write platform specific code.

You may not care, but a large section of the IT industry does; hence the success of open standards and Unix and even semi-portable languages like SQL.

Portability is an important protection of the investment in development time and expense.

Persistence?Enough defacto standard framework around (ibates, hibernate) that does the job better.

Better than what? There is good evidence that implementations of real JSR standards can provide at least equal performance.

hence the success of open standards and Unix and even semi-portable languages like SQL.Portability is an important protection of the investment in development time and expense.

I'm not saying that nothing should be reusable, I'm just saying that it's useless (espacially for your customer) to write expensive generic code where you actually should write specific code.

For instance Hibernate doesn't discard the fact that there are several different database servers. All with there own subset of SQL. Why not use that, well hibernate does and has neatly encapsulated it for you in Dialect classes. A great example of being specific when you have to.

Take a look at Spring and find out what real reusability means instead outdated concept of EJB's. Reusable property editors, factory beans, method interceptors, and so on...

Hi Mark,

Do you think Spring is the end? The last open source framework. The final implementation that will rule them all.

Or do you think it's a great moment in time. Embracing lots of good principles, helping to stear developers and architectures. And from this will evolve better standards, simpler platforms and new technologies.

JBoss is very much alive, and ejb2 is irrelevant to it's future. But Hibernate is not. So much so that they hired Gavin, and he contributed to EJB3 and they are writing a working EJB3 implementation at this moment. So are Oracle. Not sure about IBM or Weblogic etc but I guess they are too.

My guess is that Spring will go into decline, because it will be solving problems of J2EE complexity that no longer exist. Why use complex spring XML configs? Why use bespoke API's to hide simpler EJB3 api's. I realise you are an evangelist, who has invested training in spring. But there will be new things v soon, and I personnally can't wait to ditch huge xml configs and move logic back into the code base (even if they are annotations).

Be fun to see who is the better self publicist - Spring or JBoss. Oh how the pies will fly. Personally I hope its a new bunch of independant open source folks - we need the next generation to start standing on soap boxes.

Jonathan

Hi Mark,[..]Or do you think it's a great moment in time. Embracing lots of good principles, helping to stear developers and architectures. [..]

As you could have read in one of my earlier posts, this is the way I think of every technique.

The reason why I have more faith in spring is because of the fact that it embraces AOP. I think this new way of thinking (rather in aspects then in objects) has more future. Though the framework emerged as an answer to the poor initial design of ejb's it became a lot more. Just like the power of Java can not be found anyware near Applets.

Note: spring doesn't in anyway exclude EJB's, that's up to the develloper. It only makes it easier to use different frameworks.

Hi Mark,

I'm not convinced that AOP is the reason for embracing any framework. I know folks are using it for transaction boundaries around there 'services' (often simply an RPC).

I can understand the argument that it vastly simplifies the db code - exceptions etc move out of the code. I personally haven't done this, I prefer being close to the DB and coding up this stuff. Mainly because of the huge problems experienced with toplink and hibernate session caches in multi threaded spring servers.

Anyway, I respect your choices, they just aren't mine.

Jonathan

Seems you are highlighting a tiny specific bit. I'm in favour of the concept of 'sepperation of concerns', AOP merely simplifies this:

A property editor should format a property
A validator should validate a property
A manager should delegate the persistance
etc

Now an aspect of a manager could be that before making the property persitent it should have been formatted and validated. I could write this in my code but then my class immediatly doesn't do what it suppose to do. It does way more, leaving you with poor code.

'sepperation of concerns'
As opposed to excapsulation.

Interceptor chains configured through XML.
As opposed to reusable objects and polymorphic API's.

I wonder what they are teaching new grads these days as best practice, or if they hold their hands up in the air and say "dunno, take your pick".

Todays pattern is tomorrows anti pasta. Singletons anyone?

Jonathan

Excapsulation....It should be a word.

nothing is "opposed to", it simply works perfectly together :)
your post therefore, is false.

'sepperation of concerns'As opposed to excapsulation.Interceptor chains configured through XML.As opposed to reusable objects and polymorphic API's.I wonder what they are teaching new grads these days as best practice, or if they hold their hands up in the air and say "dunno, take your pick".Todays pattern is tomorrows anti pasta. Singletons anyone?Jonathan

I would say that the things that you are labelling as 'opposed' aren't opposed at all.

For example, separation of concerns is a much broader idea than just encapsulation. Encapsulation is 'hiding the details' of what a method does. Separation of concerns is not having different 'concerns' (e.g. persistence, security, logging) mixed up in the same code.

The IoC and AOP workings of systems like Spring aren't opposed to, or a similar name for, reusable objects and APIs - they help make objects and APIs more re-usable. For example, If you take out from classes the code that explicitly links objects together, and have that in some easily managed external form (such as a script or XML file), this makes the classes more re-usable.

"Separation of concerns is not having different 'concerns' (e.g. persistence, security, logging) mixed up in the same code."

In this AOP view you mix it up in an ascii file. Not only that you dramatically change runtime behaviour through the use of ascii. You effectively create your own runtime harness/environment for the java code. You can even hijack function calls and invisibly redirect them elsewhere.

I see it as complexity for no gain, a risk to the stability of my software, and the addition of complexity. You see this as a powerful tool. All the things I consider negative you consider to be positive. Thats OK, doing the correct thing in software is purely a perspective, there is no right or wrong.

I'm also a pragmatist. If the industry goes that way for a year or two I will buy into it, but it hasn't happened yet in my experience. People play with AOP, and they drop it - in my experience.

Jonathan

If I alter or delete a class your program is broken too.
It simply seems you just haven't taken the time make yourself familiar with these concepts. Otherwise you simply wouldn't be making such statements.

IOC and AOP, IMO, are just new ways to increase code's manageability, by concentrating in one place what would otherwise be spread all over your code, helping incresing cohesion and lowering coupling. So with IoC you wire objects in one place, instead of all over your code. And with AOP, you change app's behaviour in one place, instead of spread all over your code. Of course, like any other tool, there can be abuses, so it is up to us to develop best practices regarding these new techniques. And when these best practices and their implications are mature and well known, then we'll have a clearer understanding of these tool's value in development. IMO it is still too early to have this complete evaluation now.

Regards,
Henrique Steckelberg

I agree they are a new way. I'd disagree if you thought they were the only way (not that you have said this).

OO models can be as elegant and manageable. In fact, I'd argue far more manageable. Try entering a large mature Spring project with huge autowired code bases and ancient docn. Compare this to a compile time system and it is has been my experience that the compile time system is easier to get into.

This is actually more to do with the IDE's than anything else. But configs that have such wide ranging impact are no longer simply configs - they are part of the structure of the solution. They are part of the setup of a system that requires integration and regression. But far too many developers still see them as config files, rather than as part of the code.

And when you see them as part of the code you start wondering about how appropriate it is...

IMHO.

Jonathan

I agree they are a new way. I'd disagree if you thought they were the only way (not that you have said this).OO models can be as elegant and manageable. In fact, I'd argue far more manageable. Try entering a large mature Spring project with huge autowired code bases and ancient docn. Compare this to a compile time system and it is has been my experience that the compile time system is easier to get into.This is actually more to do with the IDE's than anything else. But configs that have such wide ranging impact are no longer simply configs - they are part of the structure of the solution. They are part of the setup of a system that requires integration and regression. But far too many developers still see them as config files, rather than as part of the code.And when you see them as part of the code you start wondering about how appropriate it is...IMHO.Jonathan

The wiring of components in Spring does not have to be done in configuration files - it can be done in a scripting language or as Java Code, so it can be checked at compilation. The point is that the classes implementing logic should not have to know how to wire themselves together. This means that the classes can be re-used in different contexts and independently tested. This is why 'wiring', be it in configuration files or code, is appropriate.

I agree with injection - great for testing. Auto-wiring has created deployment issues.

I admit it's about 9 months since playing with AOP - so I'll bow out now.

Thanks for your comments.

Cheers,
Jonathan

I agree with injection - great for testing. Auto-wiring has created deployment issues.I admit it's about 9 months since playing with AOP - so I'll bow out now. Thanks for your comments.Cheers,Jonathan

Yes - I agree with your opinion of auto-wiring.

I agree they are a new way. I'd disagree if you thought they were the only way (not that you have said this).OO models can be as elegant and manageable. In fact, I'd argue far more manageable. Try entering a large mature Spring project with huge autowired code bases and ancient docn. Compare this to a compile time system and it is has been my experience that the compile time system is easier to get into.This is actually more to do with the IDE's than anything else. But configs that have such wide ranging impact are no longer simply configs - they are part of the structure of the solution. They are part of the setup of a system that requires integration and regression. But far too many developers still see them as config files, rather than as part of the code.And when you see them as part of the code you start wondering about how appropriate it is...IMHO.Jonathan

I'm a big fan of Spring but I agree with your observation. The config file is part of the code base. Being defined in xml files make it the most brittle part of the system. You really need to implement full integration testing to make sure you haven't screwed it up. Developers in one project were getting it wrong a lot of the time so we implemented a convention and wrote up a hacked up ant task to validate the xml files. Hopefully, spring will provide better support in the future.

dean

The org.springframework.test package provides useful support for integration testing.

The org.springframework.test package provides useful support for integration testing.

Rod,

A question for you. I have used this package very successfully when testing the DAO layer. Works like a charm.

But can you use this approach on the business layer or even in the UI action layer?

Dino

But can you use this approach on the business layer or even in the UI action layer?

Yes, I've certainly used it against the business layer, and it works well. Always in addition to unit tests for that layer, which will use mock or other test-time DAO implementations.

Testing the UI action layer is also possible this way, although sometimes a bit more painful because of the Servlet API (assuming you're talking of web apps). I believe that Spring Web Flow ships with an extension of an org.springframework.test base class to facilitate integration testing web flow actions.

Rgds
Rod

Mark,

Accusing folks of not being familiar with concepts as a part of an argument is a pretty immature approach.

I offer the position that runtime config creates more problems than I need. Your response is that I don't know anything about the technology.

Pity really, as I am interested in perspectives. Changing teams opens you to new technologies. When those teams all evaluate something over a period of years and all discard a certain technology then it is either immature, or irrelevant. AOP is yet to prove itself mature or relevant. Unlike IOC which hit the public awareness at about the same time, and is being adopted everywhere.

AOP is being used for niche work, and loads of developers frankly do not care about it because of this. I have only seen one great application and that was transaction and exception handing in a SOA - but there were side effects. The aspects themselves had to have a fairly intensive understanding of the context - which started to couple them to use cases, otherwise exception handling was too generic.

Jonathan

Well I'm probably right then since, for instance, AspectJ works at compile time and doesn't use a centralized configuration location. It does sepperate concerns.

That's why I said make yourself more fimiliar with AOP, since it's a concept, not an implementation. At this moment it only leads to false claimes.

"Separation of concerns is not having different 'concerns' (e.g. persistence, security, logging) mixed up in the same code."In this AOP view you mix it up in an ascii file.

No you don't. If, for example, I want a method to be transactional, I can simply add an attribute to the method to indicate this, then in configuration say what code is to use used to implement the transactional behaviour. This is clean and simple.

Not only that you dramatically change runtime behaviour through the use of ascii. You effectively create your own runtime harness/environment for the java code. You can even hijack function calls and invisibly redirect them elsewhere. I see it as complexity for no gain, a risk to the stability of my software, and the addition of complexity.

You can do this, but any technique can be used badly. When used well it can get rid of large amounts of boilerplate code that would otherwise be embedded in business logic. Furthermore, changes to the behaviour added as an aspect can be done in one place, rather than in embedded code in numerous methods. This can make code far cleaner and more maintainable.

People play with AOP, and they drop it - in my experience.Jonathan

In my experience AOP has a slow rate of adoption, but once used developers tend to find situations where is it a very good fit (transactions, logging etc).

I'm just saying that it's useless (espacially for your customer) to write expensive generic code where you actually should write specific code.

Writing generic code is not expensive. It is one of the key features of Java.

For instance Hibernate doesn't discard the fact that there are several different database servers. All with there own subset of SQL. Why not use that, well hibernate does and has neatly encapsulated it for you in Dialect classes. A great example of being specific when you have to.Take a look at Spring and find out what real reusability means instead outdated concept of EJB's. Reusable property editors, factory beans, method interceptors, and so on...

So after having said about how specific code should be written, you are talking about how easy it is to write portable code with Hibernate, Spring etc? Hibernate has it's own portable query language, which then translates to optimised specific SQL.

So after having said about how specific code should be written, you are talking about how easy it is to write portable code with Hibernate, Spring etc? Hibernate has it's own portable query language, which then translates to optimised specific SQL.

No I'm telling which parts should be specific and which parts should be abstract. It was merely an example. Please look at it at a more abstract level, not a progmatic one.

And I realise that for people who have spend all there training on J2EE, my posts can be considered quiet invasive. But try to be open minded because the way we develop is always evolving.

So after having said about how specific code should be written, you are talking about how easy it is to write portable code with Hibernate, Spring etc? Hibernate has it's own portable query language, which then translates to optimised specific SQL.

No I'm telling which parts should be specific and which parts should be abstract. It was merely an example. Please look at it at a more abstract level, not a progmatic one.

As I understood it, you stated that that products like Hibernate can allow you to access the specific features of the underlying database etc. However, just because they allow this does not mean you have to use it like this. Plenty of developers use tools like Hibernate in a portable fashion. So, I still don't see what parts you are implying should be 'specific', or why.

And I realise that for people who have spend all there training on J2EE, my posts can be considered quiet invasive. But try to be open minded because the way we develop is always evolving.

I'm not a 'J2EE' developer: I am a Java developer, and some of my applications run on J2EE. I like to have general-purpose code and re-use tools on J2EE and J2SE. This is why I like portability - it makes me more productive. Writing specific code for a platform when, with a little more work, you could end up with portable code that could potentially save you and your client a lot of time and money, seems to me to be moving backwards, not evolving.

Since I'm not able to clarify the portability issue to you the second part of your statement is redundant. I think in general we agree :)

Mark, why do you use Java. You could have used any native language supported by the mainframe you work for.

Standards are not just for inter-compatibility.. It gives you a future-proof system. Future - in terms of technology itself and future in terms of the technology vendor. Don't tell me that enterprices never change their vendors. I know companies who have spent fortunes just for migration projects.

J2EE is nonsense[...]

THAT is a narrow-minded remark, if any.

[...]because it's an invasive concept.

True, but no more invasive than a lot of other technologies. IoC is not an invasive concept? I don't think, if you consider as "invasive" anything that forces you to do things some arbitrary way. All frameworks exhibit this characteristic (with the possible exception of AOP).

your Entity beans have to extend EjbHome

What?

Furthermore your attributes have to be declared public making it imposible to reuse the objects.

I insist: what?

Because we are working in tiers sessions are managed on a higher level.

Dude, what are you talking about? "Statefull" is the important word in "Statefull session EJB", not "session".

So yes, pretty much of J2EE is useless :)

See? YOU do not understand the concept. You don't like EJB spec? OK. But J2EE is more than just that. JCA has NOTHING to do with EJB, for instance. JMS also has nothing to do with EJB, even when MDB have a lot to do with JMS.

Cheers and happy coding,
Martin

My compliments for putting everything out of context and discarding all posts that came afterwards :)
Have a nice day.

I'm surprised no one has raised this point yet regarding the Spring vs J2EE debate, but the fundamental thing that Spring will give you that J2EE does not is the ability to run your code outside the context of an application server.

Maybe you don't need to do it today, but isn't it nice to have the option if you need it?

Almost every project can take advantage of this with their unit tests (true you can use container based testing facilities like Cactus to test your J2EE code, but that is a more cumbersome approach, and it's really a pain doing that if you want your build machine to automatically run your unit tests).

Another common example is a standalone program that performs long running operations that just would not make sense to execute in the context of an application server (do you really want to tie up an execute thread for an hour? and what if you want to kill the long running operation for some reason, do you really want to have to kill the entire app server?).

This is not something that is going to change with the next version of J2EE. J2EE, by design, requires an application server that supports the full specification. Spring, on the otherhand, is like J2EE a la carte.

IMHO, the article suggests "back to origin" of pure J2EE. However, if it's such a good practice, why people just don't happily use it through all these years? Can't you see that the drawbacks of such patterns were the reasons of other frameworks and solutions to be born?

I'd guess that there are quite a few people who have been happily using J2EE as-is for many years. Of course there will be other frameworks popping up, probably for at least 2 reasons:

1. barrier to entry is high with J2EE
2. inapplicabliity of J2EE in all situations

The 'drawbacks of such patterns' is the inappropiate and over-enthusiastic application of them (like in the J2EE Petstore).

All frameworks are based on patterns, and J2EE has a very stong inner core and allows for the structured layering of additional patterns on top and inside of it.

As the article points out, many shops in the end build/use frameworks on top of J2EE to abstract the dependency on J2EE, and they end up with dependencies on their chosen framework. What have they gained in the end? They've lost the ability to use multiple vendors of their framework, and standardized transcation and security contexts, which J2EE offers.

I agree with you... so at the end we need to use the right tool for the right job ;-)

If you only need to build a web based application: use the number (2) (from my thread above: http://www.theserverside.com/news/thread.tss?thread_id=34658#175069).

If you need to integrate a lot of available enterprise systems use the number (1).

Cheers,
Lofi.

I agree with you... so at the end we need to use the right tool for the right job ;-)If you only need to build a web based application: use the number (2) (from my thread above: http://www.theserverside.com/news/thread.tss?thread_id=34658#175069).If you need to integrate a lot of available enterprise systems use the number (1).Cheers,Lofi.

These approaches aren't that different, and don't imply the use of open source or not, or limiting yourself to one vendor. If you pick JSR standards you have the option of using either open source or commercial implementations and you can source any part from multiple vendors, no matter how simple or complex the application.

For example, when I 'only' need to built a web application, I use JSF (myfaces/apache), and JSP/Servlet (Tomcat) and JDO (I use a commercial product, but I could have used the open-source JPOX). Each of these APIs is available from multiple sources.

<quote>
For example, when I 'only' need to built a web application, I use JSF (myfaces/apache), and JSP/Servlet (Tomcat) and JDO (I use a commercial product, but I could have used the open-source JPOX). Each of these APIs is available from multiple sources.
</quote>

yes, everything is a process -> life cycle. As we all see EJB3 will be a lot more better than EJB2, so all the knowledge from "outside", vendor specific frameworks like Hibernate, Spring, ... will be absorbed into JSR specs. Hibernate will become "just" an EJB3 implementation (I wonder though what will happen to Spring?). So at the end we will stay to "multiple" vendors (OSS, commercial) solution which is good IMO.

Cheers,
Lofi.

Session facade to hide entity bean.
Business deletegate to hide session facade and ejb layer.
Home factory to abstract jndi look up.
Business interface to get rid of inconsistency of the remote interface and bean class.

This is the mixed ejb pattern, and i think it is the best practice of ejb design. what do you think?

That's what we do.