Applet client calling servlet/EJB database backend

[ChuckO]

I've been doing some fat client applet development connecting with JDBC to
Oracle for a while. Now, our clients are getting tired of downloading the
large .jar files and having to update their .java.policy file every time
we change the database location. So the question, is anybody using a rich
GUI front end applet to call a servlet or EJB that is connecting to a database?
We want our apps to look like a "traditional" client/server C++ application
(ie using a JTable to display rows and GUI cell renderers, instead of an
HTML table with just text), but I'm thinking with the Java security, we'll
need to make the connection from the servlet or EJB to the db to avoid having
to have each client update their .java.policy with that IP address. We're
also going to move most of our business logic to the back end, but then how
can we reference all of the JTextFields on our content pane wihtout passing
a huge name pair string to the doGet call? I'd rather pass the applet and
use our xxxFld.getText calls, but is serializing and passing an entire applet
across the lines going to be too much to deal with? Any suggestions would
receive a warm welcome.

[mark]

We are doing this two ways.

The first requires a Java frontend and backend. We use the Plugin so all
we have to download is our code. We are sending serialized java objects
back and forth using the technique described in "Java Servlet Programming"
by Jason Hunter. We have customized it for our use. The serialized object
contains databeans and command information. This can be as simple or complex
as you wish. Just remember that everything must be serializable (i.e. no
ArrayList - use Object arrays).

Secondly - Use XML to serialize objects and commands. This has some advantages
and complications. It is flexable - your front end can be different from
your backend (Java applet and (gulp) ASP back - I am doing this because
of Client request). This basically is a simple version of Web Services.
The major downside is the download of XML Jars. If you really want to use
this techinique, get everything coded and figure out what classes you need
from whatever XML parser you will use and jar up only the classes you need.
The other complication is that this may run a little slower than serialized
java objects.

We went to this because we wanted to avoid one of the biggest headaches in
programming - figuring out why something doesn't work on the client machine.
Now we don't have to install JDBC drivers, MQ Clients, etc but still get
a 'rich client'.

Mark

"ChuckO" <ckj@longsol.com> wrote:
>
>I've been doing some fat client applet development connecting with JDBC
to
>Oracle for a while. Now, our clients are getting tired of downloading the
>large .jar files and having to update their .java.policy file every time
>we change the database location. So the question, is anybody using a rich
>GUI front end applet to call a servlet or EJB that is connecting to a database?
> We want our apps to look like a "traditional" client/server C++ application
>(ie using a JTable to display rows and GUI cell renderers, instead of an
>HTML table with just text), but I'm thinking with the Java security, we'll
>need to make the connection from the servlet or EJB to the db to avoid having
>to have each client update their .java.policy with that IP address. We're
>also going to move most of our business logic to the back end, but then
how
>can we reference all of the JTextFields on our content pane wihtout passing
>a huge name pair string to the doGet call? I'd rather pass the applet and
>use our xxxFld.getText calls, but is serializing and passing an entire applet
>across the lines going to be too much to deal with? Any suggestions would
>receive a warm welcome.

[ChuckO]

Thanks a bunch Mark!

We haven't had much luck getting serialization to work. We found one article
by Chad Darby that gives a relatively good example that we are working from.
It seems like we're able to pass an object to the servlet and change state,
but then we can't get the servlet to return that object back to the applet.
I'll see if we can track down that book by Jason Hunter you mentioned.

Since some of our applets are quite large, are you having any problems with
speed or bandwidth issues passing back and forth these large serialized objects?

