API service/worker architecture for async operation

This blueprint discusses a few possible options for the API service workflow and architecture.

The objective is to design the API worker architecture so that it is extensible,
can scale independently and can be deployed independently. The idea is to quickly have an implementation which can support a wide variety of use cases.

Proposed architecture:
-----------------------------

The API service should be capable of abstracting the interface with various clients. In essence provide a view to the client. The control layer (controller class in solum) can be used for that. Authentication would happen here. Request validations, transformations, etc would happen here too. The controller passes on requests to the dispatcher.

The Dispatch layer will encapsulate the routing mechanism required to get the request to the right handler for fulfillment. This could be with a direct call to a known method in the handler class (first version), or by placing a message on a queue which the handler can read (for scaling, and handling requests asynchronously). RabbitMQ or Oslo Messaging [1], can be used for queuing messages.

Handlers are responsible for fulfilling the request.

1) | Controller |------->| Dispatcher |-------->| Handler |-------> Database

2) | Controller |------->| Dispatcher |-------->| queue |--------->| Handler |------> Database

Comments:
---------------

- To start things off, we can implement workflow #1 shown above and make all requests synchronous.

[1] https://wiki.openstack.org/wiki/Oslo/Messaging. I think Oslo messaging is used in other openStack projects.