Yes it might work and there is a pretty simple idea: use a proxy pattern. All you have to do is to use a SLSB that keeps a reference to your POJO (your POJO is an attribute of the bean class). Define your bean to have the same business method, matching your POJO�s method signiature. Inside every such method make a call to the internal private instance of your POJO. This will definitely work. However there are several thinks that you need to take care of:
The return values as well as the input arguments must be serializable. If your POJO doesn�t convey to this limitation then you have to either change your POJO, or do more work in your bean class in order to convert this types.
All thrown exception must be serializable. Otherwise you need to catch them in your bean and throw serializable exception.
Check the transaction management, this might be more difficult to convert. I would expect that your POJO is using JDBC api for managing the transactions. That�s fine, but instead of using the classic DriverManager you might like using a DataSource and take advantage of the connection pooling that your container provides.
If there are any security checkings you probably have to redesign this from scratch.
Logging needs also to be revisited; if you use log4j for example you might face a configuration challenge (not big deal anyway).
Become familiar with the application packing, since you might provide a jar or a war. You probably need to understand you container�s class loading architecture as well.
If your POJO is using any Swing/AWT features then you better tell your manager to forget about�
Bottom line is that this looks like a pretty simplistic task, but it could soon get really complex.
I think, therefore I exist -- Rene Descartes
Joined: Feb 23, 2005
Thanks a lot for your response. The way you have explained is very apt to the current scenario we have though AWT, Swing (never) as well as Security currently is not a part of our application currently
Point 1 is well taken.
your 2nd point mentions about making excpetions serializable. I don't think that would be required as the root Exception class does impelement Serializable.
I would be very glad if you could ellaborate a bit more on transaction management, Log4j & application packaging as these definately figure in our application
Thanks & Regards Rohit
Joined: Feb 17, 2005
I would be very glad if you could ellaborate a bit more on transaction management
As you know if you use enterprise beans you might choose between bean managed transaction (BMT) or container managed transaction (CMT). Entity beans are the only exception from this rule, because only CMT is allowed with entity beans. So in case of using SLSB (which I would recommend) you have to choose whether to use low-level transaction API or you want to use the implicit transaction model provided by your container. In a nutshell the second approach is preferred since the container will take care of your transactions management. You don�t need to write any code and your only concern should be about setting the right transaction demarcations, using transaction attributes in your deployment descriptors. There is a limitation though: J2EE doesn�t support nested transactions. If you need nested transactions, maybe J2EE is not the right choice for you. Although this could be achieved in some cases, using a JDBC driver that supports nested transaction, is not a portable solution and is database vendor specific. You might consider another approach though. If your POJO has already transaction logic encapsulated you might like keeping the code and that�s just fine. However you must be aware about the two most used techniques for implementing BMT: using JTA/JTS api or using JDBC api (you might find lot of resources about both of them on the net). In a nutshell the difference between the two is that with JTA you can achieve distribute transactions (your transaction can span multiple containers or different databases, etc). This also requires installing an XA compatible driver, so check your driver�s documentation. Again if your POJO has implemented the transaction logic you mostly are using JDBC & DriverManager (rather than a Data Source) and you cannot implement (without rewriting the code) distributed transaction which you might not need though);
Log4j & application packaging
log4j requires a configuration file either in xml format or a properties file (named log4j.xml/log4j.properties). This file must be located in your container�s classpath in order for log4j to be initialized properly. It also requires the log4j.jar library to be in your application�s classpath (if both xml or properties files are presented in the classpath, then log4j will prefer the xml version).
Joined: Feb 17, 2005
And by the way, sorry to confuse you with the serializable exception. You are right, they all implement the Serializable interface. This brings another good point however: you need to understand how the container rolls back the current transaction if the application throws an exception. At a glance one might think that the container will roll back the transaction all the time if an exception is thrown. Well this is not true actually: the container rolls back automatically the transaction, only if a RuntimeException is thrown. Otherwise, if an application exception is thrown, it is the application�s responsibility to catch the exception and rollback the transaction (with CMT you can use the EJBContext.setRollbackOnly() call).