Architecture of Akara

Akara provides a pipeline-based services model, implemented for invocation using REST methods. Services are identified by ID (URI), and are made available at one or more mount points (URLs). Services are abstracted through the REST model so that, for example, if you make a request of an AKara instance, it might be that specific Akara instance that executes the service, or it might be acting as some form of intermediary to other capability, whether in the form of another Akara instance or a completely different technology.

This basic service abstraction system supports complicated service choreography, including round-robin, load-balancing, a race of parallel invocations (e.g. to satisfy emergency processing requests), or even through some sort of scoring system (i.e. I prefer Akara to FooTransformer for XSLT, if available). Improtantly, this flexibility comes without the excess baggage of many "SOA" service models.



Akara's default WSGI server is based on the Apache MPM prefork model. The description is similar to that for mod_wsgi under that Apache mode:




Note: a user can opt to use a different WSGI server with Akara modules.

Parts of the implementation are based on flup's

See also:


For ideas:

Use cases

For use-cases that help shape Akara's architecture see Akara/Use_cases.

What Akara is not

There were early considerations to make Akara more of a RESTful, general-purpose document repository (document-oriented database) vaguely along the lines of CouchDB or eXist. In the end we decided that the most important thing we could accomplish in Akara was simplicity and focus. There are numerous RESTful resource repositories, in Python and other languages. The decision was that it's more important to make sure that Akara can inter-operate well with these than to try reinventing that wheel. In this way we could focus on the core aspects of what made 4Suite so special: its ability to apply modeling to rationalize data services.

So Akara is not a repository, but can interact freely with the best RESTful repository projects, open source and otherwise.



Akara's origins are in the 4Suite project, but Akara's architecture is quite different from 4Suite Server's, taking advantage of 8 years of Web architecture developments. (see Akara/Architecture/BackwardsCompatibility for some considerations of functionality we plan to maintain or provide a migration path from 4Suite repository).


In fact, it will be designed to closely work with these and other RESTful systems such as NetKernel. It will be easy to use Akara in tandem with services hosted on these other services, and apply each to its greatest strength.

Older notes

Akara 2 will target Python 2.5 and 2.6. There will be an Akara 3.0 branch targeting the big changes in Python 3K.

Services manager

A very simple, RESTful system for discovering services available to apps. Best explained by example. Akara provides through the resource manager a Schematron validation service. It gives this class of service a URI: If you set up Akara wrapping an app at, then the default config provides an instance of this Schematron service at Akara's services manager allows you to discover this service location so your app can take advantage of it. You might use code such as:

   1 import amara
   2 from amara.lib import iri
   3 from akara import SCHEMATRON_SERVICE_CLASS
   5 def myapp(environ, start_response):
   6     xml_iri = ''
   7     schematron_iri = ''
   8     schematron_endpoint = environ[''].lookup(SCHEMATRON_SERVICE_CLASS).baseiri
   9     request = iri.resolve(schematron_endpoint, '?xml=%s&sch=%s'%(xml_iri, schematron_iri))
  10     response = amara.parse(iri.urlopen(request))
  11     #Here we can check the response from the service and do something cool with it
  12     #...

environ[''] returns the active Akara services manager instance. The basic lookup() method for just returns the first available matching service instance. Akara Enterprise has a more sophisticated lookup implementation that can offer fallback (i.e. use an alternate service if the main is down), load balancing and such. For now the only property or method defined on service instances is baseiri, which tells what IRI invokes the service. We might need to expand this for service description, for example to specify a Schematron of service response XML, but we'll address this later. There is some controversy over description languages for REST, but the Akara developers agree that something much more lightweight than WSDL or even WADL is a good idea. Schematron seems a perfect fit.

Note that services manager is decoupled from resource manager because it's possible that a service is not a managed resource of the local Akara installation. For example, you might decide to use a third-party Schematron service rather than the one you've installed with Akara.

See also

WSGI Middleware

An updated version of

from akara.transform import TransformMiddleware

You can specify where to look for needed template resources and such through resource manager (e.g. specifying a base file:/// URI for transforms, if policy manager allows).

You can also set a transform to be invoked on the WSGI response:

from akara.transform import set_transform

def wsgiapp(environ, start_response):
    # set the transform in the environ dict with the key 'amara.transform'
    set_transform(environ, 'index.xslt')
    xml = """<?xml version="1.0"?>\n<page><content>hello world</content></page>"""
    return [xml]

You can override the media type if you like:

from akara.transform import set_transform
    set_transform(environ, 'index.xslt', media_type='text/plain')

You can specify a list rather than an instance for the XSLT. Each item can be a string, stream, URI or file.

See also


Triggers are an event-driven system that allows one event in Akara to trigger another. Akara includes a lightweight framework for triggers (much like a tuple space) and specific services or resource implementations can use this for specific needs.

Examples of use:

Web triggers

Triggers are carefully exposed to Web protocol as Web triggers, where they are essentially RESTful trigger system.

XSLT extensions

Akara continues to provide a set of XSLT extensions for accessing the above services.

Transactions and concurrency

Because of the loosely coupled component architecture of Akara, transactions and concurrency are handled in a fairly distributed model, following XA two-phase commit conventions. Each service, including core services such as the resource repository and the indexers, act as transactional resources, and the service manager acts as a transaction manager, responsible for creating and managing global transactions across operations on these resources.

Notes on transactional properties:

full all-or-nothing outcomes per transaction
guaranteed across transactional boundary
ANSI/ISO read-committed by default
guaranteed upon second phase of commit
No checkpoints or sub-transactions by default



We'll start with an HTTP interface, but in the chance we want something lower-level & more efficient here are some thoughts about a specialized client/server interface. Note: one thing that might make this useful is the case where auth is needed but SSL is not practical for the user. Would be nice to have an interface with some sort of nonce scheme to bump up security a bit.

One strong candidate for minimal wheel reinvention is BEEP:

See also

Low level process foundation

We're evaluating standardized approach for low-level daemon set-up and network protocol bootstrapping, such as:

See also

Akara/Architecture (last edited 2010-03-02 20:25:31 by UcheOgbuji)