"mark" <mnuttall@nospam.com> wrote:
>
>We are doing this two ways.
>
>The first requires a Java frontend and backend. We use the Plugin so all
>we have to download is our code. We are sending serialized java objects
>back and forth using the technique described in "Java Servlet Programming"
>by Jason Hunter. We have customized it for our use. The serialized object
>contains databeans and command information. This can be as simple or complex
>as you wish. Just remember that everything must be serializable (i.e. no
>ArrayList - use Object arrays).
>
>Secondly - Use XML to serialize objects and commands. This has some advantages
>and complications. It is flexable - your front end can be different from
>your backend (Java applet and (gulp) ASP back - I am doing this because
>of Client request). This basically is a simple version of Web Services.
> The major downside is the download of XML Jars. If you really want to
use
>this techinique, get everything coded and figure out what classes you need
>from whatever XML parser you will use and jar up only the classes you need.
> The other complication is that this may run a little slower than serialized
>java objects.
>
>We went to this because we wanted to avoid one of the biggest headaches
in
>programming - figuring out why something doesn't work on the client machine.
> Now we don't have to install JDBC drivers, MQ Clients, etc but still get
>a 'rich client'.
>
>Mark
>
>"ChuckO" <ckj@longsol.com> wrote:
>>
>>I've been doing some fat client applet development connecting with JDBC
>to
>>Oracle for a while. Now, our clients are getting tired of downloading
the
>>large .jar files and having to update their .java.policy file every time
>>we change the database location. So the question, is anybody using a rich
>>GUI front end applet to call a servlet or EJB that is connecting to a database?
>> We want our apps to look like a "traditional" client/server C++ application
>>(ie using a JTable to display rows and GUI cell renderers, instead of an
>>HTML table with just text), but I'm thinking with the Java security, we'll
>>need to make the connection from the servlet or EJB to the db to avoid
having
>>to have each client update their .java.policy with that IP address. We're
>>also going to move most of our business logic to the back end, but then
>how
>>can we reference all of the JTextFields on our content pane wihtout passing
>>a huge name pair string to the doGet call? I'd rather pass the applet
and
>>use our xxxFld.getText calls, but is serializing and passing an entire
applet
>>across the lines going to be too much to deal with? Any suggestions would
>>receive a warm welcome.
>

[mark]

We haven't seem to have speed problems. Starting servlets and maybe DB connections
seem to be issues. You will want to use connection pooling and figure out
the optimal time to keep servlets around. Now we dont't serialize the whole
applet. Just data and command. And just send what you need. If you need
code let me know. I can send snippets. If you want my email account, let
me know.

"ChuckO" <ckj@longsol.com> wrote:
>
>Thanks a bunch Mark!
>
>We haven't had much luck getting serialization to work. We found one article
>by Chad Darby that gives a relatively good example that we are working from.
> It seems like we're able to pass an object to the servlet and change state,
>but then we can't get the servlet to return that object back to the applet.
> I'll see if we can track down that book by Jason Hunter you mentioned.
>
>Since some of our applets are quite large, are you having any problems with
>speed or bandwidth issues passing back and forth these large serialized
objects?
>
>"mark" <mnuttall@nospam.com> wrote:
>>
>>We are doing this two ways.
>>
>>The first requires a Java frontend and backend. We use the Plugin so all
>>we have to download is our code. We are sending serialized java objects
>>back and forth using the technique described in "Java Servlet Programming"
>>by Jason Hunter. We have customized it for our use. The serialized object
>>contains databeans and command information. This can be as simple or complex
>>as you wish. Just remember that everything must be serializable (i.e.
no
>>ArrayList - use Object arrays).
>>
>>Secondly - Use XML to serialize objects and commands. This has some advantages
>>and complications. It is flexable - your front end can be different from
>>your backend (Java applet and (gulp) ASP back - I am doing this because
>>of Client request). This basically is a simple version of Web Services.
>> The major downside is the download of XML Jars. If you really want to
>use
>>this techinique, get everything coded and figure out what classes you need
>>from whatever XML parser you will use and jar up only the classes you need.
>> The other complication is that this may run a little slower than serialized
>>java objects.
>>
>>We went to this because we wanted to avoid one of the biggest headaches
>in
>>programming - figuring out why something doesn't work on the client machine.
>> Now we don't have to install JDBC drivers, MQ Clients, etc but still get
>>a 'rich client'.
>>
>>Mark
>>
>>"ChuckO" <ckj@longsol.com> wrote:
>>>
>>>I've been doing some fat client applet development connecting with JDBC
>>to
>>>Oracle for a while. Now, our clients are getting tired of downloading
>the
>>>large .jar files and having to update their .java.policy file every time
>>>we change the database location. So the question, is anybody using a
rich
>>>GUI front end applet to call a servlet or EJB that is connecting to a
database?
>>> We want our apps to look like a "traditional" client/server C++ application
>>>(ie using a JTable to display rows and GUI cell renderers, instead of
an
>>>HTML table with just text), but I'm thinking with the Java security, we'll
>>>need to make the connection from the servlet or EJB to the db to avoid
>having
>>>to have each client update their .java.policy with that IP address. We're
>>>also going to move most of our business logic to the back end, but then
>>how
>>>can we reference all of the JTextFields on our content pane wihtout passing
>>>a huge name pair string to the doGet call? I'd rather pass the applet
>and
>>>use our xxxFld.getText calls, but is serializing and passing an entire
>applet
>>>across the lines going to be too much to deal with? Any suggestions would
>>>receive a warm welcome.
>>
>

