Our team has been dealing with storage and storage standards
for quite a while and took on the Cortex challenge. Could we actually develop,
manage and monitor a Xiotech ISE using a proprietary API and do it quickly? The
challenge was incorporating Xiotech’s cortex REST implementation within our
systems management application, StorageIM. Could we perform this development
with efficiency, a rapid application development paradigm? How would Cortex perform?
For the books, I’m a advocate in storage standards. I’m also
an advocate for vendors thinking outside the box and that is exactly what Cortex
is about. Cortex, Xiotech’s ‘Embedded’ RESTful storage API for their
Intelligent Storage Elements.
For starters Xiotech chose a RESTful web service that has
implemented XML as its current mime type and utilizes HTTP methods for
monitoring, provisioning and indications. The URI’s implemented for capturing
information about the ISE are similar to the SMI-S view concept. As an example, the cortex ‘query’ URI call
(localhost/query) looks familiar to the SMI-S Multiple Computer System Profile.
The difference is you don’t have to create any association traversals.
Cortex also has a set of XSD’s that we used to dynamically
create our client object model. These definitions made it a snap to create a
normalized DB schema that performs and scales nicely for trending and
All of the above being said I also never touched the ISE
element manager during development. I provisioned everything through
simple http URI posts and would check to ensure endpoints were created, volumes
were created through simple http URI gets.
During and after implementing our initial ISE aggregated monitoring
solution a question kept creeping up, why are storage standards so
complex? Xiotech has completely removed