Long: Python Is Really Middleware
nigelc at datacom.co.nz
Tue Aug 7 05:58:05 CEST 2001
I've been thinking about this issue in a more or less independent
mode. A basic framework for building customised, transactional
middleware would be very helpful in using python as a glue language.
I'm thinking of something between a TP monitor and an integration
server like Crossworlds or BizTalk.
You'd need to build a backbone for the system that allows multiple
python interpreters in different threads or processors (to get around
the threading issues in the python interpreter). It would support
for transactional API's such as XA and (maybe) TX (?) [starting to
tickle the limits of my knowledge of the X/Open protocols here]
There is a range of middleware interfaces for distributed communication
systems here, ranging from cPickle and sockets to XML-RPC, CORBA, SOAP
etc. in various levels of maturity. I see something that integrates
or allows the use of existing communication libraries without trying
to depend on them (although the transactional hooks would allow systems
that implement CORBA transaction service or the like)
Does this make sense?
More information about the Python-list