When most people think of Spring, they think "J2EE without EJB" (for obvious reason). However, Spring has excellent support for EJB, and makes life easier for using it. This excerpt from Pro Spring sheds light on the Spring EJB integration.

Pro Spring: Spring and EJB

Hmmmm...I just read the first sentence of the article, in which ORM is referred to as Object Role Modelling. Doesn't bode well for the rest of the article..... :)

OK, I'll go back to reading it...maybe it was just a typo, huh?

I think its more like acronym overload. I was doing object role modelling well before I was doign object relational mapping :).

Check out http://www.orm.net.

Rob

P.S. A google for ORM shows Operational Risk Management as ther 3rd hit.

...but yes, in that context it is a mistake - bloody typos :(.

I'll fix that in the next edition of the book.

Rob

I'm yet to read the Spring/EJB article but Object Role Modeling is a very standard data modeling term. There are even books written about it:

http://www.amazon.com/exec/obidos/ASIN/1558606726/qid=1108661726/sr=2-1/ref=pd_bbs_b_2_1/103-6727038-1899843

Scott Ambler talks about Object Role Modeling as well a few times in his Agile Database Modeling articles.

I think people (myself included) who have been brought up on OO and OO only are sometimes better off paying more attention to what data modelers/DBAs have to tell us :-)

I have tried to implement the example you provided in the article using JBoss. I have two apllicationContext.xml files one in the ejb.jar and the other under WEB-INF, as explained in the article. But as JBoss starts up it seems that it reads the applicationContext.xml under WEB-INF and tries to find the bean by JNDI name ejb/echoService and throws and error: ebj not bound - JavaNamingException...

I looked up in the JNDI for JBoss and the echoService is bound under ejb in the Global area. Any advice would be appreciated!

Vijay

Can someone explain to me why using Spring in this case better?

1. All the POJO classes are "EJB" independent (echo and counter). So, therefore you can test them outside the container... But if your POJO classes use another EJB, you won't be able to test them outside the container. In most cases you won't implement something simple with EJB :-)

2. Using simple POJOs + factories without Spring for "echo" and "counter" would be a lot more easier. No need to write those XML files... So, in this case using Spring makes me write a lot more code... (OK, you can generate everything with the help of AndroMDA Spring cartridge, but that's another story - but again you can also just generate factories and everything will work easier) :-)

So, I don't see any advantages using Spring in this case... :-(

Cheers,
Lofi.

1. All the POJO classes are "EJB" independent (echo and counter). So, therefore you can test them outside the container... But if your POJO classes use another EJB, you won't be able to test them outside the container. In most cases you won't implement something simple with EJB :-)

..and why would you design a POJO class, in this case, that calls EJB? Maybe there is a flaw in the design?

pinoyjed

<quote>
..and why would you design a POJO class, in this case, that calls EJB? Maybe there is a flaw in the design?
</quote>

No, but in real systems you need JNDI, EJB EB, EJB MDB, Web Service, etc.
- How can you connect to JNDI without a container?
- How can you use Environment Entries without a container?
- How can you use MDB and TimerBean without a container?

Do you want to implement/simulate all of those stuffs again by yourself? :-) So, in this case you need the container. The example is too simple because "echo" and "counter" are "stand-alone".

Adding Spring in the case I said above, makes my system more complex than necessary. You still can use normal factories if you want the independency to the implementations, but still you need the *container* to test them...

Lofi.

Adding Spring in the case I said above, makes my system more complex than necessary

Yeap. And it hides Exceptions to make little surprises at runtime here and there.

Adding Spring in the case I said above, makes my system more complex than necessary

Yeap. And it hides Exceptions to make little surprises at runtime here and there.

Interesting... just where in the code does Spring hide these Exceptions? If you look at the EJB code you'll see that Spring does not hide any Exceptions there.

Rob

Adding Spring in the case I said above, makes my system more complex than necessary

Yeap. And it hides Exceptions to make little surprises at runtime here and there.

Interesting... just where in the code does Spring hide these Exceptions? If you look at the EJB code you'll see that Spring does not hide any Exceptions there.Rob

Konstantin and Juergen had a rant a long time ago about checked vs. unchecked exceptions.

No, but in real systems you need JNDI, EJB EB, EJB MDB, Web Service, etc.

Do you? I've been happily building systems without EJB at all...

If you are doing this the Spring way, then your service implementation won't depend on EJBs, instead they will depend on some interface that can be used to inject an EJB proxy at production or another service object, or a mock at test time. In this way you can unit test your service beans as much as you like. You will still need to perform some kind of integration testing within the container, but unit tests can be done outside.

Rob

<quote>
Do you? I've been happily building systems without EJB at all...
</quote>

yes. If you need to integrate many systems you need them...

<quote>
If you are doing this the Spring way, then your service implementation won't depend on EJBs, instead they will depend on some interface that can be used to inject an EJB proxy at production or another service object, or a mock at test time. In this way you can unit test your service beans as much as you like. You will still need to perform some kind of integration testing within the container, but unit tests can be done outside.
</quote>

This is again wrong...

If you have a business process, which does following: "createStudent":
- check whether he/she already available in our database?
- check his or her register number from the university through a web service. Is she/he a real student in our university? --> Web Service, JNDI.
- everything OK, send her/him a mail. --> Need environment entry with JNDI to see the SMTP server.
- everything OK, send to all the teachers a mail, that we have a new student. --> MDB.

How can you unit test this business process without a container? The problem is that your business process depends on many other systems...

Cheers,
Lofi.

