Chapter 7. Scaling your Application Across Nodes with Spring Python's Remoting

With the explosion of the Internet into e-commerce in recent years, companies are under pressure to support lots of simultaneous customers. With users wanting richer interfaces that perform more business functions, this constantly leads to a need for more computing power than ever before, regardless of being web-based or thick-client. Seeing the slowdown of growth in total CPU horsepower, people are looking to multi-core CPUs, 64-bit chips, or at adding more servers to their enterprise in order to meet their growing needs.

Developers face the challenge of designing applications in the simple environment of a desktop scaled back for cost savings. Then they must be able to deploy into multi-core, multi-server environments in order to meet their companies business demands.

Different technologies have been developed in order to support this. Different protocols have been drafted to help communicate between nodes. The debate rages on as to whether talking across the network should be visible in the API or abstracted away. Different technologies to support remotely connecting client process with server processes is under constant development.

Spring Python offers a clean cut way to take simple applications and split them up between multiple machines using remoting techniques that can be seamlessly injected without causing code rewrite headaches. Spring Python makes it easy to utilize existing technologies, while also being prepared to support ones not yet designed.

In this chapter we will learn how:

  • Pyro provides a nice Python-to-Python remoting capability to easily create client-server applications
  • Spring Python seamlessly integrates with Pyro so that your application doesn't have to learn the API
  • You can convert a simple application into a distributed one, all on the same machine
  • It takes little effort to rewire an application by splitting it up into parts, plugging in a round-robin queue manager, and running multiple copies of the server with no impact to our business logic

Introduction to Pyro (Python Remote Objects)

Pyro is an open source project (http://pyro.sourceforge.net) that provides an object oriented form of RPC. As stated on the project's site, it resembles Java's Remote Method Invocation (RMI). It is less similar to CORBA (http://ww.corba.org), a technology-neutral wire protocol used to link multiple processes together, because it doesn't require an interface definition language, nor is oriented towards linking different languages together. Pyro supports Python-to-Python communications. Thanks to the power of Jython, it is easy to link Java-to-Python, and vice versa.

Note

Python Remote Objects is not to be confused with the Python Robotics open source project (also named Pyro).

Pyro is very easy to use out of the box with existing Python applications. The ability to publish services isn't hard to add to existing applications. Pyro uses its own protocol for RPC communication.

Fundamentally, a Pyro-based application involves launching a Pyro daemon thread and then registering your server component with this thread. From that point on, the thread along with your server code is in stand-by mode, waiting to process client calls. The next step involves creating a Pyro client proxy that is configured to find the daemon thread, and then forward client calls to the server. From a high level perspective, this is similar to what Java RMI and CORBA offer. However, thanks to the dynamic nature of Python, the configuration steps are much easier, and there are no requirements to extend any classes or implement any interfaces.

As simple as it is to use Pyro, there is still the requirement to write some minimal code to instantiate your objects and then register them. You must also code up the clients, making them aware of Pyro as well. Since the intent of this chapter is to dive into using Spring Python, we will skip writing a pure Pyro application. Instead, let's see how to use Spring Python's out-of-the-box Pyro-based components, eliminating the need to write any Pyro glue code. This lets us delegate everything to our IoC container so that it can do all the integration steps by itself. This reduces the cost of making our application distributed to zero.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.21.46.78