[occi-wg] Simple JSON rendering for OCCI -deployment configurations

[Sam Johnston]

Interesting diagram, does seem to cover most of the common cases.

Sam

On Thu, May 14, 2009 at 9:13 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:

> Alexis mentioned the ascii art failed, sorry...
>
> here is a pdf
>
> -gary
>
>
>
> It sound like there is a consensus here to agree to disagree. Having
> said that tongue in cheek, I'd have a few configurations issues I'd like
> to propose as it pertains to rendering.
>
> I've put it fixed font if it looks odd, change the font to a fixed version
>
> The drawings are simple 2 node systems. The systems represent
> integration points. You'll notice there are 2 interconnects between the
> systems. A rendered format and a logical model. I discriminate between
> the two, because, I believe they are two separate issues in terms of
> interoperability.
>
> I'm looking for consensus that these are the 4 simple models we will
> most likely encounter in deployments.
>
> -gary
>
> 1) OCCI Native Configuration
>
> ------------------       Native OCCI      ------------------
> |                |          Format        |                |
> |   System A     |<---------------------->|   System B     |
> |                |                        |                |
> ------------------                        ------------------
>  System A Model <========================> System B Model
>
>
> ----------------------------------------------------------------------------------------------------------------
> 2) OCCI Adapter Configuration
>
> ---------------------------------------
> ------------------       Native OCCI      |-----------
> ------------ |
> |                |          Format        || OCCI    |<----------->|
> System B | |
> |   System A     |<---------------------->|| Adapter |   Foreign   |
> (Foreign)| |
> |                |                        |-----------    Format
> ------------ |
> ------------------
> |                                     |
>
> --------------------------------------
>  System A Model <========================> System B Foreign Model
>                     Model Transform
>
>
> ----------------------------------------------------------------------------------------------------------------
> 3) Foreign Adapter Configuration
>
> ---------------------------------------
> ------------------       Native Foreign   |-----------
> ------------ |
> |                |          Format        || Foreign |<----------->|
> System B | |
> |   System A     |<---------------------->|| Adapter |     OCCI    |
> (OCCI)  | |
> |   (Foreign)    |                        |-----------    Format
> ------------ |
> ------------------
> |                                     |
>
> --------------------------------------
> System A Foreign Model <=================> System B OCCI Model
>                        Model Transform
>
>
> ----------------------------------------------------------------------------------------------------------------
> 4) Gateway Configuration
>
> ------------------    Native Foreign   -----------------     Native
> OCCI     ------------------
> |                |       Format        |               |
> Format       |                |
> |   System A     |<------------------->| OCCI Gateway
> |<------------------->|    System B    |
> |   (Foreign)    |                     |               |
>    |     (OCCI)     |
> ------------------                     -----------------
>   ------------------
> System A Foreign Model
> <===================================================> System B OCCI Model
>                                      Model Transform
>
>
> ----------------------------------------------------------------------------------------------------------------
>
> Sam Johnston wrote:
>
>> On Tue, May 12, 2009 at 10:23 PM, Tim Bray <Tim.Bray at sun.com <mailto:
>> Tim.Bray at sun.com>> wrote:
>>
>>        For JSON it's a lot less clear (at least for the famous
>>        enterprise users) due to the support, copyright, patent, etc.
>>        status surrounding third-party implementations. I know at
>>        least some of my clients have policies that would require
>>        developers to write the parser themselves - granted not a
>>        particularly difficult task but an unnecessary and error prone
>>        one.
>>
>>
>>    We must live in different worlds.  The Java programmers I know are
>>    like "Yeah, JSON, whatever", and for .NET,
>>    http://www.google.com/search?q=json%20.net turns up lots of stuff
>>    including from Microsoft's own Codeplex.  Javascript/Python/Ruby,
>>    no problem.  PHP I have no first-hand info, but since half the
>>    Ajax-heavy sites in the planet are PHP-backed, I can't imagine
>>    it's an issue.   -T
>>
>>
>> Perhaps we do [live in different worlds]. Where I come from people would
>> rather have silent phones <
>> http://blogs.gartner.com/lydia_leong/2009/05/11/the-perils-of-defaults/>
>> than risk changing a default setting. Opaque binaries and their updates pass
>> without question while third-party/open source implementations are held up
>> for months in convoluted approval processes (if not flat out banned).
>> "Simplicity" translates to "Complexity" (so does "Complexity" for that
>> matter).
>>
>> One of the reasons I'm pushing the point is because I'd actually like to
>> be permitted to use the fruits of our labour.
>>
>> Sam
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090514/7eff4824/attachment.html