If you have a business process, which does following: "createStudent":- check whether he/she already available in our database?- check his or her register number from the university through a web service. Is she/he a real student in our university? --> Web Service, JNDI.- everything OK, send her/him a mail. --> Need environment entry with JNDI to see the SMTP server.- everything OK, send to all the teachers a mail, that we have a new student. --> MDB.How can you unit test this business process without a container? The problem is that your business process depends on many other systems...Cheers,Lofi.

Wow! Are all these logics in only one POJO Class?

I think we have to go back to the definition of UNIT TEST and INTEGRATION TEST.

I believe one of the advatages in using Spring is that individual classes can easily be UNIT-TESTED.

<quote>Do you? I've been happily building systems without EJB at all...</quote>yes. If you need to integrate many systems you need them...<quote>If you are doing this the Spring way, then your service implementation won't depend on EJBs, instead they will depend on some interface that can be used to inject an EJB proxy at production or another service object, or a mock at test time. In this way you can unit test your service beans as much as you like. You will still need to perform some kind of integration testing within the container, but unit tests can be done outside.</quote>This is again wrong... If you have a business process, which does following: "createStudent":- check whether he/she already available in our database?- check his or her register number from the university through a web service. Is she/he a real student in our university? --> Web Service, JNDI.- everything OK, send her/him a mail. --> Need environment entry with JNDI to see the SMTP server.- everything OK, send to all the teachers a mail, that we have a new student. --> MDB.How can you unit test this business process without a container? The problem is that your business process depends on many other systems...Cheers,Lofi.

Firstly, that's not unit testing it's integration testing which, as I said, you test in the container. To test each component independently you mock out the dependencies which are hidden behind interfaces. Then at production, one of these dependencies can be filled by an EJB proxy, another by a JAX-RPC proxy and so on.

You do not need to design your components so that they are so closely coupled. Why have a POJO-backed EJB that looks up another EJB when you can simply inject a proxy to that EJB? The same applies for web services. The same applies for SMTP Session which can be configured in XML and injected or accessed from JNDI and injected.

The only thing in your example that you need an EJB container for is the MDB which is where the integration level tests come in, but you can still mock out the sending of the message behind an interface for unit testing.

That's how you would test that process without a container.

Rob

OK, sorry to mixed up the UNIT and INTEGRATION test (I was too fast :-))

<quote>
You do not need to design your components so that they are so closely coupled. Why have a POJO-backed EJB that looks up another EJB when you can simply inject a proxy to that EJB? The same applies for web services. The same applies for SMTP Session which can be configured in XML and injected or accessed from JNDI and injected.
</quote>

This is actually what I'm trying to understand. If I understand you correctly, you propose to have a new "layer" on the top of EJB to decouple all the components. Why?:
- So, you can make UNIT test with mock-components outside the container.
- But you still need to do INTEGRATION test within the container?

My question, how can this save my time:
1. Because at the end I need to do that integration test in my container anyway? So, I still cannot live without the container...

2. Adding layer means adding reusability but on the same time adding complexity.

*IF* I want to add layer on my components: I just cannot see the advantage of using Spring instead using simple factory on every components you said above. I know that you actually use Spring factory capability for your purpose. But adding XML for each component will be horrible to maintain.
*IF* I want to add layer on my components, I prefer using AndroMDA to generate the factory for each my component automatically, which has following advantages:
- Strong typing, compiler check.
- You can use code completion in your IDE instead of "String".
- You have your OO model which can be used to talk with your customers, documentation -> "higher level of abstraction".

This is actually what I want to say :-)

IMO, adding layer is good but it has to be carefully executed. In your use case, adding the Spring layer does not give me enough advantages. Simply using *factory* would be the same. But before I'm implementing my factory by hand, I would take an MDA tool. This tool can bring me more advantages (not only decoupled components but also documentation, model to be able to talk with your customers, etc.) So, it is worth it to do this...

Sorry for a long response :-)

Cheers,
Lofi.

OK, sorry to mixed up the UNIT and INTEGRATION test (I was too fast :-))<quote>You do not need to design your components so that they are so closely coupled. Why have a POJO-backed EJB that looks up another EJB when you can simply inject a proxy to that EJB? The same applies for web services. The same applies for SMTP Session which can be configured in XML and injected or accessed from JNDI and injected.</quote>This is actually what I'm trying to understand. If I understand you correctly, you propose to have a new "layer" on the top of EJB to decouple all the components. Why?:- So, you can make UNIT test with mock-components outside the container.- But you still need to do INTEGRATION test within the container?My question, how can this save my time:1. Because at the end I need to do that integration test in my container anyway? So, I still cannot live without the container...2. Adding layer means adding reusability but on the same time adding complexity. *IF* I want to add layer on my components: I just cannot see the advantage of using Spring instead using simple factory on every components you said above. I know that you actually use Spring factory capability for your purpose. But adding XML for each component will be horrible to maintain. *IF* I want to add layer on my components, I prefer using AndroMDA to generate the factory for each my component automatically, which has following advantages:- Strong typing, compiler check.- You can use code completion in your IDE instead of "String".- You have your OO model which can be used to talk with your customers, documentation -> "higher level of abstraction".This is actually what I want to say :-)IMO, adding layer is good but it has to be carefully executed. In your use case, adding the Spring layer does not give me enough advantages. Simply using *factory* would be the same. But before I'm implementing my factory by hand, I would take an MDA tool. This tool can bring me more advantages (not only decoupled components but also documentation, model to be able to talk with your customers, etc.) So, it is worth it to do this...Sorry for a long response :-)Cheers,Lofi.

I see where you are coming from on this, and in most respects you are neither right or wrong.

