Implementing J2EE-based services for a real world.
Eugene Kuleshov's Blog |
August 12, 2005 9:45 AM
|
Comments (7)
Bobby Woolf posted a blog entry "How to Implement a Service in J2EE". He is suggesting to use SSB if service using synchronous transport (such as HTTP or RMI) and MDB in case if transport is asynchronous (e.g. JMS or JCA).
Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.
It is hard to disagree with this. Services exposed as SSB and MDB managed by J2EE application server is a really good option, because it automatically provides remoting, transactionality, security, pooling, load balancing, failover recovery, etc. to both client an service provider and especially if you can afford to use an application server there is truly no point to reinvent the wheel and spend time on reimplementing these services.
Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean/POJO. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.
So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.
Well, it had been discussed a lot some time ago when IoC containers started to became popular. This is seems too strong statement to say that POJO-based design is leaking support of security, transactions, remoteness, etc. Those are really crosscutting concerns and has very little or nothing to do with actual business logic. Moreover these separate concerns don't really require unit testing, but only integration testing.
In my opinion the much more flexible approach that benefits from both is to use EJB's only as a Service Facade for boundaries that may have remoting, transactionality, etc. and keep actual business logic implementation in POJO's driven by some IoC container. Then EJB code will look something like this (with XDoclet annotations):
private RequestProcessor requestProcessor;
/**
* @ejb.interface-method view-type = "both"
* @ejb.transaction type = "RequiresNew"
*/
public String request( String msg) {
return requestProcessor.submitSync( msg);
}
Where requestProcessor is a POJO managed by Spring. Note that code is so simple that practically require no testing at component level.
This is how service components are wired together.
Notice that POJO component can be still used outside container (e.g. in a standalone client), which is particularly handy for testing and debugging.
The above approach has several significant benefits during development. The following table provides comparison between EJB and POJO-based component development. As you can see, POJOs make testing easier and the time for the entire change/build/deploy/test/verify cycle is about 5...10+ times less in this case and allows more dynamic development process.
| -- |
EJB |
POJO |
| Change |
Force to use Component
Oriented and limited Object Oriented |
Object Oriented |
| Build |
Slow because require to build deployment
package, generate stubs
Can be optimized with proper toolset (e.g. when deploying exploded
application),
but this introduces additional risk and require additional testing for
the real deployment configuration. |
Fast, because there is no overhead to generate
stubs, etc.
|
| Deploy |
Slow in most cases because J2EE container does
lot of expensive initialization.
|
N/A |
| Startup |
Slow. J2EE application server startup takes lot
of time. |
Fast. IoC containers can use lazy initialization and load only active components.
|
| Test |
Require special approach to test local beans,
e.g. Cactus (but this usually increases build time because tests
require additional stubs). Testing of the asynchronous components such
as MDB is even more challenging.
|
Plain JUnit. Can be tested directly from the IDE and does not require to redeploy entire application to test only
changed component.
|
| Verify |
Challenging, because it is difficult to mock the dependent services and prepare preconditions for testing.
|
Very flexible. Depended services and
preconditions can be mocked or stubbed, which allows to cover more code
with less effort.
|
| Average time |
0.5-5 minutes for not very big component. |
2-10 seconds for the same component |
There are many other benefits with POJO-based implementation that I'd like to talk about in other posts.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Where does AOP fit into this picture? For example, using AOP combined with IoC, I could have a POJO and apply a transactional veneer to it. See Implementing Transaction Suspension in Spring for example. This seems to be pushing SSBs out of the door a little?
Posted by: jonmountjoy on August 15, 2005 at 7:07 AM
-
Jon, see the very last sentence of my post. I save this for later blogs. ;-)
Posted by: euxx on August 15, 2005 at 7:57 AM
-
Great post - totally agree with it. Infact, if you look at CORBA, it has the same concept of a distributed object that needs to be network aware and "servant" objects which is where the business logic is coded. The servant classes are POJOs. This approach also makes it easy to reuse existing code.
Posted by: nsimha on August 17, 2005 at 2:06 PM
-
I couldn't agree more that POJO's have advantages, and that using AOP to provide flexible, a la carte implementations of services is a much better way than EJB. I also think using pointcuts based on stable properties is even better than littering POJO's with entangling annotations.
Ron Bodkin
Posted by: rjbodkin@excite.com on September 14, 2005 at 3:47 AM
-
I dont think the Development to Deployment cycle will always take long time once its fixed up(Just get setup once with ant script - a good IDE like eclipse / wsad will manage for you).
What about the issue like threading, transactions -- more issue when you get up with POJO.
Posted by: jignesh_rangwala@yahoo.com on September 30, 2005 at 3:44 PM
-
jignesh, Spring can handle transactionality, multithreading and even make POJO's message-driven and all of this is supported by BEA already. However you can still use good old EJB's and MDB as I've suggested in my post, because POJO's don't really need to know about transactions and threading. Those are ortogonal concerns and can be handled externally (either in EJB code itself, or using thin advices for Spring-managed pojos).
I also doubt that testing business logic implemnted in EJB with hot deployment and even with good IDE support can outperform unit testing of the business logic implements in POJO's with using mocked dependencies. For integration testing you would need a container in both cases, but that is another story.
Posted by: euxx on October 1, 2005 at 2:10 PM
-
I used the approach presented above on a precedent project, without using Spring though, something I would do now. I just would like to tell that you must be careful with the fact that when you are using POJO's, you are in a reference semantic. When you call your functionality through an EJB, you are in a copy semantic. When you code your JUnits, beware of that if your JUnits are a bit more than just pure unit tests, but perform some degree of integration testing !
Posted by: ange on June 14, 2006 at 12:59 AM
|
