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.
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.
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.
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.
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.