[ChuckO]

Any code snippets you have would be great!

The only reason I mentioned serializing the entire applet and passing it
back to the servlet is for getting field content type of access. For example,
if your servlet has the business logic that checks the value of three or
four fields on your applet for validation, how can it (the servlet) do that
validation without it having the entire applet to reference the xxxFld.getText()?

We just got back from Barnes and Noble and got that "Java Servlet Programming"
book (2cnd Edition) by Jason Hunter. Ch. 10 goes into some detail about
the serialization, and I noticed he uses a content type of "application/x-java-serialized-object".
Is there some list somewhere that tells what all of the valid content types
are? I'm sure we're just big idiots in this area, but I don't know if that
is user defined or set in an RFC somewhere, but that was something different
from our code that isn't working.

Thanks again for all of your help! If there is anything I can do to reciprocate
please let me know. You obviously have a ton more expertise in this area
than myself, but if there is anything else in the IT arena you have a question
about, maybe I, or the group I work with, could help.

"mark" <mnuttall@nospam.com> wrote:
>
>We haven't seem to have speed problems. Starting servlets and maybe DB
connections
>seem to be issues. You will want to use connection pooling and figure out
>the optimal time to keep servlets around. Now we dont't serialize the whole
>applet. Just data and command. And just send what you need. If you need
>code let me know. I can send snippets. If you want my email account, let
>me know.
>
>"ChuckO" <ckj@longsol.com> wrote:
>>
>>Thanks a bunch Mark!
>>
>>We haven't had much luck getting serialization to work. We found one article
>>by Chad Darby that gives a relatively good example that we are working
from.
>> It seems like we're able to pass an object to the servlet and change state,
>>but then we can't get the servlet to return that object back to the applet.
>> I'll see if we can track down that book by Jason Hunter you mentioned.
>>
>>Since some of our applets are quite large, are you having any problems
with
>>speed or bandwidth issues passing back and forth these large serialized
>objects?
>>
>>"mark" <mnuttall@nospam.com> wrote:
>>>
>>>We are doing this two ways.
>>>
>>>The first requires a Java frontend and backend. We use the Plugin so
all
>>>we have to download is our code. We are sending serialized java objects
>>>back and forth using the technique described in "Java Servlet Programming"
>>>by Jason Hunter. We have customized it for our use. The serialized object
>>>contains databeans and command information. This can be as simple or
complex
>>>as you wish. Just remember that everything must be serializable (i.e.
>no
>>>ArrayList - use Object arrays).
>>>
>>>Secondly - Use XML to serialize objects and commands. This has some advantages
>>>and complications. It is flexable - your front end can be different from
>>>your backend (Java applet and (gulp) ASP back - I am doing this because
>>>of Client request). This basically is a simple version of Web Services.
>>> The major downside is the download of XML Jars. If you really want to
>>use
>>>this techinique, get everything coded and figure out what classes you
need
>>>from whatever XML parser you will use and jar up only the classes you
need.
>>> The other complication is that this may run a little slower than serialized
>>>java objects.
>>>
>>>We went to this because we wanted to avoid one of the biggest headaches
>>in
>>>programming - figuring out why something doesn't work on the client machine.
>>> Now we don't have to install JDBC drivers, MQ Clients, etc but still
get
>>>a 'rich client'.
>>>
>>>Mark
>>>
>>>"ChuckO" <ckj@longsol.com> wrote:
>>>>
>>>>I've been doing some fat client applet development connecting with JDBC
>>>to
>>>>Oracle for a while. Now, our clients are getting tired of downloading
>>the
>>>>large .jar files and having to update their .java.policy file every time
>>>>we change the database location. So the question, is anybody using a
>rich
>>>>GUI front end applet to call a servlet or EJB that is connecting to a
>database?
>>>> We want our apps to look like a "traditional" client/server C++ application
>>>>(ie using a JTable to display rows and GUI cell renderers, instead of
>an
>>>>HTML table with just text), but I'm thinking with the Java security,
we'll
>>>>need to make the connection from the servlet or EJB to the db to avoid
>>having
>>>>to have each client update their .java.policy with that IP address.
We're
>>>>also going to move most of our business logic to the back end, but then
>>>how
>>>>can we reference all of the JTextFields on our content pane wihtout passing
>>>>a huge name pair string to the doGet call? I'd rather pass the applet
>>and
>>>>use our xxxFld.getText calls, but is serializing and passing an entire
>>applet
>>>>across the lines going to be too much to deal with? Any suggestions
would
>>>>receive a warm welcome.
>>>
>>
>