I think the first thing to realise is that you CAN save time because you can test more thoroughly in your unit tests and you only need to run integration tests as part of your CI or nightly build. As a developer you can execute a comprehenshive suite of unit tests that execute very quickly. On a large project this is a real bonus, especially if you are in the maintenance phase where the temptation is to just fix a bug or add a new feature and be done, without running any tests.

Another point I'd like to dispel is the myth that Spring XML makes maintenance a nightmare. As the owner of a software company that spends a good portion of its time maintaining applications written in Spring for our clients, I can say that this is simply not true. If anything, the Spring XML file provides a unified view of the application and its dependecies, especially when coupled with the nifty BeanDoc tool by Darren Davison.

I can see where people get the idea from that it would cause problems, but I can say from practical experience that I have never encountered these problems with the XML-based configuration mechanism.

Of course, the whole dependency on the container becomes a moot point if you question whether you actually need EJB or not, but that is a topic that has been covered extensively so there is no need to get into that :).

Rob

<rob>
I think the first thing to realise is that you CAN save time because you can test more thoroughly in your unit tests and you only need to run integration tests as part of your CI or nightly build. As a developer you can execute a comprehenshive suite of unit tests that execute very quickly. On a large project this is a real bonus, especially if you are in the maintenance phase where the temptation is to just fix a bug or add a new feature and be done, without running any tests.
</rob>

OK, I agree with this. It can save my time within the UNIT test using mock objects (independent whether I need to do INTEGRATION test or not). But again, this is independent whether you use Spring or just *simple factory*, correct? (simple factory means "factory class" with its "POJI").

<quote>
Another point I'd like to dispel is the myth that Spring XML makes maintenance a nightmare. As the owner of a software company that spends a good portion of its time maintaining applications written in Spring for our clients, I can say that this is simply not true. If anything, the Spring XML file provides a unified view of the application and its dependecies, especially when coupled with the nifty BeanDoc tool by Darren Davison.
</quote>

I'm not sure whether you know UML? IMO, the Spring XML file has less meaning than a UML diagram :-) You can really see the model (platform independent model) of your domain model (relationship, inheritance, etc.)! This is not comparable with JavaDoc files :-) I already mentioned the advantages of using AndroMDA in my thread before...

So, I still don't see the advantage using Spring in this case... I know that AndroMDA also offer a Spring Cartridge, so you can generate your model into Spring framework (never used it by myself though) but this is another story.

IMO, we need to balance the use of FRAMEWORK and CODE GENERATOR. We need both! Only depending on a FRAMEWORK won't help you in many cases...

Therefore for the EJB use case above, I would still use simple factory, which will be generated from my UML class diagram (XMI) with the help of AndroMDA instead of using Spring BeanFactory...

Cheers,
Lofi.

something to add:

Don't understand me wrong. I have nothing against Spring :-) It is a great solution if you don't need EJB container (and for many solutions this is the best solution! We don't need to re-discuss this matter, I agree with almost all of you ;-)).

But - again the problem of silver bullet :-) - it CANNOT give you a solution of any problems you encounter. One of it is the integration with the EJB environment. You can have a BETTER solution for this problem by using MDA concept (I already showed the advantages of using this concept in this problem domain).

Cheers,
Lofi.

Answer: very easily using spring

a) code to interfaces
b) use predefined sample data
b) use mock objects
c) use (IOC) inversion of control/dependancy injection
d) remove all lookup code from your business logic code

read up on these things and learn to modularise your code.

--b

<quote>If you have a business process, which does following: "createStudent":
- check whether he/she already available in our database?
- check his or her register number from the university through a web service. Is she/he a real student in our university? --> Web Service, JNDI.
- everything OK, send her/him a mail. --> Need environment entry with JNDI to see the SMTP server.
- everything OK, send to all the teachers a mail, that we have a new student. --> MDB.

How can you unit test this business process without a container? The problem is that your business process depends on many other systems...</quote>

<quote>..and why would you design a POJO class, in this case, that calls EJB? Maybe there is a flaw in the design?</quote>No, but in real systems you need JNDI, EJB EB, EJB MDB, Web Service, etc. - How can you connect to JNDI without a container? - How can you use Environment Entries without a container? - How can you use MDB and TimerBean without a container? Do you want to implement/simulate all of those stuffs again by yourself? :-) So, in this case you need the container. The example is too simple because "echo" and "counter" are "stand-alone". Adding Spring in the case I said above, makes my system more complex than necessary. You still can use normal factories if you want the independency to the implementations, but still you need the *container* to test them...Lofi.

No, but in real systems you need JNDI, EJB EB, EJB MDB, Web Service, etc.

I love that quote. If there is a system which has a set of batch files which kick off JVM's which then run jobs scheduled by, and run from data in a database, does this mean they are not real systems? Cricky, using the OS (or some cross tech product) for scheduling. Using jdbc for the database.... Must be insane to keep things simple.

Jonathan
MicroSpring - IOC in 30K

EmeraldJB - now a free sparkling green DAO code generator.

<quote>
I love that quote. If there is a system which has a set of batch files which kick off JVM's which then run jobs scheduled by, and run from data in a database, does this mean they are not real systems? Cricky, using the OS (or some cross tech product) for scheduling. Using jdbc for the database.... Must be insane to keep things simple.
</quote>

Ahmm... sorry IMO MDB, TimerBeans are the *simplest* things I've ever seen :-) You also forget to separate "development" and "management" aspect of your application. Developing job scheduling like you said above with Quartz is simple, no doubt, but not the management (deployment, administration) of your application later on your production environment. Using J2EE container makes this a lot more easier (no need to have Linux cron or Win schedule). Run your container that's it.

