EJBs as active components?

[Vjeran Marcinko]

Hi folks.

I'm total newbie in J2EE, so can someone explain me following about ejbs -
I know that usually client application should connect to EJB server to perform business logic by one of well-defined protocols, but let's say I want to create my own server-socket component that will accept client calls through my custom protocol and dispatch requests to appropriate business level EJBs.
Am I supose to make this active server-socket component inside EJB container as some EJB (is this entity bean then?!), or as separate java application that will decode client requests and dispatch them to EJB server by known protocol ?

Regards,
Vjeran

 

[Collin VanDyck]

Your EJB Entity beans represent data, or more commonly, rows in database
tables. Your EJB Session beans are more along the lines of what you are
probably getting at. If I were to approach this, I'd probably attempt to
write a server that listened on your proprietary protocol, and then made
requests on the EJB Session beans that would then communicate with the EJB
Entity beans.

Hi folks.

Am I supose to make this active server-socket component inside EJB container
as some EJB (is this entity bean then?!), or as separate java application
that will decode client requests and dispatch them to EJB server by known
protocol ?

Regards,
Vjeran

 

[John C. Bollinger]

I'm total newbie in J2EE, so can someone explain me following about ejbs -
I know that usually client application should connect to EJB server to perform business logic by one of well-defined protocols, but let's say I want to create my own server-socket component that will accept client calls through my custom protocol and dispatch requests to appropriate business level EJBs.
Am I supose to make this active server-socket component inside EJB container as some EJB (is this entity bean then?!), or as separate java application that will decode client requests and dispatch them to EJB server by known protocol ?

Short answer: the latter.

Longer answer:
EJBs are not permitted to open server sockets, or to do any of a number
of other things that might interfere with their management by the EJB
container. A component that needed to perform those sorts of operations
would need to be outside the EJB container, but not necessarilly outside
the whole J2EE server.

One solution would be to use a J2EE server with an integrated servlet
container, and to install your custom component in the servlet
container. This could be by means of making it a ServletContextListener
in some (possibly empty, otherwise) web application. That way your
custom component could talk to the EJBs via their local interfaces.

Alternatively, you could put the custom component into a standalone
application. You would need to communicate with the EJBs via their
remote interfaces in this case. The only advantage I see here is not
needing to know anything about the servlet API. Other than that, doing
it in a webapp associated with the J2EE server that hosts the EJBs has
only advantages.


John Bollinger
(e-mail address removed)

 

[Michael Borgwardt]

Thx. I found some document about ejb restrictions and it is stated there that usage of java.io.*
should be avoided ? Why is that ?

Wasn't a very good document if it didn't explain the reasons. This one does:
http://www.javaworld.com/javaworld/jw-08-2000/jw-0825-ejbrestrict.html

Actually, the restriction only applies to *file* access, not network IO.
And that's because files are local to a specific machine and EJBs are
supposed to be migrateable between machines.

I have some components that inside it's business methods perform socket connection to some other
special-purpose servers (java.net* and java.io.* classes are used) and I want to convert them
to EJBs... That means that such components are impossible to convert ?

According to the document above, that's explicitly allowed. You just shouldn't
*liste* for socket connections or use multicast.

 

[Vjeran Marcinko]

Short answer: the latter.

Longer answer:
EJBs are not permitted to open server sockets, or to do any of a number
of other things that might interfere with their management by the EJB
container. A component that needed to perform those sorts of operations
would need to be outside the EJB container, but not necessarilly outside
the whole J2EE server.

One solution would be to use a J2EE server with an integrated servlet
container, and to install your custom component in the servlet
container. This could be by means of making it a ServletContextListener
in some (possibly empty, otherwise) web application. That way your
custom component could talk to the EJBs via their local interfaces.

Alternatively, you could put the custom component into a standalone
application. You would need to communicate with the EJBs via their
remote interfaces in this case. The only advantage I see here is not
needing to know anything about the servlet API. Other than that, doing
it in a webapp associated with the J2EE server that hosts the EJBs has
only advantages.

Thx. I found some document about ejb restrictions and it is stated there that usage of java.io.* should be avoided ? Why is that ?
I have some components that inside it's business methods perform socket connection to some other special-purpose servers (java.net* and java.io.* classes are used) and I want to convert them to EJBs... That means that such components are impossible to convert ?

Regards,
Vjeran

 

[Emanuel Bulic]

You want a standalone java app.. open a socket, accept connections,
and do the custom protocol thing.

Actually, my first suggestion is, use web-services, since you probably
need this in order to get around some network security issues. But,
anyway, a standalone application, outside the ejb container, is
probably the best approach, for reasons already mentioned. you don't
want to clutter your ejb's with any of these things anyway.