Re: Components for a client/server architecture
- From: "Diez B. Roggisch" <deets@xxxxxxxxxxxxx>
- Date: Mon, 21 May 2007 12:06:50 +0200
- 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
.
- Follow-Ups:
- Re: Components for a client/server architecture
- From: Samuel
- Re: Components for a client/server architecture
- References:
- Components for a client/server architecture
- From: Samuel
- Components for a client/server architecture
- Prev by Date: Re: Inverse of id()?
- Next by Date: Re: TIFF to PDF
- Previous by thread: Components for a client/server architecture
- Next by thread: Re: Components for a client/server architecture
- Index(es):
Relevant Pages
|
