Python Web Server Gateway Interface, as specified in Python Enhancement Proposal 333, is a proposal for a "simple and universal interface between web servers and [python] web applications or frameworks".

Modjy is an implementation of a WSGI compliant gateway/server for jython, built on J2EE servlets.

A - What modjy is not

Modjy is not another python web framework! There are already enough frameworks for python, as can be seen on the Python web programming wiki. So much energy has gone into building those frameworks that there is little to be achieved by replicating that work. Instead, it is to be hoped that the authors of some of those frameworks will port their frameworks to WSGI, in which case they will be portable to every WSGI server, including modjy.

And that is where modjy comes in. Any python framework that is WSGI compliant should run under modjy without problems. Which means that it should be possible to run python frameworks under java!

Modjy is released the Apache License v2.0

The full text of the licence, including all terms and conditions, is included in the Download.

I wrote this software for a few reasons.

• Because I really like the idea of WSGI, particularly because it could be the solution to the fragmentation of the python web infrastructure market.
• Because there's no better way to familiarise oneself with a new standard than to build software that implements it (I do Quality Assurance work a lot in my day job).
• Because I use java a lot in my work, and have always looked enviously at the fantastic (but frequently non-portable) creativity of the cpython web community.
• Because I want to encourage more cross interaction between the cpython and jython worlds.
• Because I wanted a java platform on which to develop my own WSGI middleware components
• Because J2EE's servlet architecture is too rigid, in terms of session management, authorisation, etc. Even writing servlets in jython doesn't alleviate these problems.
• Because WSGI saved me from having to write python framework N+1 :-)
• Because I get a buzz out of enabling portability.

I hope that at least one or more of the reasons above makes sense to you!

Basically, the following were my main aims for modjy

1. To provide a jython platform for prototyping and developing WSGI applications and middleware, for my own use and for the python web community in general.
2. To provide myself a prototype implementation which I could use to track the evolution of the WSGI spec.
3. To develop a WSGI-compliant server with minimal complexity, so that highly reliable operation could be relatively easily assured.
4. To develop the thinnest possible layer between J2EE and WSGI, for maximum simplicity and efficiency.
5. To leave out of modjy all of the things that are best provided by a WSGI framework running on top of modjy, i.e. by portable middleware components. Such areas include uri mapping, session management, page templating, etc, etc. Indeed, portability of those very components between WSGI frameworks is the desired goal, so there's no point in me implementing them in modjy.

A - Architecture

The architecture of modjy is very simple, from a J2EE point of view. It consists of a single java servlet class, which is the thinnest possible wrapper around the required jython functionality. Since the java servlet is multithreaded, only one instance of it will ever run in a given container (unless configured otherwise). This java servlet also initializes the jython runtime, setting some necessary parameters beforehand.

The java servlet then creates a single instance of the modjy_servlet class, to which all incoming HTTP requests are delegated. The modjy_servlet instantiates an application object for each request, as described in How modjy locates application callable objects. It then creates WSGI environment and start_response_callable objects, and invokes the application.

More details on how to configure modjy to use single vs. multi threading, etc, see the Configuration reference.

B - Code structure

The principal jython class for implementation of modjy is the modjy_servlet class. This class uses mixins to factor out code by functionality, so that the structure can be more easily evolved, components replaced, etc. For example, the modjy_servlet inherits from the mixin modjy_impl.modjy_impl21, which takes care of all jython 2.1 related implementation.

As it happens, the jython 2.1 implementation works seamlessly with jython 2.2, a tribute to the stability and clean design of jython. So you should be able to migrate your WSGI applications to jython 2.2 without difficulty.

The code should be fairly easy to understand, and not hugely J2EE specific. When it has settled down as a model, I am sure that it would port reasonably well to other platforms where python might be embedded in a native multithreaded server: for example IronPython. If anyone is looking for an interesting project with which to try their hand at IronPython and .net :-)

As you have probably gathered from the goals above, I didn't see any point in having a complex uri mapping scheme built into modjy itself. Instead, it is much easier to write a good uri mapping algorithm in python, and layered on top of modjy. Also, once such a uri mapping component has been written to be compliant with WSGI, it can then become a portable component, which would work on all other WSGI compliant servers, cpython, jython and ironpython included. (I like this portability stuff :-)

Also, getting to know how a new web application or framework manages its URL space can be one of the most difficult things to discover/understand about it. So rather than confuse modjy users and make them learn yet another way to map uris to objects, I thought I'd build the simplest possible mechanism, and let the user supply their own mapping algorithm, in their favourite language :-) In fact, I'd go so far as to say that the user really *must* supply their own uri to object mapping algorithm with modjy, because the existing one just isn't useful for anything complex.