Re: [Opengrads-devel] Java client/server

[Arlindo da S. <da...@al...>]

Pedro,

   This looks like a great design. I like the fact that the GrADS Backend
Server (let's call it GBS) uses sockets, so in principle the front end could
be implemented in other languages, for example, python. This is good because
later on I could hook up PyGrADS to the GBS as well.  For performance
critical applications, at the expense of security, one might be able to
replace the NextVM portion with the actual GrADS C implementation with some
form of JNI glue. A quick question: would the server be able to handle
requests from multiple clients? This would be important if one wants to
provide GBS as a web service. Also, having the GBS and a thin client as you
propose would make it very feasible to have a cell phone implementation of
the client. I'd love to plan a route on Google Maps and have a Meteogram
plotted along the route.

  Would you have any time to help out with the Java implementation? I have
limited Java/socket programming experience. I suppose you could reuse some
of your previous Java code, correct?

  Thank you for the thoughtful response.

  Cheers!

     Arlindo


On Mon, Jan 19, 2009 at 12:22 PM, pedro tsai <ped...@ya...> wrote:

> Dear Arlindo,
>
> Here is my suggestion/approach regarding this issue about client-server and
> non-blocking behavior.
>
> For the purpose of discussion, I will use the term java-client process
> and c-code server process.  These 2 processes can be running on
> different machines or on the same machine.
>
> 1. For the Java client process, I think this process needs 2 execution
> contexts (e.g, 2 threads).
>
>    (a) thread 1 is a command processor, this corresponds to the part of
> code that use
>        JReadline to get the user input:
>
>     if ((cmd = reader.readLine("ga-> "))==null) break;
>             rc = ga.call("gaCmd",ga.strdup(cmd));
>
>         Now instead of calling GrADS runtime under NextedVM,  it will sends
> the
>         command to the C-code server process.
>
>     if ((cmd = reader.readLine("ga-> "))==null) break;
>             rc = Send_command_and_c_code_process("gaCmd",ga.strdup(cmd));
>
>     For now, we don't need the detail for 'Send_comand_to_c_code_process',
>         most likely it will be implemented on standard 'socket API' in
> Java,
>         using TCP or UDP connection.
>
>    (b) thread 2 is described later.
>
> 2. C-code server process :  this process consists of 'grads c-code'
> component
>    running under NextedVM and a wrapper layer, this is the 'GradsVM'
> wrapper
>    in your e-mail:
>
>    (a) In the GradsVM component, it performs 'socket' read function
>        get the command string from the Java client process, and it then
>        calls 'ga.call("gaCmd,ga.strdup(cmd))' to pass the command
>        to the 'grads c-code'.
>
>    (b) After the execution is done by 'grads c-code', the graphics
> primitives
>        commnads are returned to the GradsVM wrapper via the callback
> function
>        (this corrsponds to the Runtime.CallJavaCB() in the existing
>        JGrads.java code).  In this function, we will buffer the graphics
>        primitive commands,  for example,
>
>        In the Runtime.CallJavaCB(),  if we receive a GXDWID, instead of
>        calling g.gxdwid(a), we will add the GXDWID command and its
>        parameters to the buffer:
>
>           (......,
>           GXDWID+parameters,
>                   GXDMOV+parameters,
>           GXDDRW+parameters,
>           GXDFRM
>           )
>
>        When the graphics primitive 'GXDFRM' is encountered, then the
> content of
>        the buffer can be send back to the Java client process
>        (again, omitting the detail for network socket operation)
>
> 3.  In the Java client process, the second execution context (thread 2) is
>     the graphics primitives processing thread.
>
>     (a) In thread 2, it listen for graphics primitives requests from the
>         C-code server process.  When the requests arrive, it processes
>         the graphics primitive commands by calling gxJ() functions:
>
>     g.gxdwid, g.gxdmov, ..... gxdfrm.
>
> Attached files are drawing showing this program flow (If you can not open
> the vizio file, then just open jpeg file).
>
> best regards,
>
> Pedro
>
>
>
>
> --- On *Thu, 1/15/09, Arlindo da Silva <da...@al...>* wrote:
>
> From: Arlindo da Silva <da...@al...>
> Subject: Java client/server
> To: ped...@ya...
> Cc: ope...@li...
> Date: Thursday, January 15, 2009, 8:42 AM
>
>
> Dear Pedro,
>
> I have a question for you regarding a client/server split of GrADS, much
> along the lines of what youy did 10 years ago.  My main interest is to be
> able to run the core GrADS on the machine where the data resides and do the
> plotting locally on my laptop while sipping coffee at Starbucks. Of course
> OPeNDAP allow some of this functionality, but doing server-side operations
> in GDS is just a bit restricted.
>
> My current approach for *grads.jar* is  based on NestedVM and creates sort
> of a "single executable". Strictly speaking, it is not client-server.
> However, there is a very natural "fold" for a client/server split: most of
> the system is based on the C sources compiled into java byte code through
> NestedVM; I'll refer to this part of the system loosely as the "C code".
> There are only 2 files with actual java code:
>
>    1. *JGrads.java *which contains main(): the NestedVM class "*grads*" is
>    called several times: once for initialization and then in a while loop
>    (function *GaCmd*) so that I can use JLine (readline replacement).
>    2. *gxJ.java*: adaption of your original code. These gets called from
>    within the "C code" through a  callback setup that gets done in *
>    JGrads.java.*
>
> Therefore, one could say that the "*C code*" part of the system is the *
> server*, while *JGrads.java* is the *client*. This split is very different
> from what you have conceived originally because now most of the graphics is
> done server-side, only the final rendering using the gx primitives is done
> client-side. A good thing about it is that any improvements Brian makes to
> the plotting routines are readily available. The graphics primitives are
> much less likely to change, so it is much easier to maintain. On the down
> side, the server does most of  the work.
>
> Now, the thorny issue: how to handle the fact that the "C code" calls back
> java for the graphics primitives.  Although it is not setup this way right
> now, perhaps we could have some non-blocking way of calling *GaCmd *with
> subsequent queries to the server for the graphics primitives requests/end of
> command events. I was thinking about a *GradsVM.java* class that wraps
> around the "C code " and provides what is necessary for implementing this
> (for example, buffering the graphics primitives' requests.)
>
> How would you do it? I have close to zero experience in Java, there is
> probably more elegant ways of doing this.
>
>    Thanks,
>
>         Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>
>
>


-- 
Arlindo da Silva
da...@al...