The same is for JMS and MDB. Do you never use "asynchron" method calls?

The main idea of J2EE container is to separate *concerns* (transaction, management, development, communication, etc.). Why reinventing the wheel if you already have it? (Maybe you like to reinvent the wheel to learn how to do it, that's OK :-))

KISS is very important but please don't simplified everything... :-)

Cheers,
Lofi.

Fair comment.
But when your scheduled jobs are java, scripting, ftp, even some ms boxes, all with inter job dependencies then the issue is less clear.

At this point we see 3rd party products like autosys being used accross the enterprise with management consoles for reporting and monitoring.

As ever, it depends on the environment you are in.

Jonathan

<quote>
As ever, it depends on the environment you are in.
</quote>

agree. No silver bullet solution for all our problems :-)

Cheers,
Lofi.

Let's add Hessian to the list... it's such a nice lightweight alternative to Web Services for remoting.

Lofi,

I think the summary to your answer is:

Rather than calling out to the container for your dependencies (JNDI, other EJB's ,etc) let Spring inject them.

This is the essence of IOC or dependency injection.

-Nick

<nick>
Rather than calling out to the container for your dependencies (JNDI, other EJB's ,etc) let Spring inject them.
</nick>

Nope, this is not the answer :-) The answer is:
generate your factories with AndroMDA, so you have:
1. No dependency to Spring, which is not useful in EJB container.
2. Strong typing, compiler check.
3. Code completion.

Again (please read my thread above). Summary:
1. Using Spring in an environment *without* EJB is very nice and the way to go!
2. Using Spring in an EJB environment makes no sense, since you can have a lot MORE advantages by using MDA concept!

--> NO SILVER BULLET.
--> BALANCE BETWEEN FRAMEWORK and GENERATED CODES.

Cheers,
Lofi.

<quote>
Thats like saying Java is not useful in and EJB container.
Certain services that spring provides (e.g. transaction interception) is provided by the appserver. But I am not sure how you can say the same for the Hibernate support, JDBC templates, JavaMail abstraction, etc, etc.
</quote>

again, using a simple Factory will do the same thing :-) No dependency to "external libs". And there are a lot of advantages as I said above.

<quote>
You have just traded dependancies. One is at the tool level, one is at runtime. They are still dependancies.
</quote>

*buildtime* dependency is not as "hard" as *runtime* + *buildtime* dependency. Using Spring makes you to have both dependencies. Just imagine that you need to add an external "jar" file within your production environment...

<quote>
And as soon as you say "code generation", I retch. I am a very small fan of code generation - unless its a completely hidden, runtime operation. Certainly nothing that has to be factored into development...
</quote>

And this is the weakest point of your argument. Did you ever use both concepts: FRAMEWORK and CODE GENERATORS in your development environments? I did and therefore I can say using *both* in *balance* IS the BEST WAY (MDA is all about to use frameworks and code generators in a correct way) :-)

If you only use framework style development, how can you judge code generators?

Therefore the answer is still: in EJB container using Spring is non-sense and bring you more disadvantages :-)

Cheers,
Lofi.

More about dependencies:

1. Code Generators: tool level dependency. The results (generated codes) are independent.
2. External Frameworks: build-time or compile-time, runtime dependency and also sometimes they have tool level dependency.

Cheers,
Lofi.

Therefore the answer is still: in EJB container using Spring is non-sense and bring you more disadvantages.

I totally agree with you!

But,
J2EE server != EJB container
EJB container != J2EE server

The argument from the anti-EJB camp is that EJB (and EJB container) is the one bad apple on the good J2EE land.

One of the selling points of Spring is that Spring is an alternave to EJB on J2EE servers (IBM/BEA/Oracle or even JBoss).

|
|Have you pointed out JDO's "own problems" in any JDO
|related threads?
|

Yes. A long time ago.
The fact remains that no major java vendor - including the major ORM vendors - supports it.

-Nick

|
|If you only use framework style development, how can you
|judge code generators?
|

Do you think I flipped a coin to come to that conclusion? It comes from experience.

Code generation can be suitable - so long as its very well hidden. Its just that most times it is not.

Most EJB containers use code generation (on deploy) to do TX/Security/ORM interception - which you would think was fairly unobtrusive - but that led to the kind of situation where your EJB implementation couldnt implement its interface - and Entity beans had to be abstract...
It was impossible to test stuff.

Ultimately, (in my experience, at least) with code generation approaches, you end up having to reverse-engineer the code generation process. You know what code you need to end up with - but you have to work out how to get the tool to generate it. This is your dependancy - and its not pretty if the tool isnt reliable. I looked at compuware's MDA tool (ok, its not a shining example) and this issue of dependancy was abundantly clear. The tool would fall over - and you were left with a mess of code "what the tool done wrote" to try and comprehend...

I am not saying code generation is a completely invlaid approach. Just that I dont like it. And I have my reasons. And I think they are valid. :-)

|
| Therefore the answer is still: in EJB container using
| Spring is non-sense and bring you more disadvantages :-)
|
Except, of course, that by using Spring, I can test my code without the container...
I can compile 99% of my code without Spring. I can unit test all of my code without Spring.
And with a mere config change, using Spring, I can test my entire app end-to-end. From *within* JUnit. With no EJB container (or any other server) in sight...
Other than that, yes, its just nonsense ;-)

-Nick

I was noticing that this book shot up to #1 among java books: http://www.javacrawl.com/java-books-j2ee-books. Considering it just came out this is pretty impressive.

This is almost the exact same reason why we moved Liferay over to a Spring architecture. Ppl were complaining that Liferay was too heavy in its use of EJBs. We wanted to please the community, but at the same time, our large bank/telecom clients were demanding EJBs.

