aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes pojo into ejb & web services Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "pojo into ejb & web services" Watch "pojo into ejb & web services" New topic
Author

pojo into ejb & web services

Rohit Chatterjee
Greenhorn

Joined: Feb 23, 2005
Posts: 4
Hi All

Hope you can help me on this

I have a java class (POJO) which comprises of business logic methods.
This POJO invokes the DAO which inturn calls the database stored procedure
to persist the data

Now I have been told to make this POJO available as an EJB and a web service too.

Could i attain something like this

I dont want to disturb the existing POJO
I want the EJB or web service only as a wrappers on top of ther existing POJO
I dont want to duplicate the same logic in the EJB & Webservice

Can i make my EJB & webservice something like a router to the POJO rather than
duplicating the whole business functionality all over again inside the EJB & the
Webservice

Kindly respond. If the above scenario looks feasible also I would be glad if someone
posts details about how to go about the same


Regards
Rohit
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Rohit,

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
    Rohit Chatterjee
    Greenhorn

    Joined: Feb 23, 2005
    Posts: 4
    Valentin


    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
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704

    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).
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    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).
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: pojo into ejb & web services