Sam +2 It is much simpler to map a strongly hierarchal structure to a flat representation than the converse. Moving towards a JSON ONLY solution may alienate and exclude interoperability with other well established and standardized management schemes. IMHO, this would be very poor approach for this occi effort. In fact, using a JSON scheme would prove challenging to clearly represent relationships in a unix /dev tree or the /proc file system. For example, representing the different views capable in SNIA storage models with JSON would be extremely difficult, if not at all. Rendering a model, whether in XML or JSON should not be the issue. Providing an accurately rendered representation reflecting the interests of the users, including system managers, is very important. Today, most computer systems are organized and represented though management schemes that are at least hierarchical if not network models ie: recursion though symbolic and hard links. Most storage systems, along with TINA, and DMTF's CIM, are complex systems represented though standardized management schemes that are complex network models. As the cloud matures and as we adopt collaborative practices, do we actually believe cloud systems and architectures will reduce complexity ? I don't believe so. It is far easier to represent hierarchical and network (not networking) information with XML than JSON. It also requires less time and effort, we don't have to flatten existing models and delay adoption. I personally believe there will be many opportunities to represent the complex in flatter renderings (mappings) like JSON, flat text or ASN.1, SNMP MIBS or enterprise 6bit paper tape. Each entity involved with clouds will have their own business models and processes. Roles and existing operational models will determine the informations required from clouds, one size will not fit all. We cannot treat clouds as a university mid-term project or the 20year fiasco of linux. IMHO, again, moving to a JSON only solution would radically defeature capabilities and significantly limit the value proposition of deployments. IMHO, Sam is on target, Mark: Go work as an IT tech in a very large data center, your opinion will change. cheers, Gary Mazz Sam Johnston wrote:
Including the list this time...
On 5/7/09, Sam Johnston <samj@samj.net> wrote:
So examples of the requisite extensibility include creating complex storage and networking resources and importing the (large) existing base of compute resources (in OVF or other legacy formats). It is without doubt better to have the option and not use it than give it up and find we need it.
For the componentisation of implementations, it's highly unlikely that the best architecture is to use the same platforms for everything from controllers to monitoring to billing to security etc. in which case it is extremely useful to be able to pass your messages around and build them iteratively. JSON is great for [de]serialising objects in memory but is actually more troublesome than XML for this particular use case.
I guess a lot of this comes down to the public vs private debate that Ignacio captured nicely in a recent blog post. I prefer not to differentiate and have my money on hybrid architectures. As a potential client implementor I'd mych prefer not to have to implement OCCi *and* vCloud^W OVF2.0 for things like that function people are calling 'cloudbursting'.
With XML we can be light for light users and as fat as need be for the more demanding ones (like my enterprise clients who are primarily from the CAC 40 - top 40 companies in France).
FWIW I actually dislike XML as much as the next guy but I'm also very practical and like to avoid cutting off my nose to spite my face.
Sam on iPhone
On 5/7/09, Mark Masterson <mmasterson@csc.com> wrote:
Sam -- for the record, I find blanket assertions such as "an essential enterprise feature" to be problematic. I'm about as enterprisey as anyone could possibly be, and you are definitely *not* speaking on my behalf here. I've no doubt that you are speaking for someone or something that relates to your experience, and an alternative phrasing such as "an essential feature for the enterprise customers I work with" would clearly articulate that. But I"m here to tell you -- there's a large and valid population of folk who self-identify as "enterprise" who disagree with much of your reasoning. Here are some examples:
-- "The schema is a WiP for a start, and an essential enterprise feature".
No, it is not. In my world, we are busy trying to learn many lessons from the Web, only some of which fit within the scope of the term REST. One of the most important lessons we are trying to internalise and apply is that a priori schemas are sometimes much more trouble than they are worth. In that world, among other things, there are any number of examples of cases where I am trying to figure out how to *store my data* without an a priori schema, because that confers on me all sorts of advantages which seem to move me an inch or two towards the holy grail of disposable software. I can assure you that, in those sorts of contexts, the idea of going to those lengths, only to move data to and from those schema-less data stores via "standard" mechanisms that impose one of its own can provoke gales of (slightly bitter) laughter.
-- "Our success *requires* playing nice with OVF. And SNIA. And probably a bunch of other stuff in the future" followed then by "Our spec will be concise anyway given how we use XML in the lightest way possible".
It worries me that you may not see the contradiction lurking in those two statements. At best, these statements have a high probability of both being true only at a given point in time; one quite early in the life cycle of OCCI (which, of course, is where we are). Over time, it is *very* unlikely (verging on the impossible, IMO) that both statements can *remain* true. This is because the imperative underlying each of these statements is in direct conflict with the other -- "playing nice with others" is in direct conflict with "concise". We all seem to be in agreement about the merits of concise -- the disagreement revolves around the degree of "playing nice with others", and / or preparing for playing nice with others. I think there is a strong argument to be made for making a deliberate decision, at this point in the lifecycle, to *not* make playing nice with others a goal. Explicitly -- IOW, making it a non-goal. Instead, focus on what I thought this group was chartered to do -- the simplest possible common representation of what's already out there, working. The "others" be damned.
-- "Cloud architectures are complex with many differs t extensions having to contribute to answers. JSON does not lend itself to this kind of thing so it's actually (a lot) more work for implementors"
That sounds, to this "enterprise voice", like a feature, not a bug. Constraints are good. I like constraints. You have not yet convinced me that the "extensions" you refer to here are critical to the core of the aforementioned simplest possible common representation of what's already out there, working. Instead, the impression I get is that these extensions (or even the possibility of having them) serves primarily the "play nice with others" (non) goal. Since I don't think worrying about playing nice with others is a good idea, imposing a contstraint that makes it harder to do seems like a good idea to me. Helps focus on the core goal -- distractions fall away. In my experience, that's a design approach that, in turn, produces *very* robust artefacts -- ones on which it is subsequently relatively easy to build more stuff (to play with other, for example). Doing things the other way round (trying to anticipate and account for possible "extensions"), in my experience, too often leads to fragile, brittle designs.
This argument, OTOH:
-- "Agreed but that was before we had an almost complete spec, a rough reference implementation complete with mechanical transforms to the requested formats and the start of a HTML interface for good measure. For JSON we have nothing"
... is quite compelling, and in my view. And that may outweigh all other concerns, given the desire to hold the date. Dunno.
Mark Masterson Enterprise architect, troublemaker CSC
Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss Masterson | Public blog: Process Perfection (http://jroller.com/MasterMark/) | mmasterson@csc.com | www.csc.com.
CSC • This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered in England No: 0963578 _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg