It is great for developing standalone network services and/or packs of services constituting middleware glue layer. Its flexibility comes particularly useful when integrating highly heterogenous networks of existing systems present in an enterprise.

Integration is difficult, because none of the 3rd party systems deployed in the enterprise are really interested in integration with any other.

Integration capabilities of various systems are very limited. They support different protocols and offer proprietary APIs. Even when a standard protocol compliance is declared, the implementation is often incomplete or broken.

You cannot modify 3rd party systems by yourself. Pushing the vendor to make modifications is often impossible or at least lengthy or expensive.

At the same time, a vendor can modify his system at his own convenience at any time.

Once integrated, the value of the systems increases, the integration middleware becomes more and more important over time, the business is depending on it and its failures are very undesirable.

What, you may ask, is so good about Pythomnic ? Why should you consider it over your current framework/platform ? What can it do for you ?

Unzip the package, start up an empty service in seconds and it goes live. From there you just keep building it online. Add a module, a method, reconfigure, edit your code and save it, it's there. No need to restart the service, Pythomnic reloads the updated modules automatically and transparently.

Pythomnic supports various network protocols for accepting client requests, synchronous (HTTP, XMLRPC, SOAP), asynchronous (JMS, SMPP, POP3, ICQ) or special (file swapping). Which you pick in any particular case depends on what your systems to integrate support. The best part of it is that your application code processes requests in a uniform way, with no attention to the original protocol. It is therefore easy to switch from one protocol to another or even accept logically identical requests arriving simultaneously over different protocols.

It's easy to split your service-based Pythomnic application into separate processes, likely to run on separate machines. One obvious reason for such modularization is that the integration middleware application will get scattered all over the network, following the layout of the systems it integrates. Modularization is also done for redundancy (and hence fault-tolerance) when the application parts that do some actual processing are run in multiple identical copies. Different parts of Pythomnic application can communicate over synchronous RPC calls or asynchronous P2P messages.