So we migrated our EJB implementations into a service class (pojo impl), so that a servlet container could call it the impl directly whereas the EJB container would call the EJB wrapper that would call the impl.

Spring's dynamic proxies actually made this very easy to do.

It does mean even more XML files (ejb + spring files) and more factory classes, but with xdoclet and other generators, the pain is gone. You just end up using a little more hd space.

I think the article hava a bug for statefull session bean implemention, because the BeanFactory have no any session management for beans it managed. After ejbPassivate all the
state will not be restored

I see what you are saying here. Yes, once the EJB is reactivated the CounterService will be created again from scratch. If this is not desirable, as will often be the case, then you should opt to make the service bean serializable as mentioned in the article so you can skip the whole reload process, or use a different implementation of BeanFactoryLocator (as mentioned in the book) that caches the BeanFactory somewhere once it is loaded and makes the exact same BeanFactory available after the EJB is reactivated.

...once the EJB is reactivated the CounterService will be created again from scratch...

in your article, to avoid that, you chose to keep the handle to the stateful session bean in the HttpSession, instead use a different implementation of BeanFactoryLocator.

i have never used SFSB, but i know that there is something like BeanNotReentrantException when you try to call the same stateful SessionBean from two different threads. it can happen when you store reference in http session. so, maybe that storing is not good idea, isn't it?

greets,
michael k.

I don't see why I should use a proprietary solution when EJB 3 is already on its way. Granted it may take quite a while until it comes to an application server near you. But instead of introducing yet another framework into the infrastructure hodgepodge that typical real world IT shops have to operate today, I'd much rather start to experiment with an early implementation of EJB 3 like JBoss's. That way, I do at least have a standards based upgrade path.

yeah .... if you can ever get it

a)configured
b)to run

--b

ps: good luck !

Given that Spring is open source, I wouldn't really class it as proprietary but...

On the EJB3 front, aside from the fact that a production implementation is still some time away, I can't really see the attraction. I think if you look the IoC stuff in EJB3, you'll see how primitive it is compared to Spring, so why limit yourself to a sub-standard implementation. More on that on my blog: http://www.robharrop.com/blojsom/blog/default/Java/2005/01/31/Looking_at_IoC_in_EJB3.html.

Rob

My impression is that you and many other people here make valid points about small technical details at the expense of infrastructure planning. Is instance based object configuration via XML really worth ditching all standardisation efforts? Is this not a sure way to increase overall complexity of Java based IT infrastructures?

IoC is but one very small piece of the whole picture and instance based injection again is but one aspect of IoC. Most of my instance data is in the database anyway, not in XML config files and not in annotations. I feel that this community's obsession with the details of particular IoC, AOP or MVC designs doesn't provide much relief for the complexity problems that most IT organisatios face today.

You shouldn't be configuring fine-grained objects with a lot of instance data. You're typically configuring coarser-grained services that makeup the internals of your application, and exporting and adapting those services for use in different technology environments IF YOU NEED TO (like EJB, which everyone surely knows by now is not always neccessary.) Spring helps you do that in a consistent, manageable away, one where the internals of your app ("the meat") stay simple and highly testable and highly OO, while the external facades (or adapters) can often be created with zero custom glue code because of techniques like AOP and out-of-the-box factories/decorators Spring provides for a number of STANDARD technologies. I hope you can see it--you get a LOT of leverage that way...

Most of my state is in the database too, doesn't mean I don't use Spring.

Here's my point: there are often costs (and often zero value) in coupling yourself to any one infrastructure technology (standard or not) within the INTERNAL structure of your application. In most cases, all you're doing is bloating your domain-specific (money making) code with a dependency on a particular technology (one that is usually quite volatile), and for what reason? Keep your core code simple, testable, decoupled from superflouous infrastructure - use decoration/factories/AOP to scale up that code (and adapt it to different technology environments as needed).

Really, what is there to standardize within the internal structure of your app when it's already based on STANDARD J2SE PLAIN-OLD-JAVA-OBJECTS. Now standardizing a messanging protocol, a transaction coordinator, a remote access API many competing vendors implement -- now that's needed! But my core code doesn't have (or want or need) to know about all that...

POWER TO THE POJO! :-)

You shouldn't be configuring fine-grained objects with a lot of instance data. You're typically configuring coarser-grained services that makeup the internals of your application, and exporting and adapting those services for use in different technology environments IF YOU NEED TO (like EJB, which everyone surely knows by now is not always neccessary.) Spring helps you do that in a consistent, manageable away, one where the internals of your app ("the meat") stay simple and highly testable and highly OO, while the external facades (or adapters) can often be created with zero custom glue code because of techniques like AOP and out-of-the-box factories/decorators Spring provides for a number of STANDARD technologies. I hope you can see it--you get a LOT of leverage that way...Most of my state is in the database too, doesn't mean I don't use Spring.Here's my point: there are often costs (and often zero value) in coupling yourself to any one infrastructure technology (standard or not) within the INTERNAL structure of your application. In most cases, all you're doing is bloating your domain-specific (money making) code with a dependency on a particular technology (one that is usually quite volatile), and for what reason? Keep your core code simple, testable, decoupled from superflouous infrastructure - use decoration/factories/AOP to scale up that code (and adapt it to different technology environments as needed).Really, what is there to standardize within the internal structure of your app when it's already based on STANDARD J2SE PLAIN-OLD-JAVA-OBJECTS. Now standardizing a messanging protocol, a transaction coordinator, a remote access API many competing vendors implement -- now that's needed! But my core code doesn't have (or want or need) to know about all that...POWER TO THE POJO! :-)