[mark]

Content types - There are standard types. I believe you can define your own
- but whoever is on the rxing end needs to know about it. I use text/xml
if I am sending xml (standard). Not sure where a list is.

How to handle business logic - We went around on this one. It wasn't a quick
decision. Anyway how we handle it is in a MVC type of way. Only we split
up the controller. You almost have to have some business logic on the client.
You can reuse the business logic on the server to ensure validation. Other
wise you have to do round trips everytime a user makes a change. I guess
I would have to have a diagram to show what we do.


Code snippets - (modifying this a little will work for XML)

Client code
URLConnection urlConnection = null;
try
{
urlConnection = servletURL.openConnection();

// Prepare for both input and output
urlConnection.setDoInput(true);
urlConnection.setDoOutput(true);

// Turn off caching
urlConnection.setUseCaches(false);

// Set the content type to be java-internal/classname
urlConnection.setRequestProperty(
"Content-Type",
"java-internal/" + this.getClass().getName());

// Write the serialized object as post data
ObjectOutputStream out =
new ObjectOutputStream(urlConnection.getOutputStream());
out.writeObject(this);
out.flush();
out.close();
ObjectInputStream objin = new ObjectInputStream(urlConnection.getInputStream());



Object obj = objin.readObject();
// DO something with object

}
catch (IOException ex)
{
//Handle exception
}
finally
{

urlConnection = null;
}


Server Code

ObjectInputStream in = new ObjectInputStream(req.getInputStream());
YourObject yourObject(YourObject)in.readObject();

//Do something

ObjectOutputStream out = new ObjectOutputStream(res.getOutputStream());
out.writeObject(yourObject);

--
Let me know if you need anything explained. It is tough to write in this
little window.

Mark

