Storage as a Service Extension Overview

In previous articles we have looked at what an API extension is and how they work internally in context of Storage as a Service.  Let's look at the implementation of an API extension from a business logic standpoint that delivers our STaaS service using vCloud Director API extensions. 

Storage Extension Process


If we look at the 7 steps in our overall API process, steps 1,2,6 and 7 have been covered in the previous articles.  Steps 3, 4 and 5 have been implemented as a Java process that subscribes to our AMQP queue in order to receive API requests, and process them.  The Java process starts a new thread for each extension service registered with the extension server that processes the incoming API messages.

The AMQP Server object, which is the thread that will process the API messages subscribes to the AMQP queue that is registered with the service extension, as it was defined in the service extension XML definition.  (See introduction to API extensions for details).  The AMQP server thread takes the AMQP message and deserializes the message body into 3 objects, using the Jackson JSON libraries.  The deserialization results in 3 objects, HttpMessage, SecurityContext, and Context.  These 3 objects are then submitted to the HttpExtensionService object for processing.  The HttpExtensionService class is the class which our API extension business logic needs to implement.  In this example, our HttpExtensionService has been implemented as a class called StorageService.  StorageService receives the 3 objects from AmqpServer and then processes the API request, implementing the business logic.

StorageService has generic methods for interfacing with the underlying storage subsystem.  StorageService takes the HttpMessage and consumes the POST message body which is an XML doc with the storage request parameters.  These are the details of the storage request, such as storage size, IQNs to map to the new Lun and storage state (online, offline).  StorageService processes the XML and then calls the vendor specific implementation of how to complete the tasks of the generic methods.

In this example we have a class called OntapController, which takes the reqest to create/destroy/online/offline storage from the StorageService object and actually carries it out on the NetApp 3240 we used for this example.  StorageService then returns an HttpReply object back to the AmqpServer with the results of the provisioning task, which are then serialized into JSON and sent to the reply exchange for consumption by the vCloud Director cell.

I'll post the source code for this example with usage instructions in a follow up post.


Add comment

Security code

Joomla templates by a4joomla