Is JCA approriate?

[Reinf]

Hello group,
I am working on a data broadcasting system(in java) which communicates
with
one physical broadcast card via JNI. The system itself is composed of
several EJBs and a web interface. And now we are redesigning the system in
order to work with more than one broadcast card, which involves the
management
of multiple hardware resource.
My colleague suggestted the use of JCA(j2ee connector architecture), and
his
reason is that JCA includes features like Transaction processing, resource
pool
and etc, though it might sounds differrent from what Sun suggested.

Do you think JCA is really approriate for this purpose? And your reasons
please.
Thank you






reinf

 

[Lee Fesperman]

Hello group,
I am working on a data broadcasting system(in java) which communicates with
one physical broadcast card via JNI. The system itself is composed of
several EJBs and a web interface. And now we are redesigning the system in
order to work with more than one broadcast card, which involves the
management of multiple hardware resource.
My colleague suggestted the use of JCA(j2ee connector architecture), and
his reason is that JCA includes features like Transaction processing, resource
pool and etc, though it might sounds differrent from what Sun suggested.

Do you think JCA is really approriate for this purpose? And your reasons
please.
Thank you

The interface you're describing sounds like a device driver style interface. JCA is
apparently intended for complex backend software systems, listing database servers,
application packages like CRM/ERP and messaging systems.

JCA might be overkill for your situation, but I do think it could be possibility. It is
a fairly complicated API, so the question is -- is it worth the effort?

Note: Though JCA provides a standardized transaction interface for container sofware
(like, application servers), your software will need to handle the actual transaction
processing. JCA also supports distributed transactions, but you must provide the XA
implementation as a resource manager.

My JDJ article on JCA might help you make your decision:
http://sys-con.com/story/?storyid=46283&de=1.

 

[Reinf]

Hello Lee,
Thanks for your reply!
I fully agree that JCA is a little overkill for this case, so what kind
of tool/framework would you suggest?

The management of multiple broadcast cards involves the following issues:
* Session support: That is, when the user logged in and started the
broadcasting of a specified card, the current
session state shall be stored so that the state could be restored the next
time he logs in. This means that a new session is
created immediately after a user starts the broadcasting of a card. The
session associates the user and the card.
We call this user the (temporary) "owner" of this card(within the session
scope). A user could be the owner of more than
one card.

* Status: A broadcast card could be in two status: Idle, Busy. Idle means
the card is ready, but nobody is using it,
and "Busy" means that card is using(locked) by a specified user.
A card turns from "Busy" to "Idle" when it's owner or the Administrator
stopped the broadcasting, and thus the session ends.

* Permission: When the broadcast of a card is started, no any other user
could stop it, except the Administrator and his owner.
So there will be two-kinds of permissions for the broadcast card:
read-only(View current status) and
write(Transmit data thru the card). Read-only permission is available to all
the users, while write permission is only available to
it's Owner and the Administrator.

Preferably, the framework could also support a list of allow/denied list of
hosts.

Thank you!


----- Original Message -----
From: "Lee Fesperman" <[email protected]>
Newsgroups: comp.lang.java.programmer
Sent: Thursday, November 04, 2004 6:42 AM
Subject: Re: Is JCA approriate?

 

[Lee Fesperman]

Hello Lee,
Thanks for your reply!
I fully agree that JCA is a little overkill for this case, so what kind
of tool/framework would you suggest?

Yes, JCA seems to be too much for your purposes.

The management of multiple broadcast cards involves the following issues:
* Session support: That is, when the user logged in and started the
broadcasting of a specified card, the current
session state shall be stored so that the state could be restored the next
time he logs in. This means that a new session is
created immediately after a user starts the broadcasting of a card. The
session associates the user and the card.
We call this user the (temporary) "owner" of this card(within the session
scope). A user could be the owner of more than
one card.

* Status: A broadcast card could be in two status: Idle, Busy. Idle means
the card is ready, but nobody is using it,
and "Busy" means that card is using(locked) by a specified user.
A card turns from "Busy" to "Idle" when it's owner or the Administrator
stopped the broadcasting, and thus the session ends.

* Permission: When the broadcast of a card is started, no any other user
could stop it, except the Administrator and his owner.
So there will be two-kinds of permissions for the broadcast card:
read-only(View current status) and
write(Transmit data thru the card). Read-only permission is available to all
the users, while write permission is only available to
it's Owner and the Administrator.

Preferably, the framework could also support a list of allow/denied list of
hosts.

I don't know of an appropriate design pattern or tool for the overall structure. There
might be some choices for certain parts -- for example, using java.io interfaces for the
data transfer portion. I think you'll need to 'roll your own' for the overall structure.