Components for a client/server architecture

[Diez B. Roggisch]

> - Java (and possibly Jython) or Mono/C# (or possibly IronPython) on the
>   server. Requirements are: A strong and fair threading model. This is
>   actually what drove me away from Perl and what essentially prevents
>   using a normal Python interpreter on the server. I don't know whether
>   the GIL and starvation issues also apply to IronPython or Jython.
>   Sharing non thread-aware objects of arbitrary type between threads
>   without any restriction is absolutely necessary (this is not possible
>   in Perl).

I'm not sure which configuration you want to change how often. But I'm not
convinced that the python threading limitations really do make a difference
here. Do you really benefit from multi-core capabilities in this scenario?
Because that's what you are asking here, and somehow I doubt that all of a
sudden the bazillion of single-core-servers that suited us so well are a
major PITA, together with all the apps running on them.
 
> - Perl or Python on the client side. Clients have to provide a UI (a
>   web application is not an option).
> 
> Unfortunately, I have very little experience with client/server
> architectures and the protocols involved, so I would like to collect your
> recommendations as a starting point for further research:
> 
> - Are there any standard protocols that make it easy to share objects
>   between Java/Jython/IronPython and Python or Perl over the network? I
>   am thinking of a portable, language independent object
>   (de-)serialization, if such a thing exists.
>   Having a defined protocol/interface between the client and the server
>   that makes it easy to switch technologies on either side of the
>   architecture is a strong requirement.
> 
> - How does bi-directional communication in such a protocol work? I am
>   assuming that the client should not poll the server for callbacks,
>   OTOH, leaving a TCP connection open also does not seem right.
> 
> - What is the security model of that protocol?
> 
> If my description of the project is inaccurate or too incomplete I
> apologize; the problem is that I still find it hard to tell which
> requirements actually matter.
> 
> If you have any pointers that might be of interest for such an
> architecture, please let me know.

Sounds like CORBA to me. CORBA has a very mature and good implementation for
Python called OmniORB, and interoperability with other orbs (the ones
available for e.g. Java) is very good - as CORBA as standard is mature.

Having call-backs and the like is also no issue in CORBA. However, it is
_not_ serialization of objects, just RPC - you expose an object living in
your server to clients. It's not transferred. And the other way round, you
can pass client-side object references to the server and call these.

I can't comment too much on the security aspects, but AFAIK at least SSL is
an option. And from what I know about SOAP it's certainly not better suited
(besides the fact that it sucks big time anyway)

HTH,

Diez