Well put. This is exactly the level that standarization that we should be at. Standardizing services (JTA etc) is a good idea, standardizing a programming model is, in general, not. A programming model should be uninvasive and use normal Java constructs.

Rob

Really, what is there to standardize within the internal structure of your app when it's already based on STANDARD J2SE PLAIN-OLD-JAVA-OBJECTS. Now standardizing a messanging protocol, a transaction coordinator, a remote access API many competing vendors implement -- now that's needed! But my core code doesn't have (or want or need) to know about all that...POWER TO THE POJO! :-)

EJB3 is POJO, because "Hibernate is EJB3".

Only the persistence part of EJB3 is related to Hibernate. The rest of the stuff is not.

Rob

It's quite simple: If I don't want a particular piece of code to depend on outside service infrastructures, I design it that way. I can do that with or without EJB/Spring/Anything. The problem is, that at some point, if I want to use a service, I'm creating a dependency. That dependency might be in a config file, in some Java class, in an SQL statement, in a UML diagram, in an ANT file or even in my development process. All I'm saying is that I prefer to depend on agreed upon standards.

Sometimes, this is not practical. Sometimes standards are bad. Somtimes implementations of standards are bad. Sometimes they do not go far enough and I come to the conclusion that a particular piece of proprietary code makes my life so much easier that I can justify the dependency. Spring is proprietary and it doesn't offer me anything beyond standard J2EE that I couldn't create myself within a week, so I don't use it.

Spring is proprietary and it doesn't offer me anything beyond standard J2EE that I couldn't create myself within a week, so I don't use it.

Do you mean the BeanFactory, ApplicationContext, TransactionManager, templates for Hibernate, JMS etc? I think that takes quite some time and efford to build and test. :-)

regards

Spring is proprietary and it doesn't offer me anything beyond standard J2EE that I couldn't create myself within a week, so I don't use it.

Do you mean the BeanFactory, ApplicationContext, TransactionManager, templates for Hibernate, JMS etc? I think that takes quite some time and efford to build and test. :-)regards

Sure, that's why I said, 'beyond J2EE'.

Let's face it, quite a few people either hate J2EE and the whole way it is made or simply love to create their own framework designs (which I understand very well). They will always find a way to bash EJB, not matter what the design the EJB 3 EG comes up with.

Sorry, the last half sentence should read: no matter what design the EJB 3 EG comes up with.

<quote>
Sometimes they do not go far enough and I come to the conclusion that a particular piece of proprietary code makes my life so much easier that I can justify the dependency. Spring is proprietary and it doesn't offer me anything beyond standard J2EE that I couldn't create myself within a week, so I don't use it.
</quote>

Alex, IMO you can use Spring if you don't need EJB (again, in many cases you don't need EJB as I said above). In this case I won't reinvent the wheel. Although you can write it within a week, why should you spend one week more? (I prefer to go holidays for one week :-)) In combination with AndroMDA you can generate almost everything for Spring, so I think, you'll get everything faster...

My point was "using Spring in conjunction with EJB". IF I USE EJB... This makes no sense, since this does not help me to spare my time. Instead I would just use AndroMDA and generating the whole factories and stuffs (the advantages are clear)...

So, we need to be carefull... :-) Using Spring everywhere just makes NO sense. But using it in some cases is great!

Cheers,
Lofi.

Although you can write it within a week, why should you spend one week more?

Because for trivial things it's often easier to create your own small library that does exactly what you need and in exactly the way your architecture requires it, instead of configuring and customizing a much broader framework. But I agree that it's not always easy to find the right balance between framework creep and not invented here syndrome.

<alex>
it's not always easy to find the right balance between framework creep and not invented here syndrome.
</alex>

agree. Just like it's not easy to find the balance of using FRAMEWORK and CODE GENERATOR... I think your sentence is very wise: BALANCE...

Cheers,
Happy weekend!

Lofi.

Alexander,

I am not sure what your definition of proprietary is - but it seems different to most people.

To some extent I understand what you are getting at; On a project Spring can represents Yet Another Thing to Learn.
You have to make a call whether the added complexity of Spring is worth the extra features it gives you.

|
|that I couldn't create myself within a week
|

Statements like this are guaranteed to earn you little respect - and some amount of derision. You are essentially saying that what has taken a team of smart guys over a year to develop, you could knock together in a week? If its true, send me your CV - we are hiring ;-)

Spending any time looking at Spring (and the documentation is excellent BTW) and you will notice there are quite a number of things that spring offers from an IOC container perspective - and from a general "useful stuff" perspective that would warrant its use. There is plenty of supporting framework to make general J2EE services IOC-friendly (e.g) JavaMail, Hibernate support, etc.

And as Rob said, the advantage is that its right here, right now... - you can put it into production on whatever appserver you run with today. Why wait?

Note to Rob & Spring guys:
While your comments (and criticisms of EJB3) are inherantly correct, the Spring team's anti-ejb sloganing often tends to fire the wrong neurons in people... :-)
You wanna decide how far you want to push that barrow...

-Nick

First of all - thanks for your praise, Nick!

And as Rob said, the advantage is that its right here, right now... - you can put it into production on whatever appserver you run with today. Why wait?

This is probably the most important point in any discussion about Spring "vs" EJB3: Spring is available right now, offering its services on JDK >= 1.3 and application servers >= J2EE 1.2 (which includes Tomcat 3 to 5, WebSphere 4 and 5, WebLogic 7 and 8, etc).

