Hi,

The spec says you are allowed to open a Client Socket
but not a Server Socket from an EJB.

Ejb 2.0 Section 24.1.2 - "Programming Restrictions"

"
� An enterprise bean must not attempt to listen on a
socket, accept connections on a socket, or
use a socket for multicast.

The EJB architecture allows an enterprise bean
instance to be a network socket client, but it does
not
allow it to be a network server. Allowing the instance
to become a network server would conflict with
the basic function of the enterprise bean-- to serve
the EJB clients.
"

Doing IO does not directly give you serializable
errors. The spec says the reason you are not meant to
use the java.io package is as quoted,

"The file system APIs are not well-suited for business
components to access data. Business components
should use a resource manager API, such as JDBC, to
store data."

IMHO

> >A.with a Java class that uses a JMS to interact
> with the inventory system

Can the inventory system some how act as a JMS client?
 Is asynch communication between the two systems ok?
Is so it would work.  If not what benefit is JMS
giving you?

> >B.with a distributed CORBA object that uses IIOP to
> interact directly with
> >the inventory system

CORBA is just as bad to handle as Socket
communication.

> >C.with an EJB Tstateful session bean that uses Java
> sockets to interact
> with
> >the inventory system

Why stateful?  Stateless EJBs scale much better. Write
a java class that encapsulates the protocol logic.  If
in the Stateless EJB method you wish to communicate
with the invetory system you can instantiate one of
these classes and off you go.

Singletons can be used if you wish to pool connections
however Singletons in J2EE can be tricky and pooling
of socket connections may be more effort than its
worth.

You can use stateful EJBs but you have to make sure
the connection if it is part of the conversational
state gets closed/open every time the bean gets
activated/passivated.

> >D.with an EJB entity bean that uses
> container-managed persistence to
> >encapsulate the inventory system
> >

Entity Beans general work best with JDBC.  I would
stay clear of doing anything else with them.

JCA

As for JCA it is a good idea for connecting things
like a back office system (Siebel) to you container.
It allows you to work with the back office system just
the same as you would work with a JDBC connection
pool.  Transactions, security etc are handled by the
container and the JCA resource adapter.  For simple
socket communication it is probably overkill.

David

--- "Kesav, Ramesh" <[EMAIL PROTECTED]> wrote:
> The first One
> --------------
> You are right. By specification, you are not allowed
> to use IO in EJB. If
> you do, there will be a runtime error, because IO
> classes are not
> serializable.
>
> To solve this problem, there are two options:
>
> 1) use JMS, as suggested by your friend. This allows
> decoupling between your
> EJB and the TCP/IP class. Less efficient.
>
> 2)  Use a singleton class that keeps a TCP/IP
> connection. Your EJB
> references this singleton as a local variable in a
> method, but should not
> keep it as a member variable. This will avoid
> runtime error. It is a simple
> and efficient method.
>
>
>
> worth another try is
> --------------------
> Assuming that the app server is initiating the
> interaction with the
> inventory devices I recommend looking at the JCA for
> abstracting the
> interaction. (requires a J2EE 1.3 compliant server
> otherwise there is a bit
> of hacking required for 1.2.)
>
> As for session bean vs entity bean it would depend
> on what level the app is
> interacting with the devices and how smart they are.
> If you communicate with the devices at a fairly low
> level (e.g. close to
> primitive data manipulation) then use entity beans
> with bean managed
> persistence.
> If the devices are smart/functional then use session
> beans as a facade to
> the high level functions provided by the devices.
> In either case incorporate the JCA if you can. It is
> particularly useful for
> proprietary connections.
>
>
> Regards
>
> Ramesh Kesavanarayanan
> EDS
> [EMAIL PROTECTED]
>
>
> >hi all
> >
> > 2.A shipping company is building an enterprise
> system to track the
> location
> >of packages.One part of the tracking sys-
> >tem is a network of wireless inventory devices.The
> devices can only be
> >accessed using a custom,synchronous TCP/IP
> >protocol.How should you encapsulate interaction
> with the wireless inventory
> >system?
> >
> >A.with a Java class that uses a JMS to interact
> with the inventory system
> >B.with a distributed CORBA object that uses IIOP to
> interact directly with
> >the inventory system
> >C.with an EJB Tstateful session bean that uses Java
> sockets to interact
> with
> >the inventory system
> >D.with an EJB entity bean that uses
> container-managed persistence to
> >encapsulate the inventory system
> >
> >My doubt
> >  Can I open a socket connection from a session
> bean? After all Iam using
> >few I/O operations
> >which is not allowed according to the specification
> and most of the
> >appservers do not allow
> >I/O operations. Am I missing some thing??
> >
> >thanks in avance
> >ramesh
> >
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED]
> and include in the body
> of the message "signoff EJB-INTEREST".  For general
> help, send email to
> [EMAIL PROTECTED] and include in the body of the
> message "help".
>



=====
David J. Jones, <[EMAIL PROTECTED]>,
Virgin Mobile USA,
8th Floor,
22 Fourth Street,
San Francisco,
CA, 94103,               Work: 415 932 5470.
USA.                     Fax:  415 358 4999.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to