• Post Reply Bookmark Topic Watch Topic
  • New Topic

EJB 3.0 invasive?

 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a recent Sun's tech tip article on the EJB3.0, I noticed that the source code of an entity bean had an import statement

import javax.persistence.*;


I think the package defines annotations such as Entity,EjbLoad etc. Doesn't this make EJB 3.0 invasive?
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you mean by invasive? Like "take invasive action"

Mark
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Invasive = Invading or encroaching.

When I write business logic in the bean class I need to import javax.ejb.* and also implement some(Entity/Session) interface. I cannot use the code witout EJB container and is not reusable.
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, I see what you mean. Yes, you would be right in that assumption, but let me give you an example of how we do it here at work. And this definitely makes it unobstrusive and uninvasive.

First we create a standard interface, with no J2EE libraries.



Then we create interfaces for EJB like. (This is just a Remote Interface but the same would be used for a Local Interface with just @Local



The EJB Bean has no real code, just will call some Service class.

So our EJB looks like this




Then last but not least, we have our actual implementation of the Service class which is a POJO and has no J2EE imports. This is the class that actually does the work.



I used Object just to be general about it, it would be application specific to your application.

I hope that helps and shows how you can make it completely non-invasive, and you can move your main interface and service implementation class out of an EJB server and not have any problems because the j2ee jars aren't needed.

Mark
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mark but in Spring /Hibernate framework one can write all code in SomeServiceBean class without any container specific import statements and avoid the extra SomeService class and that makes it truly non-invasive. Correct me if I am wrong.
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, but I have never ever put any code into a Bean. I think that a Bean should only be a public interface to the world, and pass it to a Service class POJO. Service classes can then be mapped to Use Cases and works really well in OO and extensibility, maintainability, and scalability.

Also, with Spring, you are introducing more XML configuration files. We are being overdone with XML Config files and I find them really annoying and more of a maintenance nightmare. But that is my opinion. Use XML for Web Services to pass data between two systems that can't call each other directly. Otherwise, I have never liked XML.

For Hibernate, using Annotations in Hibernate 3.x or using XDOclet to generate the mapping files for me. Don't let me touch XML.

Mark
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mark. I agree that XML can go out of control.

I think that a Bean should only be a public interface to the world, and pass it to a Service class POJO.



Isn't ISomeService the interface to the world ?
You have separated the business logic in SomeService and made it reusable.
My question is - Cant we avoid the extra bean class whose functionality is limited to delgating calls to the someService instance. I think this is what the spring avoids.
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the ISomeService is "the public interface" but there is no implementation. You have to first have some class implement that interface. And as you had pointed out before, then the bean class would have import statements to the j2ee.jar file

Yes, that is what Spring avoids. But this also avoids it without having to create another XML file. It is simple and keeps things Java based and not any outside framework.

Mark
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mark.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!