Components for a client/server architecture

[Samuel]

Hi,

I am looking for some recommendations for client/server technologies and
for the communication involved.

I am currently planning to port a Perl application that has grown out of
proportion to another language and architecture. For this purpose, I am
investigating technologies that best fit the requirements.

The current plan for the architecture of the ported software includes:

- A client/server model, where the server provides a service for
configuring network devices and the client provides a user interface
that runs on Unix.

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

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

-Samuel

 

[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

 

[Samuel]

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?

The threading issues are not bound to multi cpu systems. The problem is
that some of Python's blocking functions require holding the global lock.

"Not all built-in functions that may block waiting for I/O allow other
threads to run."
"It is not possible to interrupt the acquire() method on a lock"
http://docs.python.org/lib/module-thread.html

I also found that IronPython does not have a global lock, so far it seems
well suited for solving the problems I am trying to avoid. I am still
looking for a good comparison between IronPython, Python, and Jython.

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.

I have worked with Bonobo (an implementation of CORBA) before, though not
on the network - it is fairly complex. But I did not think of using it
for this purpose, it might actually make sense. I'll have to look into
the transport protocol more.

And from what I know about SOAP it's certainly not better
suited (besides the fact that it sucks big time anyway)

SOAP seems well suited for web services. But it comes with quite some
overhead, I tend to say that it's not a perfect fit for our purpose.

Thank you for your comment!

-Samuel

 

[Josiah Carlson]

The threading issues are not bound to multi cpu systems. The problem is
that some of Python's blocking functions require holding the global lock.

"Not all built-in functions that may block waiting for I/O allow other
threads to run."
"It is not possible to interrupt the acquire() method on a lock"
http://docs.python.org/lib/module-thread.html

You really should read the source.

static PyObject *
lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
{
int i = 1;

if (!PyArg_ParseTuple(args, "|i:acquire", &i))
return NULL;

Py_BEGIN_ALLOW_THREADS
i = PyThread_acquire_lock(self->lock_lock, i);
Py_END_ALLOW_THREADS

return PyBool_FromLong((long)i);
}

That snippet of code shows that acquiring a lock does release the GIL.
Whether or not you are able to interrupt the underlying operating system
lock acquisition is platform dependent (on *nix, you can signal anything
to die). Now, whether or not some other code does or does not release
the GIL depends on its implementation. However, having used threads on
Windows and Linux, with files, sockets, databases, etc., I haven't ever
experienced a case where the threads did something that wasn't
reasonable except in once case*.

I also found that IronPython does not have a global lock, so far it seems
well suited for solving the problems I am trying to avoid. I am still
looking for a good comparison between IronPython, Python, and Jython.

From what I've been reading over the last couple years, IronPython is
relatively competitive with Python, being faster or slower depending on
the things you are doing. Jython is syntactically limited to Python 2.2
at present, so if you want decorators, descriptors, etc., you are out of
luck.

I have worked with Bonobo (an implementation of CORBA) before, though not
on the network - it is fairly complex. But I did not think of using it
for this purpose, it might actually make sense. I'll have to look into
the transport protocol more.

You should also consider XML-RPC. Setting up and using XML-RPC in
Python is quite easy (see the recipes in the Python cookbook), both as a
server and client. If you are thinking about running the server in
Jython or IronPython anyways, you can always use the standard library
XML-RPC libraries from Python, aside from the sockets stuff, it's all in
Python.


- Josiah

* That one case was with mixing a 3rd party library that seemed to
have an incomplete Python wrapping that caused values from two thread
stacks to be exchanged. The only way I was able to tickle it was with
older versions of wxPython + wx.FileConfig + Scintilla + Python's
compiler module.

 

[Duncan Grisby]

[...]

I have worked with Bonobo (an implementation of CORBA) before, though not
on the network - it is fairly complex. But I did not think of using it
for this purpose, it might actually make sense. I'll have to look into
the transport protocol more.

To be clear, Bonobo is not an implementation of CORBA. It is a
(somewhat byzantine) implementation of a component model on top of
CORBA.

CORBA certainly has some complex corners, but for many of the most
common application requirements it is pretty simple, and buys you a
lot in terms of cross-platform compatibility and clarity of
interfaces.

Cheers,

Duncan.

 

[Samuel]

That snippet of code shows that acquiring a lock does release the GIL.

Of course, that does not mean that the (possible) issues no longer
apply. However, I decided to hack up a quick prototype and see how it
goes. If it doesn't work it shouldn't be too hard to switch to
IronPython.

You should also consider XML-RPC. Setting up and using XML-RPC in
Python is quite easy (see the recipes in the Python cookbook), both as a
server and client.

It's nice and simple, but more in the SOAP domain of things. As for
CORBA, I had a closer look at Omniorb and it looks powerful, pretty
much exactly what I was looking for.

Thanks!
-Samuel

 

[John Nagle]

[...]

You don't hear much about CORBA any more. It used to be derided
as a bulky way to marshall data, but then came XML.

Gnome and OpenOffice both use CORBA internally. But they don't
talk to each other that way; the implementations aren't compatible.

John Nagle

 

[Irmen de Jong]

You don't hear much about CORBA any more. It used to be derided
as a bulky way to marshall data, but then came XML.

CORBA is much more than just a way to marshall data.
GIOP (or its more often used implementation IIOP) is the marshaling
protocolused in CORBA. And it is hardly bulky!
Being a binary protocol, it is much faster and leaner than XML.

--Irmen