This discussion is archived
4 Replies Latest reply: Mar 15, 2011 11:47 PM by mauric RSS

A general question on client-server communication

mauric Newbie
Currently Being Moderated
Good morning to all forums' users,

I'd like to know your opinion regarding protocols to be used to communicate from a desktop client,
I mean a java client (no matter of other languages: let's focuse ourselves on Java client only)
with a remote J2EE server.

As far as I known and I've read on forums, books, articles and so on, we've basically these approaches
to solve client-server communications:

- Web Services (SOAP, JAX-RPC, RESTful and so on)
- RMI (direct RMI, RMI over HTTP etc)
- Http request/response based protocols (see, for example, Spring HttpInvoker).

In each approach, basically these steps are done:
a) information, generally Java Beans (Value Objects), are marshalled in some form (binary form, xml etc) on the client side;
b) information is sent from the client to the server over the wire;
c) information is deserialized at server side;
d) information is used for some kind of elaboration on server-side;
e) server-side calculations generate some kind of result
f) results are sent back to the client, following the same steps form a) to c), with "client" instead of "server".

I'd like to have some advices about optimizing each step. A crucial question I have is, for example, if it
is always better use a facade approach to reduce network latency. For example, let's suppose that we must preload some
data from server side. We may choose:

- preload all data in a single request: serialized data may require 100KB of data sent over the wire;
- preload data in single steps: serialized data for a single request are smaller (for example, 10 KB for each request,
on a total of 10 requests).

How serialization/deserialization steps would impact on processing time ? I.E, it's better to serialized/deserialized a few
data, multiple times, or a bigger amount of data in a single step ? On the other hand, it's better to send more request
with smaller payload over the net, or a bigger one ?

What would you suggest me to do ?
  • 1. Re: A general question on client-server communication
    jtahlborn Expert
    Currently Being Moderated
    mauric wrote:
    As far as I known and I've read on forums, books, articles and so on, we've basically these approaches
    to solve client-server communications:

    - Web Services (SOAP, JAX-RPC, RESTful and so on)
    - RMI (direct RMI, RMI over HTTP etc)
    - Http request/response based protocols (see, for example, Spring HttpInvoker).
    the last one seems to be a bit of a repeat (httpinvoker is basically "rmi over http", all the webservices are "http req/resp" based).
    I'd like to have some advices about optimizing each step. A crucial question I have is, for example, if it
    is always better use a facade approach to reduce network latency. For example, let's suppose that we must preload some
    data from server side. We may choose:
    the first and best answer is that you can't really optimize until you implement something specific, because different scenarios have different needs. the essential question is: are you spending most of your time sending data or processing the data on the server. if the former, you should optimize the transport layer. if the latter, you should probably optimize your server side processing and not worry about the transport layer.
    - preload all data in a single request: serialized data may require 100KB of data sent over the wire;
    - preload data in single steps: serialized data for a single request are smaller (for example, 10 KB for each request,
    on a total of 10 requests).
    my previous comment aside, there are usually a few broad generalizations you can apply with remote communication. it pretty much breaks your nice OO abstraction layer, and you almost always want to reduce your round trips and the amount of data you send. which means: fewer requests and as little data as possible (e.g. "preload all data in a single request" if possible).
    How serialization/deserialization steps would impact on processing time ? I.E, it's better to serialized/deserialized a few
    data, multiple times, or a bigger amount of data in a single step ? On the other hand, it's better to send more request
    with smaller payload over the net, or a bigger one ?
    again, the answer to this is "it depends". you pretty much need to start putting code together before you can really know the answer to these questions. in theory, xml serialization (aka SOAP) is bloated and slow. in practice, it doesn't usually matter unless you are making many, many small requests that need to be really fast.

    i would say that the best way to start designing something like this is:

    - pick the best technologies based on all the usage criteria you currently have (e.g. if you need to support non-java clients, you should probably lean towards webservices)
    - keep your business logic as abstracted from your transport layer as possible
    - implement some key pieces of the system
    - test it, profile it
    - finally: possibly change/optimize the transport layer if the previous step shows that to be the bottleneck (and if you abstracted the system well, that shouldn't be too hard)
  • 2. Re: A general question on client-server communication
    mauric Newbie
    Currently Being Moderated
    Hi Jtahlborn,

    thank you for your reply.
    the first and best answer is that you can't really optimize until you implement something specific, because different scenarios have different needs. the essential >question is: are you spending most of your time sending data or processing the data on the server. if the former, you should optimize the transport layer. if the >latter, you should probably optimize your server side processing and not worry about the transport layer.
    I'm thinking of an ERP, so, generally speaking, of a distributed system which is asbolutely data-centric, in which transactions are not limited to a few data, but may be very complex.
    there are usually a few broad generalizations you can apply with remote communication. it pretty much breaks your nice OO abstraction layer, and you almost >always want to reduce your round trips and the amount of data you send. which means: fewer requests and as little data as possible (e.g. "preload all data in a >single request" if possible).
    [...]
    again, the answer to this is "it depends". you pretty much need to start putting code together before you can really know the answer to these questions. in >theory, xml serialization (aka SOAP) is bloated and slow. in practice, it doesn't usually matter unless you are making many, many small requests that need to be >really fast.
    Ok, that's absolutly reasonable concept... anyway, let's think the problem under another form. Client server communication is an exchange of information over the net, an exchange made in two macro-steps: serialization of data and data transport. If I'm working in a LAN enviroment, or via an internet connections, data processing on server-side is the same, and clearly processing time does not depend on the transport layer.
    So, let's suppose we need to serialize for a transaction an amount D of data. From a pure networking point of view, I can only:
    - transmit all data in a single request,
    - split the data in multiple request.
    If there is no way to transmit such data in an efficient way, a logical consequence is that there are situations in which a client (both web and desktop client) server model can't be applied... or am I wrong ?

    I would really appreciate your reply.... thanks !

    Edited by: mauric on 12-mar-2011 12.37
  • 3. Re: A general question on client-server communication
    jtahlborn Expert
    Currently Being Moderated
    mauric wrote:
    Ok, that's absolutly reasonable concept... anyway, let's think the problem under another form. Client server communication is an exchange of information over the net, an exchange made in two macro-steps: serialization of data and data transport. If I'm working in a LAN enviroment, or via an internet connections, data processing on server-side is the same, and clearly processing time does not depend on the transport layer.
    So, let's suppose we need to serialize for a transaction an amount D of data. From a pure networking point of view, I can only:
    - transmit all data in a single request,
    - split the data in multiple request.
    If there is no way to transmit such data in an efficient way, a logical consequence is that there are situations in which a client (both web and desktop client) server model can't be applied... or am I wrong ?
    if understand what you are saying: if the client must have access to the data but you cannot get the data to the client, then yes, you are pretty much stuck. however, presumably, you are ultimately displaying some information to a user, who can only consume a certain amount of information at a time. therefore, pretty much any information you need to display to a user should be transmittable across the network (e.g. i can use vnc/remotedesktop to look at any client program running on my computer). in other words, you can usually do more work on the server side to condense the information such that you can efficiently transmit the information required to generate the relevant display on the client side. an example of this might be something like doing a google search, which may involve working with a large amount of data on the backend, but ultimately only ends up returning 50 links and associated snippets to me on the frontend.
  • 4. Re: A general question on client-server communication
    mauric Newbie
    Currently Being Moderated
    Thank you so much, jtahlborn .

    I will try and investigate in both direction:
    - efficient serialization of information to be transmitted over the net;
    - reducing payload-per-transaction at each client request.

    Thanks again !

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points