Keep in mind that the major application server vendors are just about to release their J2EE 1.4 compliant servers (e.g. WebSphere 6, WebLogic 9). It will take at least two further years until they come up with production-ready J2EE 5.0 servers, and significantly more time until major clients upgrade to those server versions.

Which means that many people won't be able to use EJB3 in their enterprise deployment environment before 2008 - with conservative upgrade paths, it will take even longer. Yes, JBoss might have a full EJB3 implementation earlier, but this is of no benefit to users of WebSphere and WebLogic. (And consider market shares in the enterprise area.)

EJB3 - by design - has to be provided by the J2EE server to fully leverage it, so cannot be plugged into existing application server environments (that is, older application server versions). In contrast, Spring is designed to seamlessly plug into any environment, be it plain Java, Tomcat or full J2EE - even old versions of those.

This is an important differentiator between an application server and an application framework: The server is considered as piece of system software, with conservative upgrade paths, while an application framework is "just" part of an application and can easily be upgraded even when deploying to an old server version.

Consequently, an application framework can be evolved in a much more agile fashion. Compare Spring's evolution (or Hibernate's evolution) with EJB's history to see what I mean. Application frameworks will always be able to introduce new features very early, while things (necessarily) take years in the world of major J2EE servers.

In essence: EJB3 is arguably about 3 years away from the enterprise deployment mainstream, so there's not much point in arguing against Spring (which is available right now, on all J2EE servers) with the EJB3 hammer. The noise coming from the JBoss camp needs to be taken with a large grain of salt; things are very different in the BEA/IBM/Oracle world.

Juergen


P.S.:

It's not such a "vs" between Spring and EJB3 anyway, at least not from the Spring point of view. Application frameworks and application servers are different things and usually live in synergy. Of course, Spring will support EJB3 once it is finalized, just like it supports other J2EE services (provided by application servers) already.

It's mainly JBoss that aims to push EJB3 as the kitchen sink of enterprise development, completely replacing all existing O/R mapping APIs as well as lightweight containers - and tying everyone to the J2EE release cycle. I strongly believe in a much more versatile Java world.

It's mainly JBoss that aims to push EJB3 as the kitchen sink of enterprise development, completely replacing all existing O/R mapping APIs as well as lightweight containers - and tying everyone to the J2EE release cycle. I strongly believe in a much more versatile Java world.

It is amazing that the J2EE community in general and major EJB2 vendors in particular are so reluctant to see this simple fact (for different reasons).

|
| completely replacing all existing O/R mapping APIs as
|well as lightweight containers
|

But dont under-value the evolution EJB is making. I would much prefer them adopt the models that spring/pcio and hibernate have developed rather than reject or ignore them.

And in the quest for simplicity, for some Appserver applications, EJB3 will be enough - and they wont need spring or anything else. We should welcome that.

-Nick

|| completely replacing all existing O/R mapping APIs as |well as lightweight containers|But dont under-value the evolution EJB is making. I would much prefer them adopt the models that spring/pcio and hibernate have developed rather than reject or ignore them.And in the quest for simplicity, for some Appserver applications, EJB3 will be enough - and they wont need spring or anything else. We should welcome that.-Nick

How about the attempt by the EJB3 camp to kill JDO? Also it will be very hard to convince people EJB3 is not another elephant to eat. It smells elephant already.

Of course, there is nothing wrong to be pro elephant, if you choose to.

JDO has its own problems - very little to do with EJB3...

JDO has its own problems

Have you pointed out JDO's "own problems" in any JDO related threads?

- very little to do with EJB3...

Then why the EJB3 side don't want JDO2 to be approved.

"Because JDO has it's own problem"


You are kidding! Probably this discussion should be moved to a JDO related threads.

JDO has its own problems

Have you pointed out JDO's "own problems" in any JDO related threads?

- very little to do with EJB3...

Then why the EJB3 side don't want JDO2 to be approved."Because JDO has it's own problem"You are kidding! Probably this discussion should be moved to a JDO related threads.

Yes, Nick you were right that the problem with JDO was that each JDO vendor only had a small user base.

But with KODO JDO, and Apache JDO on the pipe line, this is changing. Probably this is why the EJB3 camp wants to kill JDO2.

And in the quest for simplicity, for some Appserver applications, EJB3 will be enough - and they wont need spring or anything else. We should welcome that.-Nick

Rod Johnson started the "without EJB" argument. It is only natural for the EJB3 fans to come back with a "without Spring" argument.

I am not related to Spring in anyway (not even a user). Only amazed by

1)EJB3 spec is being hijacked by JBoss
2)EJB is now also about Java ORM, just because JBoss owns Hibernate and Hibernate is very popular.
3)Good product such as Hibernate (which I am a user of) got invoved in dirty politics. Spring is much cleaner here.

|
|Rod Johnson started the "without EJB" argument. It is only
|natural for the EJB3 fans to come back with a "without
|Spring" argument.
|

Ha ha. I hadnt appreciated the irony of that comment. :-)

Though, I dont know how that comment makes me an EJB3 fan over a Spring fan - given my earlier comments on this thread.

If developing an application that requires EJB - (despite the anti-EJB fashion, there are still valid reasons for EJB - though fewer than there used to be) - and if for this app, Spring gives you nothing over EJB3, then WhyTF use Spring? Ultimately, unlike EJB2, your code is not tied to EJB3 OR Spring.

|
| EJB3 spec is being hijacked by JBoss
|
You think they can out-muscle Sun, IBM & BEA on the EG? I think some EG members would have a snicker at that assertion...

I think the whole community, Spring/Pico & Hibernate have had a massive influence on the EJB3 spec - and the results have been excellent. Doesnt necessarily mean EJB3 is going to be better than Spring or Hibernate... but its a very positive move nonetheless.

