Hello Evryone, Likewise I would like to thank you for this interesting and satisfying though short exchange on the subject of JSON for OCCI. I would like to share my view of this in response to the discussions and the explaination of Gary hereunder. 1) The core OCCI specifications offer : a) a means for describing classes, in terms of members, methods and relations, b) a means by which operations may be described and performed on these instances. This maps perfectly to the so called REST paradigm over HTTP where the verbs introduced and standardised in HTTP 1.1 2) The previous usage of the HTTP headers for the transport of instance state is dangerous because HTTP agents, clients ,proxies and servers alike are at liberty to reorganise, and even reduce the message headers. 3) The initiative to standardise a description of the OCCI instance state is necessary to alleviate the real danger in (2) and to ensure the data is transfered in the correct region, the body of the message. 4) JSON is appropriate for use in Web Browsers since it is directly compatible with JavaScript. It should however be as immediatly usable by the recipiant as possible whereby the content of the message would be affected directly to a JavaScript variable and would allow access to the various internals with the easiest and shortest member access path. 5) The CLASS description should really only be made available during the capacities request in order to reduce JSON object complexity and size during actual RPC like object oriented operations. We should not have to continuously sidestep this information ( for performance reasons amongst others ) In addition to the above points I provide a summary description of the work we have undertaken here at CompatibleOne: 1) we have used the OCCI core as the basis for the specification of a complete and very loosly coulped cloud brokering system. 2) The platform is capable of describing and performing smart, automatic provisioning or placement of resources (Iaas and Paas for now) 3) This is performed across multiple provisioning platform types ( OpenStack, OpenNebula, EC2, Azure, Proactive, SlaopOs ... ) 4) The platform provides security both for the platform and as a comodity 5) Monitoring is performed both for the platform and as a comodity 6) Billing, costing and accountancy linkups are in place for the construction of real world commercial brokering systems. A request processed by this platform may result in several hundreds even thousands of OCCI message exchanges between the different components as required for the resolution of the request an the management of security, monitoring and transactions. Consquently the both the size, compexity and flexibility of these messages is of great importance to us. We wish to participate in the elaboration of the standard for the description of both the OCCI class and its instances using both JSON for user oriented browser based operation and XML for other more automated type business operations. Sincerely Jamie Marshall Expertise Manager Prologue Chief Technical Officer Compatible One Systems Architect CloudPort and Medusa ijm667@hotmail.com 0033 6 22 51 78 98
Date: Thu, 9 Feb 2012 09:45:40 -0700 From: garymazzaferro@gmail.com To: occi-wg@ogf.org Subject: [occi-wg] OCCI header information for JSON
Hi
Thank you for the interesting discussion on meta-data for the json rendering.
It was suggested OCCI meta-data should be defined as HTTP headers for the JSON and XML forms. We should seriously examine adverse outcomes of modifying well established protocols. Placing OCCI meta-data in the http header area ignores best design practices, specifically compartmentalization. We would not consider placing OCCI headers in IP or TCP protocol header space, we should not consider impacting the HTTP transport data space. Although precedence has been set, additional meta-data in http headers for alternative forms of OCCI data exponentially increases the cost burden on product testing and validation.
In my experience attempting to release a CDMI javascript library, I ran into a few security issues surrounding browser behavior. It seems the prominent browsers execute a Cross Origin Resource Sharing (CORS) protocol when a custom header is defined for any http request. CORS places a additional protocol demands on OCCI servers and OCCI clients that normally would not need to support CORS.
I would strongly suggest to avoid the complexities associated with OCCI meta-data in the http message header area and select an alternative approach placing OCCI meta-data in the http message body.
b/r gary mazzaferro
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg