Twisted Sevices

Twisted is one of the more mature Python networking libraries in existence. It has been around for over half a decade and has a very feature-rich code-base. There are several sever types that can be implemented with Twisted. This is actually a real requirement for many applications. For instance, an web application will obviously need an HTTP server for the web front-end. That same application may also want to provide a lower-level server for an API that generates less overhead. However, having to write something custom just to ensure that these servers are started along with the application seems a bit much. Especially if the servers are both a Twisted implementation. Luckily, Twisted has just the solution for this scenario.

Twisted provides developers with a MultiService class that is used to create multiple network service that behave logically as one server. Server implementations in Twisted can set the parent service to be an instance of MultiService. This MultiService instance can then be started with multiple child servers.

However, one last step should be taken. In order to make your service work with the twistd command, that is make it a sub-command, you must make the service properly. This is done by implementing a class that implements the IServiceMaker interface. This same class should also implement the IPlugin interface since it is a Twisted plugin in addition to a service.

The IServiceMaker interface requires attributes that dictate the name of the sub-command used with twistd. Also, command parameters and a description are part of the interface and should be provided.

This is a really nice way for an application to manage multiple services provided by the same application. It also goes to show that Twisted's experience is also reflected in the API.

Injecting Gaphor Services

The Gaphor UML modeling tool is more than just a simple diagram editor.  It is also a powerful application architecture, capable of being used outside of the UML context.  What makes it so powerful is that the elements that make up Gaphor are clearly separated into services, components, and adapters.  The Gaphor architecture is important in how it glues all these pieces together.

Gaphor is built on top of several services that support the application as a whole.  There are many required services that are distributed along with Gaphor.  For example, there is an element factory service which is responsible for creating and managing the various UML elements.  These services are then loaded during the Gaphor startup process by iterating through entry points and instantiating the service classes.  This, in fact, is how other Python packages would define Gaphor services.

These services also work the other way around;  existing services can be used by other Python applications instead of defining the service for Gaphor to use.  The services can be used by other applications by invoking the Gaphor injection mechanism.  There are a few precautions to take when using this mechanism and they are illustrated in the example below.

#Example; Gaphor service injection.

#Do the Gaphor imports.
from gaphor.core import Application, inject
from gaphor.UML import Class

#A class is required in order to store the injected service
#as a class attribute.
class Gaphor(object):
    
    #Inject the element factory service.
    element_factory = inject('element_factory')
    
    #Initialize the application which will,
    #in turn, initialize the services.
    def __init__(self):
        Application.init()

#Main
if __name__=="__main__":
    
    #This will not work.  It serves as an illustration as to
    #why a class attribute is necessary.
    try:
        print inject('element_factory').create(Class)
    except:
        pass
    
    #This will work.  First, create and initialize the
    #Gaphor application singleton.  Next, interact with
    #the element factory service.
    app=Gaphor()
    print app.element_factory.create(Class)