|
| EJB is now also about Java ORM, just because JBoss owns
| Hibernate and Hibernate is very popular
|
I dont think JBoss has anything to do with it. Its more to do with Hibernate being very popular (for a reason!).

|
| Good product such as Hibernate (which I am a user of) got
| involved in dirty politics
|
It is sad that *some* Hibernate project members feel they need to do that...

-Nick

Furthermore:
From a code perspective, your application code should be equally oblivious of EJB3 as it is of Spring.
So to that extent, I see the Spring Vs EJB3 question as reasonably uninteresting.

Not so sure about the 2008 prediction... but in many ways, I dont care.

I agree with you on your distinction between application server & application framework. The two do and indeed should be able to evolve seperately.

And I think Spring has focused well on being complementary to an appserver rather than competative. Despite what the book advertising suggests ;-)

-Nick

<quote>
Here's my point: there are often costs (and often zero value) in coupling yourself to any one infrastructure technology (standard or not) within the INTERNAL structure of your application.
</quote>

Yup, therefore we have Platform INDEPENDENT Model (PIM) and Platform SPECIFIC Model (PSM). So in a "big picture", you see that we need to separate these both concerns.

In a "small/detail picture" you don't really care whether you use Spring or just generally simple factories as you said... BUT IF YOU ALREADY generate your PSM/Code from your PIM, you can automatically generate the factories, etc. as you need them, so NO NEED to have a dependency to Spring. Through generating them, you can use: Code completion, static compiler check, etc. which in turn much more better than using "String" and XML files...

So now back to the use case above with EJB: Using Spring in this case does not help you a lot. Instead using factories which will be generated for you automatically have more power and KISS!

Cheers,
Lofi.

Given that Spring is open source, I wouldn't really class it as proprietary but...On the EJB3 front, aside from the fact that a production implementation is still some time away, I can't really see the attraction. I think if you look the IoC stuff in EJB3, you'll see how primitive it is compared to Spring, so why limit yourself to a sub-standard implementation. More on that on my blog: http://www.robharrop.com/blojsom/blog/default/Java/2005/01/31/Looking_at_IoC_in_EJB3.html.Rob

Rob, that is correct. The current injection proposal only allows for injection of EJBs, Resources, Env-Entry, and various singleton services. Myself and a few others on the EG are trying to get bean injection in as well.

Unfortunately, it doesn't look like the XML DD format is going change much. I wish it could have gotten a complete overhaul, but understand why it may be important to be as backward compatible as possible for migration purposes.

Bill

Rob, that is correct. The current injection proposal only allows for injection of EJBs, Resources, Env-Entry, and various singleton services. Myself and a few others on the EG are trying to get bean injection in as well.Unfortunately, it doesn't look like the XML DD format is going change much. I wish it could have gotten a complete overhaul, but understand why it may be important to be as backward compatible as possible for migration purposes.Bill

Certainly. I don't think you can just dump the XML DD, although it would have been nice if you could have created a separate 'profile' for configuration that used a different DD format and just kept the existing format for backwards-compatibility.

Rob

Pro Spring? Am I missing something or all we have here is a couple of abstract classes with simplistic brain-dead implementation?

How about <sarcasm>Pro J2EE - Extending abstract classes in EJBs</sarcasm>?

The article was hardly worth the read.

--Dmitriy.

Pro Spring is the title of the book from which the article is extracted.

Rob

No offense, but if the book goes into such depths about extending abstract classes in EJBs, maybe you should call it "Spring For VB Developers" ;-)

This kind of stuff can be covered in one or two paragraphs.

What is your target audience?

--Dmitriy.

No offense, but if the book goes into such depths about extending abstract classes in EJBs, maybe you should call it "Spring For VB Developers" ;-)This kind of stuff can be covered in one or two paragraphs.What is your target audience?--Dmitriy.

The book covers all the aspects of the Spring framework in-depth. The target audience is professional Java developers who are willing to create flexible, maintainable, testable, etc. Java applications with the help of the Spring framework.

Regards,
Dmitriy.

Hi Rob,

I think it is a nice book worth puchasing from the review read off amazon. I always like Spring (its IOC, AOP and great support and integratability with other frameworks/tools) and is really looking foward to purchasing a copy.

Thanks.

regards

p/s Spring rocks!!!

Hi Rob,I think it is a nice book worth puchasing from the review read off amazon. I always like Spring (its IOC, AOP and great support and integratability with other frameworks/tools) and is really looking foward to purchasing a copy. Thanks.regardsp/s Spring rocks!!!

Thanks! I've spoken with quite a few readers and they have really enjoyed it. There was a small problem with the code download file initially, but that is fixed now.

Rob

Rob and Jan:
  Thank your aritcle. I built and deploy example mentioned in your article with jboss. I have a question that is whether I can implement ejb without spring ( no ApplicationContext.xml for ejb implementation), but my client a spring web controller
still can invole serice provided by that ejb

Hi I found the Pro Spring: Spring and EJB article great. I have implemented it and worked fine. I have one question. I have three session EJB in my application, each one providing different services. Should I use only one ApplicationContext.xml or should I use 3 different ApplicationContext.xml ?

thanks Nicolas Fonnegra

Hi All,
Let me explain what we are planning to do.
We are developing a J2EE application with following requirement.

1. Workflow based .. so that developer can easily define its workflow in plain xml
2.Schedular.. Lots background jobs are required on server.
3.SEDA based architecture...
4.ESB
5.Distributed .. So that we can have services running on differnet machine
6.Persistence

Here I need suggetion should we go with EJB (or + ) Spring.


thanks
ani.......