webcream alternative? (for web-enabling java GUI app)

[Alex Hunsley]

I'm looking at transferring a java GUI program to have a web reachable
interface. Webcream looks fine for this (see http://www.creamtec.com/webcream/)
but I was wondering what alternatives there were? Can anyone suggest any?
(either free or commercial)

thanks!
alex

 

[Alex Hunsley]

I'm looking at transferring a java GUI program to have a web reachable
interface. Webcream looks fine for this (see
http://www.creamtec.com/webcream/) but I was wondering what alternatives
there were? Can anyone suggest any? (either free or commercial)

thanks!
alex

mmm, looks like webcream's out, I've just seen the price tag... a thousand
dollars gets you a version that will support ten users concurrently maximum...
so that's out of the question.

 

[Paul Lutus]

I'm looking at transferring a java GUI program to have a web reachable
interface.

1. Offer the application as a download to your visitors.

2. Rewrite the application as a signed applet, if the latter is needed.

3. Several other options.

But you don't say what your application is or does.

 

[Alex Hunsley]

Alex Hunsley wrote:




1. Offer the application as a download to your visitors.

2. Rewrite the application as a signed applet, if the latter is needed.

3. Several other options.

But you don't say what your application is or does.

Ok, this is a commercial application that is basically an interactive
search facility. We have a windows version already which is a GUI in
which you type in various search terms, then drill down into the
results. This product executable is smallish, but uses a data set which
is updated quarterly, and the dataset is huge (many gigs of data):
hence, the advantage of a web presented version being that the customer
does not have to get huge updates sent to them quarterly, and can
casually do searches on a charge-per-search basis on any of the data
sets on the server.
The statefulness of the application is important - it's not merely
"search and then see results"; users can search, see certain results,
and then drill down more into those results. Hence, it would be
advantageous if the server back end had notions of state and could
maintain state and memory of current place in the search as the client
drills down into the data as they wish. WebCream would apparently let us
do this statefulness ok, but the cost/usefulness ratio of webcream is
not good for us (functionality limited to 10 concurrent users costs a
thousand dollars ), so I can't use that unfortunately.

alex

 

[Sudsy]

Alex Hunsley wrote:

The statefulness of the application is important - it's not merely
"search and then see results"; users can search, see certain results,
and then drill down more into those results. Hence, it would be
advantageous if the server back end had notions of state and could
maintain state and memory of current place in the search as the client
drills down into the data as they wish. WebCream would apparently let us
do this statefulness ok, but the cost/usefulness ratio of webcream is
not good for us (functionality limited to 10 concurrent users costs a
thousand dollars ), so I can't use that unfortunately.

You could do this quite readily using servlets and JSPs in a container
like Tomcat. You can store persistent data in the session context. You
should be able to develop such an application in short order.

 

[Chris Uppal]

Ok, this is a commercial application that is basically an interactive
search facility. We have a windows version already which is a GUI in
which you type in various search terms, then drill down into the
results. This product executable is smallish, but uses a data set which
is updated quarterly, and the dataset is huge (many gigs of data):
hence, the advantage of a web presented version being that the customer
does not have to get huge updates sent to them quarterly, and can
casually do searches on a charge-per-search basis on any of the data
sets on the server.

You know your own business best, but I'd have thought it would be both easier
for you and better for your customers if you network-enabled your application
instead. I.e. it could get data from the users' local disks, as now, or from a
server that you run.

-- chris

 

[Alex Hunsley]

Alex Hunsley wrote:




You know your own business best, but I'd have thought it would be both easier
for you and better for your customers if you network-enabled your application
instead. I.e. it could get data from the users' local disks, as now, or from a
server that you run.

-- chris

Hi chris
thanks for the suggestion, I hadn't thought of that!
I think that it's infeasbile, though, due to

a) the amount of network traffic involved would be just too large, I think;
b) the platform independence of having web based access to the app is a big bonus

cheers
alex

 

[Alex Hunsley]

Alex Hunsley wrote:



You could do this quite readily using servlets and JSPs in a container
like Tomcat. You can store persistent data in the session context. You
should be able to develop such an application in short order.

JSPs had crossed my mind actually. I've done a little JSP. Any reason why JNI
access to native libs would be a problem, or would that be ok in JSP?

alex

 

[Chris Uppal]

a) the amount of network traffic involved would be just too large, I
think;

Would it be that large ? I mean if the request going over the net is "get me a
list of purple jellyblobs", and the response is a list of jellyblob "handles"
that you can drill down into with further requests, then I'd have thought that
the net traffic would be a smallish fraction of the HTML-based route (same data
but more compactly encoded). It does depend on how your application is
structured, though, and how your dataflows work (which, of course, you don't
want to change even if it was possible).

b) the platform independence of having web based access to the app is a
big bonus

Yes, I can see how it would be beneficial. BTW, have you noticed that the
"enterprise edition" of webcream starts at $3000 for unlimited clients (but
only 1 host) ? That doesn't sound too unreasonable to me for a "big bonus" ;-)

-- chris

 

[Sudsy]

Alex Hunsley wrote:

JSPs had crossed my mind actually. I've done a little JSP. Any reason
why JNI access to native libs would be a problem, or would that be ok in
JSP?

No limitation of which I'm aware . But I'd heed the suggestion given by
others here that you minimize the number of calls. Apparently crossing
the barrier (Java->Native) is quite expensive in terms of cycles.
It shouldn't take more than a couple of days to throw together a "proof
of concept".