Not everything using EJB has to BE an EJB. In your example, any kind of EJB
would be a poor choice for a port listener, due to the
passivation/activation constraints that you have to deal with. So:
a. If you choose to create a stateless session bean, the container could
create a number of them, causing all but the first one to fail (since only
one can really listen to the port at the same time). Also, you have little
control over how a particular container will choose to create/remove your
stateless session beans.
b. If you create a statefull session bean, you might have a similar problem.
Also, someone has to create the bean to start the process. Something has to
"bootstrap" the create mechanism.
c. Using Entity is out of the question since this is not what they were
created for.
What you really want to do, is write a small client application which does
what you need (i.e. listens on a port), and then posts a message into some
queue/topic. At this point you can have an MDB listening on the port to
perform some action. In the script to start your server, you can also start
up the client application which goes along with the server.
Weblogic allows you to register startup/shutdown classes, you can use this
facility to start your client automatically.
As far as creating a connection only once, you can use statics to initialize
the collection, and expose the functionality through stateless session
beans. In this scenario EACH of your EJB servers in the cluster will open
such a connection (since they are not aware of each other).
The other way, is to create a RMI object, and put this object into the JNDI
name space. Then some stateless session deployed on various servers could
all lookup this "SINGLE" RMI object and invoke methods on it. This
introduces a single point of failure, but you need to decide if this is
acceptable to your implementation.
-AP_
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews
Sent: Sunday, July 01, 2001 3:54 PM
To: Orion-Interest
Subject: Re: Question about port listener
yes, but theoretically, EJBs aren't supposed to interact with the real
world, i.e. they're not supposed to manipulate files, open sockets, or do
anything useful unless it's through the container's services.
you're choices are:
1. do what you said, i.e. open a socket. it would be against the spec but
who cares if it works right?
2. if everyone's on the same network, look at using JMS, and then getting
your client to put a message in the JMS
3. open the socket from a servlet, not a bean, which is sort of the same as
option 1 but within the EJB spec.
----- Original Message -----
From: "Karri Niemelä" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Saturday, June 30, 2001 3:03 AM
Subject: Question about port listener
> Question 1) Is it possible to build an bean, which is some sort of tcp
port
> listener?
> Idea is to listen for traffic on port and then fire an even/send a msg to
> queue if something is received
>
> Question 2) What if we have an 3rd party java api to connect some server
> using rmi
> (for an example an api which builds up an connection to short message
> center)
> Would it be possible to create an bean which builds up this connection(and
> does this only once),
> keeps it up and listens for method calls from clients and then sends them
> away
>
>
>
>