"ChuckO" <ckj@longsol.com> wrote:
>
>Any code snippets you have would be great!
>
>The only reason I mentioned serializing the entire applet and passing it
>back to the servlet is for getting field content type of access. For example,
>if your servlet has the business logic that checks the value of three or
>four fields on your applet for validation, how can it (the servlet) do that
>validation without it having the entire applet to reference the xxxFld.getText()?
>
>We just got back from Barnes and Noble and got that "Java Servlet Programming"
>book (2cnd Edition) by Jason Hunter. Ch. 10 goes into some detail about
>the serialization, and I noticed he uses a content type of "application/x-java-serialized-object".
> Is there some list somewhere that tells what all of the valid content types
>are? I'm sure we're just big idiots in this area, but I don't know if that
>is user defined or set in an RFC somewhere, but that was something different
>from our code that isn't working.
>
>Thanks again for all of your help! If there is anything I can do to reciprocate
>please let me know. You obviously have a ton more expertise in this area
>than myself, but if there is anything else in the IT arena you have a question
>about, maybe I, or the group I work with, could help.
>
>"mark" <mnuttall@nospam.com> wrote:
>>
>>We haven't seem to have speed problems. Starting servlets and maybe DB
>connections
>>seem to be issues. You will want to use connection pooling and figure
out
>>the optimal time to keep servlets around. Now we dont't serialize the
whole
>>applet. Just data and command. And just send what you need. If you need
>>code let me know. I can send snippets. If you want my email account,
let
>>me know.
>>
>>"ChuckO" <ckj@longsol.com> wrote:
>>>
>>>Thanks a bunch Mark!
>>>
>>>We haven't had much luck getting serialization to work. We found one
article
>>>by Chad Darby that gives a relatively good example that we are working
>from.
>>> It seems like we're able to pass an object to the servlet and change
state,
>>>but then we can't get the servlet to return that object back to the applet.
>>> I'll see if we can track down that book by Jason Hunter you mentioned.
>>>
>>>Since some of our applets are quite large, are you having any problems
>with
>>>speed or bandwidth issues passing back and forth these large serialized
>>objects?
>>>
>>>"mark" <mnuttall@nospam.com> wrote:
>>>>
>>>>We are doing this two ways.
>>>>
>>>>The first requires a Java frontend and backend. We use the Plugin so
>all
>>>>we have to download is our code. We are sending serialized java objects
>>>>back and forth using the technique described in "Java Servlet Programming"
>>>>by Jason Hunter. We have customized it for our use. The serialized
object
>>>>contains databeans and command information. This can be as simple or
>complex
>>>>as you wish. Just remember that everything must be serializable (i.e.
>>no
>>>>ArrayList - use Object arrays).
>>>>
>>>>Secondly - Use XML to serialize objects and commands. This has some
advantages
>>>>and complications. It is flexable - your front end can be different
from
>>>>your backend (Java applet and (gulp) ASP back - I am doing this because
>>>>of Client request). This basically is a simple version of Web Services.
>>>> The major downside is the download of XML Jars. If you really want
to
>>>use
>>>>this techinique, get everything coded and figure out what classes you
>need
>>>>from whatever XML parser you will use and jar up only the classes you
>need.
>>>> The other complication is that this may run a little slower than serialized
>>>>java objects.
>>>>
>>>>We went to this because we wanted to avoid one of the biggest headaches
>>>in
>>>>programming - figuring out why something doesn't work on the client machine.
>>>> Now we don't have to install JDBC drivers, MQ Clients, etc but still
>get
>>>>a 'rich client'.
>>>>
>>>>Mark
>>>>
>>>>"ChuckO" <ckj@longsol.com> wrote:
>>>>>
>>>>>I've been doing some fat client applet development connecting with JDBC
>>>>to
>>>>>Oracle for a while. Now, our clients are getting tired of downloading
>>>the
>>>>>large .jar files and having to update their .java.policy file every
time
>>>>>we change the database location. So the question, is anybody using
a
>>rich
>>>>>GUI front end applet to call a servlet or EJB that is connecting to
a
>>database?
>>>>> We want our apps to look like a "traditional" client/server C++ application
>>>>>(ie using a JTable to display rows and GUI cell renderers, instead of
>>an
>>>>>HTML table with just text), but I'm thinking with the Java security,
>we'll
>>>>>need to make the connection from the servlet or EJB to the db to avoid
>>>having
>>>>>to have each client update their .java.policy with that IP address.

>We're
>>>>>also going to move most of our business logic to the back end, but then
>>>>how
>>>>>can we reference all of the JTextFields on our content pane wihtout
passing
>>>>>a huge name pair string to the doGet call? I'd rather pass the applet
>>>and
>>>>>use our xxxFld.getText calls, but is serializing and passing an entire
>>>applet
>>>>>across the lines going to be too much to deal with? Any suggestions
>would
>>>>>receive a warm welcome.
>>>>
>>>
>>
>

[tom]

ChuckO,

See Chapter 17 (?) of the Servlet & JSP Programming book, Prentice Hall,
by Marty Hall. IMO it's one of the best J2EE books around.

--A

[mdsteenb]

ChuckO,

We are doing the same thing. I perform a RPC by passing a String of the name
and the parameters bundled in a Vector. The method is then invoked on the
servlet via reflection, and the results of my method are then passed back
(i.e. business classes), then using get/set to display them on text fields
(txtName.setText(Person.getName())).

=

"ChuckO" <ckj@longsol.com> wrote:
>
>I've been doing some fat client applet development connecting with JDBC
to
>Oracle for a while. Now, our clients are getting tired of downloading the
>large .jar files and having to update their .java.policy file every time
>we change the database location. So the question, is anybody using a rich
>GUI front end applet to call a servlet or EJB that is connecting to a database?
> We want our apps to look like a "traditional" client/server C++ application
>(ie using a JTable to display rows and GUI cell renderers, instead of an
>HTML table with just text), but I'm thinking with the Java security, we'll
>need to make the connection from the servlet or EJB to the db to avoid having
>to have each client update their .java.policy with that IP address. We're
>also going to move most of our business logic to the back end, but then
how
>can we reference all of the JTextFields on our content pane wihtout passing
>a huge name pair string to the doGet call? I'd rather pass the applet and
>use our xxxFld.getText calls, but is serializing and passing an entire applet
>across the lines going to be too much to deal with? Any suggestions would
>receive a warm welcome.