Applet client calling servlet/EJB database backend


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: Applet client calling servlet/EJB database backend

  1. #1
    ChuckO Guest

    Applet client calling servlet/EJB database backend


    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.

  2. #2
    mark Guest

    Re: Applet client calling servlet/EJB database backend


    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.



  3. #3
    ChuckO Guest

    Re: Applet client calling servlet/EJB database backend


    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.

    >



  4. #4
    mark Guest

    Re: Applet client calling servlet/EJB database backend


    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.

    >>

    >



  5. #5
    ChuckO Guest

    Re: Applet client calling servlet/EJB database backend


    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.
    >>>

    >>

    >



  6. #6
    mark Guest

    Re: Applet client calling servlet/EJB database backend


    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.
    >>>>
    >>>

    >>

    >



  7. #7
    tom Guest

    Re: Applet client calling servlet/EJB database backend


    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


  8. #8
    mdsteenb Guest

    Re: Applet client calling servlet/EJB database backend


    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.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center