Avatar billede fredand Forsker
01. juni 2006 - 14:34 Der er 13 kommentarer og
1 løsning

Does Tomcat 5.5 support EJB 2.0 and Message Driven Beans?

Hello!

We wonder if Tomcat 5.5 support EJB 2.0 and Message Driven Beans?

Is it possible to create topics and queues in Tomcat 5.5 and let MDB:s listen for incomming messages?

We also wonder if it is possible to create "bridges" like in WebLogic on these queues and topics so that messages posted in tomcat gets forward to say MQ for eg.

Best regards Fredrik
Avatar billede arne_v Ekspert
01. juni 2006 - 14:37 #1
Tomcat is servlet container only - no EJB's at all.

JBoss comes with Tomcat and have full EJB support (and the price is the same).
Avatar billede arne_v Ekspert
01. juni 2006 - 14:39 #2
Tomcat does not have builtin JMS support, but you can embed a message queue
system in Tomcat yourself.
Avatar billede fredand Forsker
01. juni 2006 - 17:29 #3
Thanks for your answer!

Perhaps I could ask you what you think of this.

A customer just have Licencse for WebLogic 8.1 that supports EJB 1.0

The customer needs a asynchrone integration between WebLogic and WebSphere our suggested solution is JMS and use of MDB:s. But as, I guess told me, MDB:s is only available in EJB 2.0 we got a problem.

The upgrade for a WebLogic license for this customer to be able to use EJB 2.0 is a big investment.

So now we are looking for either other cheaper applicationservers that supports EJB 2.0 or some other solution then MDB:s.

Perhaps JBoss with Tomcat will be the only solution or is there some alternative to a own MDB-implemtation that just need EJB 1.0?

It may sound like this is a stupid idea to try to implement a own solution of MDB.

What do you think?

Best regards

Fredrik
Avatar billede arne_v Ekspert
01. juni 2006 - 19:18 #4
According to http://e-docs.bea.com/wls/docs81/compatibility/compatibility.html
WebLogic 8.1 i J2EE 1.3 compatible which implies EJB 2.0 support.

But I assume you mean 6.1 or 7.0 or some other old versions that only support EJB 1.x.

JBoss (with Tomcat) sounds as an excellent solution.
Avatar billede fredand Forsker
02. juni 2006 - 08:56 #5
Hello!

Thanks for your answer. According to the link in your reply I must say that it seems very strange that our customer says that they do not have a WebLogic Licens of 8.1 that do not support EJB 2.0 and MDB:s. I need to verify this. If thay have license for a WebLogic 8.1 like your link refers to then the problem is solved, right?

How ever I have heard that thay have some cheap licens for WebLogic 8.1 that just supports EJB 1.0. Thats way we got this problem. Unfortunately our projectmanager just accepted to implement an integration based on JMS.

The solution now is looking:
weblogic got 2 server instances
Server a got a webapp.
Server b got a ejbapp with MDB:s

When sometihing happens (a specific database update) on a, b gets notfied via JMS and MDB:s and take care of the task for a.

Assume that the customer just have EJB 1.0 and do not want to invest anything more in licenses, during the night I thought of this solution then without MDB:

weblogic got 2 server instances
Server a got a webapp.
Server b got a threaded app that every minute checks a queue for new JMS-messages from a. If there is any messages b consumes the messages and performs the tasks for a.

Do you see anything bad with this solution? Using a thread to schedule a task perhaps is bad. Perhaps there is anything built in in appserevers that we could use instaead?

Any comments is appreciated?

Best regards
Fredrik
Avatar billede fredand Forsker
02. juni 2006 - 13:14 #6
Hello!

We just did a very quick test for a own home-made solution for MDB:s.

In the JMS-api there is a method "setMessageListener" in the TopicSubscriber interface. We created a Servlet that in the init method does something like this:

properties = new java.util.Properties();
properties.load(new FileInputStream(fileName));
properties.setProperty("java.naming.provider.url", properties.getProperty("protocol")+properties.getProperty("url")+properties.getProperty("port") );
jndiContext = new InitialContext(properties);

topicConnectionFactory = (TopicConnectionFactory)jndiContext.lookup( properties.getProperty("connectionfactory") ); 
topicConnection = topicConnectionFactory.createTopicConnection();
topicConnection.start();

topicSession =  topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);       
topic = (javax.jms.Topic) jndiContext.lookup(topicName);
TopicSubscriber topicSubscriber = topicSession.createSubscriber(topic);

topicSubscriber.setMessageListener(new OrderManager());

The Servlet creates a TopicSubscriber that has a MessageListener in form of a class called OrderManager. The servlet is loaded at start up like:

  <servlet>
    <servlet-name>BeanInitServlet</servlet-name>
    <servlet-class>BeanInitServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>


The Ordermanager Looks like:


import java.util.*;
import javax.naming.NamingException;
import javax.jms.*:
import java.io.*;

import javax.jms.ObjectMessage;

public class OrderManager implements MessageListener
{

    public void onMessage(Message message)
    {
        try
        {
            TextMessage textMessage = (TextMessage)message;

            System.out.println(textMessage.getText());

        }
        catch(Exception e)
        {
        }
    }
}

This acctually works fine!

Could it be like this the MDB-framework is implemented i a applicationserver?

Do you see anything crazy or that it may result in bad performance with this solution in comparation to a real MDB-solution?

Best regards
Fredrik
Avatar billede arne_v Ekspert
03. juni 2006 - 01:32 #7
The listener is many times better than a polling thread.

Functional your code appears to be doing what a MDB are doing.

But there are differences.

The biggest is probably that a MDB participate in EJB transactions !
Avatar billede fredand Forsker
04. juni 2006 - 19:09 #8
Hello!

Thank you for your very interesting comment. I guess what you say means that my code my be very risky then.

I have to admit that I do not know what or when to use EJB-transactions. Could I ask you to "describe" a very small scenario about it. I just know about JDBC-transactions. Suppose that we should do 2 updates for each received JMS-message. If the second fails we should rollback the first one. Does the EJB-transactions fit in this simple scenario or is it on a higher level thats probaply is new to me?

Best regards
Fredrik
Avatar billede arne_v Ekspert
06. juni 2006 - 16:50 #9
Not necesarrily risky. It depends entirely on whether your code
is depending on EJB transaction support or not. But it is a service
that your alternative code does not provide.
Avatar billede arne_v Ekspert
06. juni 2006 - 16:54 #10
The important thing is that if you have a transaction then a rollback will
rollback all database changes and the message will be redelivered.
Avatar billede fredand Forsker
07. juni 2006 - 08:56 #11
Hello!

Thanks agian for your very interesting comments.

I have been looking at Geronimo from apache. Perhaps this is a solution for us.

I guess it is a freeware/opensource if I'm right and it looks like it uses OpenEJB that might support EJB 2.0 => MDB-support.

I tried just to set up a OpenEJB server but I did not got it to work.

Best regards
Fredrik

BTW give a svar so I can reward you.
Fredrik
Avatar billede arne_v Ekspert
09. juni 2006 - 04:33 #12
I am sure that Geronomi supports EJB 2.0 probably also 2.1
Avatar billede arne_v Ekspert
09. juni 2006 - 04:33 #13
personally I like JBoss
Avatar billede arne_v Ekspert
09. juni 2006 - 04:33 #14
svar
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Uanset kodesprog, så giver vi dig mulighederne for at udvikle det, du behøver.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester