CompatibleOne Develop

Software developed by CompatibleOne is gradually made available on the OW2 Gitorious repository.

The lattest version of CompatibleOne can be found here.

CompatibleOne Technical Documentation

• CORDS : CompatibleOne Resource Description Schema
  Introduction
  This document describes CORDS the CompatibleOne Request Description Schema, an application of XML. The schema describing the namespace of CORDS can be found at http://www.compatibleone.fr/schemes/cords.xsd">http://www.compatibleone.fr/schemes/cords.xsd and should be used to validate documents prior to their submission for processing.
  Overview of CORDS
  This table gives a synthetic view of the relationships between the different OCCI categories involved. Remark: The cardinality of the relationships between categories is NOT shown in this diagram. CORDS PARSER MANIFEST SECURITY ACCOUNT USER NODE INFRASTRUCTURE COMPUTE STORAGE NETWORK IMAGE SYSTEM PACKAGE CONFIGURATION ACTION CORDS BROKER PLAN SERVICE CONTRACT CONFIGURATION PROVIDER INSTRUCTION TARIFICATION
  Example Cords Request : POC XWIKI
  <?xml version="1.0" encoding="UTF8"?> <manifest name="POCXWIKI" xmlns="http://www.compatibleone.fr/schemes/cords.xsd"> <node name="xwiki1" provider="any"> <infrastructure name="quadcore"/> <image name="xwiki"/> </node> <node name="sqldatabase" provider="openstack" > <infrastructure name="dualcore"/> <image name="mysql"/> </node> <node name="xwiki2" provider="openstack"> <infrastructure name="quadcore"/> <image name="xwiki"/> </node> <configuration name="pocxwiki"> <action name="connectxwiki1" type="cordscript" expression="xwiki1.configure(sql1.href);"/> <action name="connectxwiki2" type="cordscript" expression="xwiki1.configure(sql1.href);"/> </configuration> <account name="compatibleOnePocXwiki"> <user name="jamie"/> <user name="fabio"/> <user name="stephane"/> <user name="xavier"/> <user name="olivier"/> <user name="houssem"/> </account> <security name="public" level="public"/> </manifest>
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/">licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  Resource Description Schema (CORDS Reference Manual v0.8)

• CORDS-PARSER : CompatibleOne CORDS Parser
  Introduction
  This document describes the public functional interface and operations of the CompatibleOne CORDS Request Parser. This tool performs the conversion and resolution of CompatibleOne Provisioning Requests. Requests are described using CORDS ( CompatibleOne Resource Description Schema ). This is an application of XML and the namespace is described by the schema that can be found at http://www.compatibleone.fr/schemes/cords.xsd">http://www.compatibleone.fr/schemes/cords.xsd and should be used to validate documents prior to their submission for processing.
  Operation
  The Cords Manifest to Plan parsing algorithm is the primary operational work horse of ACCORDS and processing will involve a three phase operation. XML Parsing and General Syntax Check The initial phase involves the parsing of the Cords XML input document to produce a Cords Manifest graph. Syntactical and semantic errors encountered during this phase will result in the "manifest" simply being rejected. CORDS Element Resolution The second phase of processing will examine this graph in detail with a top down approach. At each level of the graph, the element identifier will be expected to be a valid Cords OCCI Category identifier. Each element in term will be processed using the Service Publication Service to locate a Service Provider for the particular Cords OCCI Category. In the simple case, where an "id" attribute representing an instance identifier is present in the attribute list of the element, it will be used in an attempt to retrieve the corresponding Cords OCCI Instance and if successful the information that it provides will be integrated into the attribute list of the element under consideration. In the absence of an instance identifier, or in the case of failure to retrieve the named Cords OCCI Instance, the different attribute values of the element under consideration will be used in turn to localize Cords OCCI Instances that correspond. The "name" attribute will in all cases be used first when present. This operation may result in a list of alternative instances which will be grouped into a "choice" element for reporting back to the "manifest" initiator for resolution. Successful selection of a Cords OCCI instance in this way will result in integration of its details and instance identifier as for the primary case of localization by the primary instance identifier. Failure to locate an instance through the attribute list selection procedure will result in a new instance being created using the different parameters provided by the attributes of the element under consideration and the resulting instance identifier will be affected to the element. CORDS Element Linkage During the final phase of the Cords Manifest processing particular and predetermined relationships are imposed upon the collection of OCCI categories composing this "manifest" graph. These relationships describe the semantics of the "manifest" and the following requirements ensue: The outermost element of the graph MUST be a Cords Manifest element. This Cords Manifest element MAY provide an ID or NAME attribute referring to a pre-existing Cords Manifest that is to be reprocessed for completion using the information provided by the current "manifest". The Cords Manifest SHOULD describe, at least ONE provisioning element in the form of a Cords Node element. The Cords Manifest MAY describe subsequent provisioning elements in the form of Cords Node elements. Each Cords Node MUST satisfy one of the following conditions: describe exactly ONE Cords Infrastructure element and ONE Cords Image element, provide a TYPE attribute defining the name of the manifest describing the complex nature of the node, provide an instance identifier ID or name attribute that references a Cords Node fulfilling either of the preceeding validity requirements. The Cords Manifest MUST reference exactly ONE Cords Configuration element. The Cords Configuration MAY reference multiple Cords Action elements describing the operations to be performed to configure the nodes comprising the provisioning "manifest". The Cords Manifest MAY reference exactly ONE Cords Account element. The Cords Account MAY reference multiple Cords User elements describing the users and their access rights to be granted for use of the resulting provisioned infrastructure. The Cords Manifest MAY reference exactly ONE Cords Security element providing details pertaining to the nature and degree of security to be imposed upon provisioned instances of the overall infrastructure described by the "manifest". During the parsing operation any error conditions encountered will be reported by appending an error element as first child element of the offending element.
  Example Trace of Cords Parsing Operation
  The following listing of OCCI category resolution operations was produced by processing the XWIKI Proof Of Concept Request File using the Cords Parser. The file was processed in accordance with algorithm described in the document CompatibleOne Service Architecture and generates a fully qualified provisioning plan on successful completion. The category instances required to represent the component parts of the plan are instanced accross the corresponding collection of OCCI service providers of the ACCORDS platform. An XML representation of the fully qualified provisioning plan is produced by this tool allowing inspection of the results. ./co-parser pocxwiki CORDS PARSER OPERATION START CORDS Request Parser Phase 1 CORDS Request Parser Phase 2 OCCI Resolver( request, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/5d3b6527-97db-4945-a357-36c2779e9bb9 HTTP/1.1 Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /manifest/ HTTP/1.1 OCCI Resolver( node, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/fe6ebbd3-c7f6-482f-8bee-3c352733e55e HTTP/1.1 Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /node/ HTTP/1.1 OCCI Resolver( infrastructure, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/402d4f9e-5585-4b8d-8173-c52010eee988 HTTP/1.1 Rest Client Request : GET /infrastructure/ HTTP/1.1 OCCI Resolver( image, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/77c18918-45e0-432d-8378-46d2fb5cd6b4 HTTP/1.1 Rest Client Request : GET /image/ HTTP/1.1 Rest Client Request : PUT /node/0911ba36-a8eb-49f3-8c93-7df52b434fd6 HTTP/1.1 OCCI Resolver( node, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /node/ HTTP/1.1 OCCI Resolver( infrastructure, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /infrastructure/ HTTP/1.1 OCCI Resolver( image, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /image/ HTTP/1.1 Rest Client Request : PUT /node/b09429e4-48b0-4f93-afb6-50775f619396 HTTP/1.1 OCCI Resolver( node, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /node/ HTTP/1.1 OCCI Resolver( infrastructure, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /infrastructure/ HTTP/1.1 OCCI Resolver( image, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /image/ HTTP/1.1 Rest Client Request : PUT /node/5e804ff1-4d55-4585-a45d-3ba072200335 HTTP/1.1 OCCI Resolver( configuration, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/89702876-bab6-4a11-a5c1-362177dcb1dc HTTP/1.1 Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /configuration/ HTTP/1.1 OCCI Resolver( action, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/81b23551-743e-466d-8981-54e400419740 HTTP/1.1 Rest Client Request : GET /action/ HTTP/1.1 OCCI Resolver( action, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /action/ HTTP/1.1 Rest Client Request : DELETE /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : PUT /configuration/016e69ca-217c-4cb6-a603-bea49d835e80 HTTP/1.1 OCCI Resolver( account, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/b6a1ea27-52cc-4922-aa83-03c9a54e0c9f HTTP/1.1 Rest Client Request : GET /publication/1a2822e7-522c-4709-9859-3b842c8388dc HTTP/1.1 Rest Client Request : GET /account/ HTTP/1.1 OCCI Resolver( account, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : POST /account/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/cea1d495-64a4-4d2c-8278-63086f5003b6 HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 OCCI Resolver( user, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /user/ HTTP/1.1 Rest Client Request : DELETE /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : PUT /account/cacf6a8e-0198-418b-af5b-0f98bba62884 HTTP/1.1 OCCI Resolver( security, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/b17b8569-b17b-4171-baa3-33be72599103 HTTP/1.1 Rest Client Request : GET /security/ HTTP/1.1 Rest Client Request : DELETE /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 OCCI Resolver( plan, CO-RDS-PARSER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/90587041-8e17-4c7f-a585-e302dbc23088 HTTP/1.1 Rest Client Request : POST /plan/ HTTP/1.1 Rest Client Request : PUT /manifest/a991abac-5360-4673-9441-a7cdaaf1af24 HTTP/1.1 CORDS PARSER OPERATION END
  Example of POC XWIKI XML Plan
  <manifest name="POCXWIKI" xmlns="http://www.compatibleone.fr/schemes/cords.xsd" id="http://127.0.0.1:8084/manifest/a991abac-5360-4673-9441-a7cdaaf1af24" configuration="http://127.0.0.1:8087/configuration/016e69ca-217c-4cb6-a603-bea49d835e80" account="http://127.0.0.1:8084/account/cacf6a8e-0198-418b-af5b-0f98bba62884" security="http://127.0.0.1:8087/security/bf8707a3-2961-4aa8-a942-ba1f825dbe32" nodes="3" plan="http://127.0.0.1:8087/plan/a7044057-4842-49d1-9f7a-638001bb0e1e"> <node name="xwiki1" provider="any" id="http://127.0.0.1:8088/node/0911ba36-a8eb-49f3-8c93-7df52b434fd6" infrastructure="http://127.0.0.1:8088/infrastructure/71609251-6193-4177-88cc-b3c5b1c98864" image="http://127.0.0.1:8088/image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3"> <infrastructure name="quadcore" id="http://127.0.0.1:8088/infrastructure/71609251-6193-4177-88cc-b3c5b1c98864"/> <image name="xwiki" id="http://127.0.0.1:8088/image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3"/> </node> <node name="sqldatabase" provider="openstack" id="http://127.0.0.1:8088/node/b09429e4-48b0-4f93-afb6-50775f619396" infrastructure="http://127.0.0.1:8088/infrastructure/d24b5e99-5ac0-4150-ad46-a49b5a02c236" image="http://127.0.0.1:8088/image/181a2825-a2d8-4ec8-9e76-daaaf940e418"> <infrastructure name="dualcore" id="http://127.0.0.1:8088/infrastructure/d24b5e99-5ac0-4150-ad46-a49b5a02c236"/> <image name="mysql" id="http://127.0.0.1:8088/image/181a2825-a2d8-4ec8-9e76-daaaf940e418"/> </node> <node name="xwiki2" provider="openstack" id="http://127.0.0.1:8088/node/5e804ff1-4d55-4585-a45d-3ba072200335" infrastructure="http://127.0.0.1:8088/infrastructure/71609251-6193-4177-88cc-b3c5b1c98864" image="http://127.0.0.1:8088/image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3"> <infrastructure name="quadcore" id="http://127.0.0.1:8088/infrastructure/71609251-6193-4177-88cc-b3c5b1c98864"/> <image name="xwiki" id="http://127.0.0.1:8088/image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3"/> </node> <configuration name="pocxwiki" id="http://127.0.0.1:8087/configuration/016e69ca-217c-4cb6-a603-bea49d835e80" actions="2"> <action name="connectxwiki1" type="cordscript" expression="xwiki1.configure(sql1.href);" id="http://127.0.0.1:8087/action/73003013-04f2-49a5-8eb3-9377922dc3f1"/> <action name="connectxwiki2" type="cordscript" expression="xwiki1.configure(sql1.href);" id="http://127.0.0.1:8087/action/15ea22b3-d684-4739-aab5-56d659f34753"/> </configuration> <account name="compatibleOnePocXwiki" id="http://127.0.0.1:8084/account/cacf6a8e-0198-418b-af5b-0f98bba62884" users="6"> <user name="jamie" id="http://127.0.0.1:8087/user/c3f37a6c-9f61-4f1b-bd39-0a657ba13039"/> <user name="fabio" id="http://127.0.0.1:8087/user/ef12733f-c23d-4f1c-ba64-8f31994bd0f9"/> <user name="stephane" id="http://127.0.0.1:8087/user/f77dcddb-4373-458d-aaae-d399b8b1bdd5"/> <user name="xavier" id="http://127.0.0.1:8087/user/f7739202-99d4-41b3-b7a1-1362972ccad1"/> <user name="olivier" id="http://127.0.0.1:8087/user/475cef44-3b29-47d6-93d3-88cecf1e80eb"/> <user name="houssem" id="http://127.0.0.1:8087/user/d8c99190-aa5c-4624-99a8-f1b088062632"/> </account> <security name="public" level="public" id="http://127.0.0.1:8087/security/bf8707a3-2961-4aa8-a942-ba1f825dbe32"/> </manifest>
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/"> licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  Service Parser Operation (PARSER)

• CORDS-BROKER : CompatibleOne CORDS Broker
  Introduction
  This document describes the operation of the cords broker which produces an operational provisioning instance, refered to as a "service" by processing a valid provision "plan" that had been produced as a result of the operation of the CORDS Parser. This provisioning "plan" will have been resolved by the CORDS Parser to create the collection of fully qualified OCCI Cords instance identifiers, one for each of the active elements of the original service "manifest" request. The CORDS Broker must create a graph of CORDS OCCI instances and identifiers for the control and management of the actual resources required for the delivery of the provisioned system configuration. The algorithm of the broker is as follows: The XML file produced by the parser provides the instance identifier of the Cords "plan". An OCCI "instance" action message is sent to the "plan" category manager. The "plan" is retrieved using the identifier The "manifest" description is retrieved using the manifest identifier taken from the plan. The "security" information is retrieved using the security identifier taken from the manifest, if one is present. The "account" information is retrieved using the account identifier taken from the manifest, if present. The "configuration" details are retrieved using the configuration identifier taken from the manifest. The OCCI Cords "service" category instance is created and its instance identifer is added as a link to the provisioning plan instance. For each "node" link present in the "manifest": The "node" description is retrieved using the identifier from the LINK If the provider atribut is present and specfies as value other than "none", "null" or "any" then it will be used as the definition of the provider category. If a provider description is not present or undefined then it must be resolved. This is currently performed using the default operator provider preference value. The resolver will be consulted to localise the list of providers which offer the "provider" category. The providers will be tried in turn in order to retrieve their list of "provider" categories. Each "provider" category will be tried in turn to localise a "category" description in accordance with the desired provider selection criteria, price, energy constraints etc. The resolved "provider" category will be retained for use for the addition of a "contract" element to the "service" instance. Once all nodes have be processed to produce "contract" instances then the collection of "configuration" actions elements will be processed. For each "action" defined by the configuration section of the "manifest" an "instruction" instance will be created and appended to the list of instructions of the "contract" currently being processed. Each "instruction" will provide information to identify the target "contract" to which the instruction applies, the source "contract" from which the action will retrieve the information, the description of the property and it's current value. Once all configuration actions have be processed to produce "instruction" instances then the "service" instance can be started. An OCCI "start" actiion will be sent to the "service" instance manager. This action will be propagated to all "contract" instances described by the service. The configuration instructions of the "contract" will make information available to the starting instance. Each "contract" will engage or deploy the required resources through their appropriate provider specific interface. Important details, pertaining to the description of the provisioned resource, host address or name, adminsitrator password and resource identification, will be returned to the "contract" manager for storage in the corresponding instance record and document elements. The configuration instructions of the "contract" will retrieve these values for use by other configuration instructions of other contract instances. The collection of host addresses and administration passwords will be returned to the initiator of the "service" instance operation allowing access to and control of the underlying infrastructure and resources. At this point the instanciation of the provisioning "plan" is complete. In the next version, 2012, of the ACCORDS Platform monitoring operations, both energetic and financial will be initiated allowing for load optimisation, quality control and billing to be performed.
  Example of Cords Instancing Operation Output
  The following listing of provisioning operations was produced by processing the output file produced by the preceeding phase using the experimental Cords Broker. The only information required for the broker operation is the resolved id of the plan. It is taken from this XML for convenience. ./testcb verbose plan_pocxwiki.xml CORDS BROKER OPERATION START CORDS Request Broker ( CO-RDS-BROKER/1.0 ) Phase 1 : Preparation Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /plan/217d1a39-d63e-4e0d-a18f-7a73ce00e8bc HTTP/1.1 Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /request/0632d8e2-ee80-4ee0-9a3e-c679ef60382d HTTP/1.1 Rest Client Request : GET /account/5f0257b2-93bf-4526-a7b4-590a25c7bf80 HTTP/1.1 Rest Client Request : GET /security/9deed35f-cc1a-45f9-aef7-361f246e4f4a HTTP/1.1 Rest Client Request : GET /configuration/97ccbf7c-0bbf-49fd-8ff6-8b8b2bfdd00a HTTP/1.1 CORDS Request Broker ( CO-RDS-BROKER/1.0 ) Phase 2 : Provisioning OCCI Resolver( service, CO-RDS-BROKER/1.0 ) Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/d75fb8b9-6831-4613-aaf2-a269bbd77408 HTTP/1.1 Rest Client Request : GET /publication/5e317692-7de3-446b-b4c3-0efa4ad54d15 HTTP/1.1 Rest Client Request : POST /service/ HTTP/1.1 CORDS Node Rest Client Request : GET /-/ HTTP/1.1 Rest Client Request : GET /node/0911ba36-a8eb-49f3-8c93-7df52b434fd6 HTTP/1.1 Rest Client Request : GET /infrastructure/71609251-6193-4177-88cc-b3c5b1c98864 HTTP/1.1 Rest Client Request : GET /compute/fa960b3b-e467-49e3-af12-4c0550db22ae HTTP/1.1 Rest Client Request : GET /storage/f23dbcea-acba-40c7-a390-75de4038c1ee HTTP/1.1 Rest Client Request : GET /network/df9d503f-bd45-4882-b602-86b20fae5c2f HTTP/1.1 Rest Client Request : GET /image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3 HTTP/1.1 Rest Client Request : GET /system/73ccdd82-bc99-4ac4-8714-5e61b4e295dc HTTP/1.1 OCCI Resolver( contract, CO-RDS-BROKER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : GET /publication/5f40ef7d-b653-4fa9-9add-9cf15ebe6ba8 HTTP/1.1 Rest Client Request : GET /publication/3c6bc64c-740b-489a-9373-e796b646ac0c HTTP/1.1 Rest Client Request : POST /contract/ HTTP/1.1 CORDS Node Rest Client Request : GET /node/b09429e4-48b0-4f93-afb6-50775f619396 HTTP/1.1 Rest Client Request : GET /infrastructure/d24b5e99-5ac0-4150-ad46-a49b5a02c236 HTTP/1.1 Rest Client Request : GET /compute/0921af05-d14f-48d9-b8fd-2f1f47f08caa HTTP/1.1 Rest Client Request : GET /storage/f23dbcea-acba-40c7-a390-75de4038c1ee HTTP/1.1 Rest Client Request : GET /network/df9d503f-bd45-4882-b602-86b20fae5c2f HTTP/1.1 Rest Client Request : GET /image/181a2825-a2d8-4ec8-9e76-daaaf940e418 HTTP/1.1 Rest Client Request : GET /system/73ccdd82-bc99-4ac4-8714-5e61b4e295dc HTTP/1.1 OCCI Resolver( contract, CO-RDS-BROKER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : POST /contract/ HTTP/1.1 CORDS Node Rest Client Request : GET /node/5e804ff1-4d55-4585-a45d-3ba072200335 HTTP/1.1 Rest Client Request : GET /infrastructure/71609251-6193-4177-88cc-b3c5b1c98864 HTTP/1.1 Rest Client Request : GET /compute/fa960b3b-e467-49e3-af12-4c0550db22ae HTTP/1.1 Rest Client Request : GET /storage/f23dbcea-acba-40c7-a390-75de4038c1ee HTTP/1.1 Rest Client Request : GET /network/df9d503f-bd45-4882-b602-86b20fae5c2f HTTP/1.1 Rest Client Request : GET /image/9597d559-d7cc-4be7-bfcb-f09e1dd60ce3 HTTP/1.1 Rest Client Request : GET /system/73ccdd82-bc99-4ac4-8714-5e61b4e295dc HTTP/1.1 OCCI Resolver( contract, CO-RDS-BROKER/1.0 ) Rest Client Request : GET /publication/ HTTP/1.1 Rest Client Request : POST /contract/ HTTP/1.1 Rest Client Request : DELETE /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : PUT /service/eaa5df19-caf3-4c8d-aa8a-1c019bf51996 HTTP/1.1 CORDS Request Broker ( CO-RDS-BROKER/1.0 ) Provisioned 3 Nodes CORDS Request Broker ( CO-RDS-BROKER/1.0 ) Phase 3 : Configuration Rest Client Request : GET /action/b7e85470-cb10-41a1-bdf5-6ec0da7fcf6b HTTP/1.1 Rest Client Request : GET /action/c61446b9-10b0-4e8a-bbf4-d96ed0ea4605 HTTP/1.1 Rest Client Request : POST /link/ HTTP/1.1 Rest Client Request : POST /service/eaa5df19-caf3-4c8d-aa8a-1c019bf51996?action=start HTTP/1.1 CORDS Request Broker ( CO-RDS-BROKER/1.0 ) Terminated (service_plan_pocxwiki.xml) CORDS BROKER OPERATION END
  Example of Cords Broker Instance Report
  This file is produced by the Cords Broker as the result of its provisioing and instancing operation. It contains all information required for the management and exploitation of the different platforms thus provisioned. <service name="POCXWIKI" plan="http://127.0.0.1:8087/plan/217d1a39-d63e-4e0d-a18f-7a73ce00e8bc" manifest="http://127.0.0.1:8084/manifest/0632d8e2-ee80-4ee0-9a3e-c679ef60382d" account="http://127.0.0.1:8084/account/5f0257b2-93bf-4526-a7b4-590a25c7bf80" tarification="http://127.0.0.1:8084/account/5f0257b2-93bf-4526-a7b4-590a25c7bf80" id="http://127.0.0.1:8087/service/eaa5df19-caf3-4c8d-aa8a-1c019bf51996" contracts="3" service="http://127.0.0.1:8087/service/eaa5df19-caf3-4c8d-aa8a-1c019bf51996"> <contract name="xwiki1" node="http://127.0.0.1:8088/node/0911ba36-a8eb-49f3-8c93-7df52b434fd6" provider="any" profile="POCXWIKI" reference="" hostname="" rootpass="" tarification="" id="http://127.0.0.1:8088/contract/37bcabe9-ebf5-4818-9835-50c1cfa6bed9"/> <contract name="sqldatabase" node="http://127.0.0.1:8088/node/b09429e4-48b0-4f93-afb6-50775f619396" provider="any" profile="POCXWIKI" reference="" hostname="" rootpass="" tarification="" id="http://127.0.0.1:8088/contract/5515c991-2215-4f33-9ce1-b820e990c7e8"/> <contract name="xwiki2" node="http://127.0.0.1:8088/node/5e804ff1-4d55-4585-a45d-3ba072200335" provider="any" profile="POCXWIKI" reference="" hostname="" rootpass="" tarification="" id="http://127.0.0.1:8088/contract/b827b640-ef84-42ac-a684-931b26c89527"/> </service>
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/">licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  Service Broker Operation (BROKER)

• CO-REST : Compatible One REST Server Library
  Introduction
  This document describes the public functional interface of the Compatible One REST Server Library which provides a basic building block for the construction of Compatible One Service components. This is a standard "C" library allowing for easy integration for use in any other programming environment. The library has been used in the construction of the Compatible One Service Publication Platform and will also be employed in both the construction of the Compatible One Resource Description Schema Parsing Service and of the Compatible One OCCI Interfaces to the open source infrastructure providers OpenStack and OpenNebula. The library will be extended in the near future to provide HTTP/REST Client functionalities to complement the currently available functions required for the construction of the REST Servers.
  rest_server
  returns	int
  parameter	char * nptr	the name string to be used to identify the REST server
  parameter	int port	port number on which the REST server will listen
  parameter	int tls	require transport layer security for this connection
  parameter	int max	maximum number of clients to alllow waiting for connect
  parameter	struct rest_interface * iptr	table of REST interface methods
  This function will build and operate a fully functional HTTP/REST Server using TCP. The provided parameters will describe the server in terms of its listening port and its host identity. The final parameter will provide the collection of user function pointers that are to be invoked for the different REST/CRUD operational verbs ( GET, POST, PUT, DELETE, HEAD). These function relays allow the actual behaviour of the server to be defined outside of the library and will be invoked by passing the client connection structure and the request description structure for processing. The function relay is to return a valid response structure pointer describing the details of the response to be returned to the client request. struct rest_interface { void * instance; struct rest_server * (*initialise)(void * instance,struct rest_server * sptr); int (*authorise)(void * instance,struct rest_client * cptr,char * user, char * pass); struct rest_response * (*get)(void * instance,struct rest_client * cptr, struct rest_request * rptr); struct rest_response * (*post)(void * instance,struct rest_client * cptr, struct rest_request * rptr); struct rest_response * (*put)(void * instance,struct rest_client * cptr, struct rest_request * rptr); struct rest_response * (*delete)(void * instance,struct rest_client * cptr, struct rest_request * rptr); struct rest_response * (*head)(void * instance,struct rest_client * cptr, struct rest_request * rptr); struct rest_response * (*extension)(void * instance,struct rest_server * sptr, struct rest_extension* xptr); void (*before)(void * instance,struct rest_client * cptr, struct rest_request * rptr); void (*after)(void * instance,struct rest_client * cptr, struct rest_request * rptr); } The rest_interface structure provides the instance to allow an application instance pointer or structure to be set as the parent of the interface. It will be passed as the first parameter of all method invocations in order that the target function be able to identify the particular parent instance for which it has been invoked. Only the collection of methods required for a particular application use are required to be defined in the function interface table prior to the invocation of this function, need to be specified in the NULL values will be directed to the standard unsupported method response function of the REST library. The before and after relays will, when defined, be invoked as their names imply, before and after the operational REST/HTTP method invocations. This allows special features to be handled such as required by the auto-unpublication and auto-publication mechanisms necessary to be able to influence load balancing and subsequently acheive elasticity and scalability. The structures rest_server and rest_client are currently opaque since they are very much implementation dependant. They are transfered to and fro across the interface to allow the server side to know for which server or client structure the operation is to be performed. The rest_request structure, presented below, is created by the server when an incoming HTTP request is detected. The request comprises, in addition to the method, object and version strings, a linked list of rest_header items, one for each of the HTTP header fields. The field may carry a filename or a string of data depending up on the value of the type field, where zero means a filename and not zero signifies a text string. struct rest_request { struct rest_header * first; struct rest_header * last; char * method; char * object; char * version; int type; char * body; } The rest_extension structure allows extensions to be added to the REST Server operational select loop in order that network activity may be detected and dispatched correctly to the handler for the extension. The payload and type fields of this structure are opaque to the REST server and are for use by the extension handler only. struct rest_extension { struct rest_extension * previous; struct rest_extension * next; void * payload; int type; struct connection * net; } The functions referenced by the function pointers in the method interface description table rest_interface, described above, will need to make use of the following library functions during their operation for the correct production of the rest_response package to be transmitted back to the client by internal functions of the library. The following code extract provides an example of the use of this function static struct rest_server * example_initialise(void * v, struct rest_server * sptr ); static int * example_authorise(void * v, struct rest_client * cptr, char * user, char * pass ); static struct rest_response * example_get(void * v, struct rest_client * cptr, struct rest_request * rptr ); static struct rest_response * example_post(void * v, struct rest_client * cptr, struct rest_request * rptr ); static struct rest_response * example_put(void * v, struct rest_client * cptr, struct rest_request * rptr ); static struct rest_response * example_delete(void * v, struct rest_client * cptr, struct rest_request * rptr ); static struct rest_response * example_head(void * v, struct rest_client * cptr, struct rest_request * rptr ); static struct rest_extension* example_extension(void * v, struct rest_server * sptr, struct rest_extension * xptr);static int example_of_rest_server_operation( char * nptr ) { struct rest_interface example = { (void *) 0, example_initialise, example_authorise, example_get, example_post, example_put, example_delete, example_head, example_extension }; return( rest_server( "Server Name", 80, 0, 0, & example ) ); }
  rest_response_body
  returns	void
  parameter	struct rest_response * aptr	a REST response structure
  parameter	char * body	the body parameter, either a filename or a string
  parameter	int type	indicates the type of the body parameter 0:file, 1:string
  This function is to be called to establish the response body to be returned. The response body may be specified as a filename or as a string of response body text. The third parameter type will differentiate between the two body types. When type is zero the body type is a filename that will be read and returned as the body content. When type is set to one then the body content will be contained in the string value of the second parameter. struct rest_response { struct rest_header * first; struct rest_header * last; int status; char * version; char * message; int type; char * body; }
  rest_response_status
  returns	struct rest_response *
  parameter	struct rest_response* aptr	a REST response structure
  parameter	int status	the HTTP status code to establish in the response
  parameter	char * message	the human readable message describing the status code
  This function simply allows the status code and status message fields of the REST response structure to be set with the provided values.
  rest_response_header
  returns	struct rest_header *
  parameter	struct rest_response * aptr	a REST response structure
  parameter	char * nptr	an HTTP header field name string
  parameter	char * vptr	an HTTP header field value string
  This function adds an HTTP header field to the indicated response structure using the provided field name and field value strings. The header structure will be added to the end of the current list of headers and will be returned to the caller. struct rest_header { struct rest_header * previous; struct rest_header * next; struct rest_request * parent; char * name; char * value; } The parent field will only be set for headers which belong to a REST request structure.
  rest_allocate_response
  returns	struct rest_response *
  parameter	struct rest_client * cptr	a REST client connection structure
  This function simply allocates a REST response structure for the indicated client connection.
  rest_drop_client
  returns	struct rest_client *
  parameter	struct rest_client * cptr	a REST client connection structure
  This function simply releases a client structure and disconnects its eventual open connection.
  rest_html_response
  returns	struct rest_response *
  parameter	struct rest_response * aptr	a REST response structure
  parameter	int status	the HTTP status code to establish in the response
  parameter	char * message	the human readable message describing the status code
  This function establishs the response status and message fields and sets the response body to contain a string of HTML data describing the tatus message.
  rest_response_failure
  returns	struct rest_response *
  parameter	struct rest_client * cptr	a REST client connection structure
  parameter	int status	the HTTP status code to establish in the response
  parameter	char * message	the human readable message describing the status code
  This function allocates a response structure and prepares the status and message fields with the provided error code and message.
  rest_resolve_header
  returns	struct rest_header *
  parameter	struct rest_header * hptr	the list of HTTP header fields to scan
  parameter	char * name	an HTTP header field name string to be located in the list
  This function will search the provided list of HTTP header fields to locate the header field name provided as the second parameter. The HTTP header structure will be returned if the search is succesful otherwise a NULL pointer will be returned.
  rest_add_extension
  returns	struct rest_extension *
  parameter	struct rest_server * sptr	the REST server structure to which the extension is to be added.
  This function allows network protocol extensions to be added to the REST server in order that their socket activity be detected during the REST server operational loop and dispatched for processing by the appropriate extension handling interface.
  rest_drop_extension
  returns	struct rest_extension *
  parameter	struct rest_server * sptr	the REST server structure to which the extension is to be added.
  parameter	struct rest_extension * xptr	the REST server extension structure to be removed.
  This function allows a network protocol extension handler to be removed from the REST server in order that socket activity no longer be detected during the REST server operational loop.
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/">licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  Rest Server Library (COREST)

• CO-OCCI : CompatibleOne OCCI Server Library
  Disclaimer
  THIS DOCUMENT AND THE SOFTWARE THAT IT DESCRIBES IS PROVIDED BY IAIN JAMES MARSHALL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  Table of Contents
  Disclaimer Introduction to the CompatibleOne OCCI Server Library. The Application Programming Interface of the CompatibleOne OCCI Server Library. Starting an OCCI Server Creating and OCCI Category Addition of an OCCI Attribute to an OCCI Category Addition of an OCCI Action to an OCCI Category Removal of an OCCI Category The Structures and Data Types of the CompatibleOne OCCI Server Library. The OCCI Category Structure The OCCI Category Attribute The OCCI Category Action References. Publication and Licensing Information.
  Introduction
  This document describes the CompatibleOne OCCI Server Library which provides the basic building block for the construction of CompatibleOne OCCI Service components comprising the Accords platform. This library is a standard "C" library allowing easy integration for use in any other programming language environment. The library is built on top of the REST/HTTP server Library and makes implicite but extensive use of the collection functions described in the document CO-REST : CompatibleOne Rest Server. This OCCI server package provides all the functions required to build the OCCI category structures needed for the description of the behaviour of the OCCI server. The list of categories is passed to the OCCI server on startup and provides the tables of interface methods to be called back as required to satisfy the service requests received through the underlying HTTP/REST server. The concepts and terminology required for the correct understanding of the information provided in this document may be aquired using the specifications published on the http://occi-wg.org">Open Cloud Computing Interface (OCCI) web site. The overall architecture of the use of this library can be seen in the following table. APPLICATION Application Program Instance CATEGORY OCCI Category and Action Handling OCCI OCCI Server HTTP REST Server REST POST GET PUT DELETE HEAD CRUD CREATE RETRIEVE UPDATE DELETE From the above it should be understood that: The application program instance encapsulates the entire OCCI server mechanism. The OCCI Category and Action management mechanisms prepare the list of Categories, Attributes and Actions. The OCCI Server Layer is responsible for directing requests back to the appropriate Category Methods. The REST Server Layer is responsible for handling of all HTTP operations, requests and responses through the method table. The REST/HTTP methods applied to OCCI categories through this architecture perform the ultimate CRUD operations on the Category instances.
  Application Programming Interface
  This section of this document describes the public functional interface of the CompatibleOne OCCI Server Library which provides a basic building block for the construction of the CompatibleOne OCCI Accords platform and tools.
  occi_server	Create and Operate an OCCI Server
  Syntax int occi_server ( char * name, int port, char * tls, struct occi_category * categories, char * authorisation ) Description The OCCI Server Library is built on top of the functionalities provided by the REST Server library and delegates responsibility for the processing of all aspects of the low level HTTP communication, message reception and response transmission. Each of the categories in the category list will provide their own functional interface table for each of the REST operational verbs ( GET, POST, PUT, DELETE, HEAD). Actions defined for individual categories will provide the function pointer to the application function implementing their particular behaviour. These function relays allow the actual behaviour of the server to be defined outside of the library and will be invoked passing the concerned OCCI category object, the client connection structure and the request description structure as parameters. Each The function relay is to return a valid REST response structure pointer describing the details of the response to be produced and returned to the client by the REST server. Parameters The name parameter provides of the name of the server and will be used by the HTTP Server header field that will be returned in each response message issued by the underlying REST server. The port parameter provides the TCP port number on which the REST server is to listen. The tls parameter which, when not NULL, provides the name of the transport layer security configuration to be used to specify keys and certificates and other TLS operational conditions. The categories parameter will provide the list of OCCI categories that are required to describe the server in terms of its OCCI capabilities. This list of categories will be built using the different functions provided by this library to this effect. The authorisation parameter may provide a non NULL string that is to be used by an HTTP X-OCCI-AUTH header field to provide application specific authorisation information to be supplied by the server with each and every response message. Example #include "standard.h" #include "rest.h" #include "occi.h" extern struct occi_category * build_category_list(); int main( int argc, char * argv[] ) { char * agentname="OcciTest"; int port=8088; char * tls=(char *) 0; int threads=1; struct occi_category * list=(struct occ_category *) 0; char * authorisation=(char *) 0; int status=0; /* tool specific command line processing ..... */ if (!( list = build_category_list() )) { printf("\nerror building OCCI category list\n"); return(1); } else { if ((status = occi_server( agentname, port, tls, threads,list, authorisation )) != 0) printf("\nerror starting OCCI server : %u\n",status); list = occi_remove_categories( list ); return( status ); } } An example of the build_category_list function is demonstrated in the category list builder.
  occi_remove_category	Removal of an OCCI Category
  Syntax struct occi_category * occi_remove_category ( struct occi_category * category ) Description This function allows the removal of a complete OCCI category representation structure including its underlying attribute and action lists. All memory associated with the category control structure will be released. Parameters The category parameter This parameter provides the pointer to the OCCI category control structure to be released and removed. Example An example of the use of this function is provided in the example demonstrating the category list builder.
  occi_add_attribute	Addition of an Attribute to a Category
  Syntax struct occi_attribute * occi_add_attribute ( struct occi_category * category, char * name, int mandatory, int immutable ) Description This library function is to be used for the addition of an OCCI Attribute control structure to an OCCI Category control structure. The parameters provided at the call will be used to describe the attribute. Parameters The category parameter This must provides a pointer to the valid OCCI Category control structure to which the new attribute is to be appended. The name parameter This string parameter provides the name to be used to identify and access this attribute value. The mandatory parameter As its name suggests this boolean value indicates if the attribute is mandatory and as such is required to be part of OCCI renderings transiting between the client and the server. The immutable parameter Again as its name suggests, this boolean parameter indicates if modification of the attribute is to be allowed by the client. Example An example of the use of this function can be found here.
  occi_add_action	Addition of an Action to a Category
  Syntax struct occi_action * occi_add_action ( struct occi_category * category, char * name, char * parameters, void * action ) Description This library function is to be used for the addition of an OCCI Action control structure to an OCCI Category control structure. The parameters provided at the call will be used to describe the action. Parameters The category parameter This must provides a pointer to the valid OCCI Category control structure to which the new action is to be appended. The name parameter This string parameter provides the name to be used to identify and invoke this action. The parameters parameter This parameter provides a comma separated list of parameter names for which values may be defined by invocation expressions for this action method. The action parameter This parameter, though defined for simplicity as a void * provides a function pointer to the actual operational function to Again as its name suggests, this boolean parameter indicates if modification of the attribute is to be allowed by the client. Example An example of the use of this function can be found here.
  occi_create_category	Creation of an OCCI Category
  Syntax struct occi_category * occi_create_category ( char * domain, char * name, char * scheme, char * classname, char * relation, char * title ) Description This function allows the creation of an OCCI category control structure. It will be used to provide the description of an OCCI category during the operation of an OCCI Server Instance. The structure will be used as the parameter to the appropriate functions for tha addition of OCCI Attribute and Action descriptons. Parameters The domain parameter This string parameter provides the domain component to be used for the construction of the complete category attribute access path of the form : domain.name.attribute. The name parameter This string parameter provides the name component to be used for the construction of the complete category attribute access path of the form : domain.name.attribute. The scheme parameter This string parameter provides the complete url to be used to locate the document contianing the formal description of the complete category in machine readable form. The classname parameter This string value provides the nature of the category and should be one of the following basic types as described in the http://ogf.org/documents/GFD.183.pdf">XMPP Core standard document: kind mixin action link The relation parameter This string parameter provides the name of the OCCI category or resopurce which is the direct parent of the newly created category definition. This should at least be the basic resource type as defined in the http://ogf.org/documents/GFD.183.pdf">XMPP Core standard document. The title parameter This string parameter provides a human readable text describing the category and its basic use and semantics. Example Here we have a example implementation of the function build_category_list demonstrating the use of the OCCI server supoport functions required for the construction of a valid OCCI category control structure. /* */ /* trivial example of an OCCI action function */ /* */ struct rest_response * application_test_example( struct occi_category * optr, struct rest_client * cptr, struct rest_request * rptr ) { return( (struct rest_response *) 0 ); } /* */ /* example of creation of an OCCI category comprising */ /* three attributes "name, description and status" */ /* and one action "test" */ /* */ struct occi_category * build_category_list() { struct occi_category * cptr; struct occi_attribute * aptr; struct occi_action * fptr; if (!( cptr = occi_create_category( "example", "test", "http://example.test.org/test", "occi.core.resource", "Example of Occi Category Creation" ))) return( cptr ); else if (!( aptr = occi_add_attribute( cptr, "name", 1, 0 ) )) return( occi_remove_category( cptr ) ); else if (!( aptr = occi_add_attribute( cptr, "description", 0, 0 ) )) return( occi_remove_category( cptr ) ); else if (!( aptr = occi_add_attribute( cptr, "status", 0, 1 ) )) return( occi_remove_category( cptr ) ); else if (!( fptr = occi_add_action( cptr, "test", "", application_test_example ) )) return( occi_remove_category( cptr ) ); else return( cptr ); } Clearly, in the above example only one category instance is created and returned to the caller. Further instances may be appended via the double linked list pointers provided within the occi_category structure for this purpose.
  Structures and Data Types
  struct occi_category	The OCCI Category Structure definition
  This structure contains the information needed to both represent and operate an OCCI category within this C implementation of an OCCI Server. In all functional interface descriptions above the term struct occi_category refers to an entity or entity pointer of exactly this type. The structure contains fields required for the management of the category with in the server, other fields necessary for the description of the category and finally fields needed for its flexible operation within an abstract processing tool chain. struct occi_category { struct occi_category * previous; struct occi_category * next; struct occi_attribute * first; struct occi_attribute * last; struct occi_action * firstact; struct occi_action * lastact; char * domain; char * id; char * scheme; char * class; char * title; char * rel; char * location; int access; void * interface; void * callback; void * payload; } previous this member of the occi_category structure points to an eventual preceeding category definition in the category list. The pointer will be null when the category is the first in the list. next this member of the occi_category structure points to an eventual following category definition in the category list. The pointer will be null when the category is the last in the list. first this member of the occi_category structure points to the first attribute in the category attribute list. The pointer will be null when no attributes are defined for the category. last this member of the occi_category structure points to the last attribute in the category attribute list. The pointer will be null when no attributes are defined for the category. firstact this member of the occi_category structure points to the first action in the category action list. The pointer will be null when no actions are defined for the category. lastact this member of the occi_category structure points to the first action in the category action list. The pointer will be null when no actions are defined for the category. domain this member of the occi_category structure provides the domain name component of the full category name. id this member of the occi_category structure provides the identification name component of the full category name. scheme this member of the occi_category structure provides the url of the schema of the document describing the category. class this member of the occi_category structure provides the OCCI nature of the category as kind, action, link or mixin. title this member of the occi_category structure provides a human readable description of the category. rel this member of the occi_category structure provides the parent category type from which this category is derived. This would be at least the resource of the standard OCCI core. location this member of the occi_category structure provides the category location string used in producing access prefixs for instances of this category. access this member of the occi_category structure defines the access rights and behaviour of the category. This bitfield value contains definitions to be used by external tools for the interpretation and publication of categories. interface this member of the occi_category structure will be used to carry the table of application interface functions that will be invoked as and when required for the servicing of standard REST requests received by the OCCI server for this particular category. callback this member of the occi_category structure will be used to carry the table of application call back functions that will be invoked as and when required during the servicing of standard REST requests received by the OCCI server for this particular category. This method table allows the definition of CRUD extensions to be performed on particular category instance definitions during the processing of a REST operation. payload this member of the occi_category structure allows storage of optional data extensions as required by the processing chain prior to invocation of the occi server initiation function. The instance would be used by post and pre processing tools during REST and CRUD level operations.
  struct occi_attribute	The OCCI Attribute Structure definition
  This structure contains the information needed to both represent and operate an attribute of an OCCI category within this C implementation of an OCCI Server. In all functional interface descriptions above the term struct occi_attribute refers to an entity or entity pointer of exactly this type. struct occi_attribute { struct occi_attribute * previous; struct occi_attribute * next; struct occi_category * parent; char * name; int mandatory; int immutable; } previous this member of the occi_attribute structure points to an eventual preceeding attribute definition in the attribute list. The pointer will be null when the attribute is the first in the list. next this member of the occi_attribute structure points to an eventual following attribute definition in the attribute list. The pointer will be null when the attribute is the last in the list. parent this member of the occi_attribute structure points to the parent category structure instance to which this attribute belongs. The pointer will be null only when an attribute is not attached to the attribute list of a category. name this member of the occi_attribute structure provides the identification name of the attribute. mandatory this boolean member of the occi_attribute structure indiatces that a value for this attribute is required to be present in messages received in client requests. immutable this boolean member of the occi_attribute structure indicates that this attribute may not be modified by values present in messages received in client requests.
  struct occi_action	The OCCI Action Structure definition
  This structure contains the information needed to both represent and operate an action of an OCCI category within this C implementation of an OCCI Server. In all functional interface descriptions above the term struct occi_action refers to an entity or entity pointer of exactly this type. struct occi_action { struct occi_action * previous; struct occi_action * next; struct occi_category * parent; struct occi_parameter * first; struct occi_parameter * last; char * name; void * action; } previous this member of the occi_action structure points to an eventual preceeding action definition in the action list. The pointer will be null when the action is the first in the list. next this member of the occi_action structure points to an eventual following action definition in the action list. The pointer will be null when the action is the last in the list. parent this member of the occi_action structure points to the parent category structure instance to which this action belongs. The pointer will be null only when an action is not attached to the action list of a category. first this member of the occi_action structure points to the first parameter in the action parameter list. The pointer will be null when no parameters are defined for the action. last this member of the occi_action structure points to the last parameter in the action parameter list. The pointer will be null when no attributes are defined for the action. name this member of the occi_action structure provides the identification name of the action or method. action this member of the occi_action structure must be initialised to point to the service function to be invoked upon reception of action invocation requests for this particular action. The target function to which this field points must be of the following signature: struct rest_response * application_test_example ( struct occi_category * optr, struct rest_client * cptr, struct rest_request * rptr ) Definitions of the types required to be received and returned by these action service functions may be found in the document describing the application programming interfaces,structures and data types of the CompatibleOne REST Server Library.
  Reference Material
  CompatibleOne OCCI Client Library http://ogf.org/documents/GFD.183.pdf">GFD 183 OCCI Core standard http://ogf.org/documents/GFD.184.pdf">GDF 184 OCCI Infrastructure http://ogf.org/documents/GFD.185.pdf">GDF 185 OCCI HTTP Binding http://www.ietf.org/rfc/rfc2616.txt">RFC 2616 HTTP 1.1 Specifications
  Publication and Licensing Information
  The sources of this work are published under the terms of the LGPL by Iain James Marshall of Prologue at http://gitorious.ow2.org/ow2-compatibleone/accords"> http://gitorious.ow2.org/ow2-compatibleone/accords
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/">licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  OCCi Server Library (OCCI)

CompatibleOne Specifications

• CompatibleOne Accords Open Source Distribution
  Information
  This document provides important information describing the CompatibleOne Accords Open Source Distribution published by Iain James Marshall for Prologue for the OW2 Open Source Comunity in September 2011. These sources are provided in accordance with the CreativeCommons Open Source Software License as expresed at the foot of this page, and all roghts are currently reserved. The following table summarises the libraries and executable programs that may be built from this source distribution. Directory Target Nature Description cOne/coxml libcoxml.so Library This library provides the XML file parsing and production functions. cOne/occi libocci.so Library This library provides the basic OCCI Category behaviour cOne/cords libcords.so Library This library provides the basic CORDS behaviours cOne/corest libcorest.so Library This library provides the REST Server and Client functions cOne/cocci libcocci.so Library This library provides the OCCI Server and Client functions cOne/cocarrier libcocarrier.so Library This library provides the different carrier client interfaces cOne/pubocci libpubocci.so Library This library provides the OCCI Publishing and Resolver functions cOne/copabr libcopabr.so Library This library provides the CORDS PArser and Broker functions cOne/coss coss Server This program is the CompatibleOne Security Service cOne/coobas coobas Server This program is the CompatibleOne Order, Billing and Accountancy Service cOne/comons comons Server This program is the CompatibleOne Monitoring Service cOne/publisher publisher Server This program is the CompatibleOne Publisher Service cOne/parser parser Server This program is the CompatibleOne Cords Parser Service cOne/broker broker Server This program is the CompatibleOne Cords Broker Service cOne/procci procci Server This program is the CompatibleOne Cords Procci Service cOne/osprocci osprocci Server This program is the CompatibleOne OpenStack Provider Service cOne/onprocci onprocci Server This program is the CompatibleOne Open Nebula Provider Service cOne/azprocci azprocci Server This program is the CompatibleOne Windows Azure Provider Service
  http://creativecommons.org/licenses/by-nc-nd/3.0/"> http://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png" /> Ce(tte) http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" rel="dct:type">oeuvre de http://creativecommons.org/ns#" property="cc:attributionName">Iain James Marshall est mise à disposition selon les termes de la http://creativecommons.org/licenses/by-nc-nd/3.0/">licence Creative Commons Paternité - Pas d’Utilisation Commerciale - Pas de Modification 3.0 non transcrit.

  CompatibleOne Accords Open Source Distribution information
• CORDS: CompatibleOne Resource and Request Description Schema