[glue-wg] JSON rendering

[Shiraz Memon]

On Thu, Oct 4, 2012 at 7:35 PM, Warren Smith <wsmith at tacc.utexas.edu> wrote:

>  ** **
>
> Could you point me to your slides from the last OGF?
>

here is a link to the slides:
http://redmine.ogf.org/dmsf_files/145?download=

and an example JSON document:
http://eu-emi.github.com/emiregistry/documentation/registry-1.2.0/emir-manual.html#appendixi

It is obvious that the JSON documents therein does not reflect glue
structure at all, however the entity names and attributes. We have also
introduced a couple of extra attributes, such as, "expire_on" - where
publisher can specify TTL value of that particular document - or _id though
uninteresting for the user, assigned by the document database.


> ****
>
> ** **
>
> I’d like to be able to have multiple entities in each JSON document for
> easier publishing. I may require it depending on how we represent
> associations - there are a couple places where XSEDE wants
> ComputingActivities in queue order.****
>
> ** **
>
> I think a good goal would be to allow JSON documents to have many GLUE2
> entities in them, or just one entity.
>
I’m using 3 documents right now (single computing activity, multiple
> computing activities, and everything else), but I may split the larger
> documents up when storing them in a document-oriented database. I **think**
> the example documents I sent could be split this way without a problem.***
> *
>
> ** **
>
> One issue I had was how to identify a particular JSON object as a specific
> GLUE2 entity. To do this I did:****
>
> ** **
>
> “GLUE2 Entity Name”: {****
>
>     attributes****
>
> }
>
****
>
> ** **
>
> If there can be at most 1 entity of that type (e.g. ComputingService). If
> there can be multiple entities (e.g. ComputingShare) I did:****
>
> ** **
>
> “GLUE2 Entity Name”: [****
>
>    {****
>
>      attributes****
>
>   },****
>
>    {****
>
>      attributes****
>
>   },****
>
> ]****
>
> ** **
>
> even if a particular document only had 1 of these entities. I did this so
> that it was a bit easier to process the document.
>

mapping the entities as you've mentioned above was my first thought while
designing the json template, however due to the requirements we shrank and
packed the entities into a single level objects (i.e. service and endpoint
at the same level).

We have to see whether the aforesaid approach - which seems to be quite
natural - is feasible for us. It would be very helpful if you have any
example showing "Service" and "Endpoint" entities.

Thanks,
Shiraz

 **
>
> Oh, I just noticed that the ResourceID and SiteID members shouldn’t really
> be in the documents I sent. They are some legacy metadata and aren’t glue2
> and I probably don’t need them, anyway.****
>
> ** **
>
> ** **
>
> Warren****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Shiraz Memon [mailto:a.memon at fz-juelich.de]
> *Sent:* Thursday, October 04, 2012 4:25 AM
> *To:* Warren Smith; OGF GLUE WG
> *Subject:* Re: [glue-wg] JSON rendering****
>
> ** **
>
> Hi Warren,****
>
>
>
> I think there was at least one other project that created their own JSON
> rendering. Is mine in the same ballpark as yours? ****
>
>  ** **
>
> Not exactly, the way we use is bit more "flattened" where each attribute
> is prepended with the owning entity/class name and an underscore; e.g.
> Endpoint_ID. Since the scope within EMIR is limited to address the
> endpoints only, therefore we didn't care about other glue 2 entities. To
> get more insight, have a look into my slides from last OGF[1]. ****
>
>  ****
>
> Are there folks interested in defining an official JSON rendering?****
>
>  ** **
>
> Yes, having JSON rendering for glue 2 would be more than nice to have for
> non-XML based services. If possible, I would recommend to have a slot in
> GLUE session at ogf 36 to kick-start this activity. ****
>
> ** **
>
> I had a short glimpse over your documents, and got slightly concerned
> about representing all the entities (while considering the glue 2 spec.) in
> a single json document for the future standard rendering, thus going to
> make it very complex and prone to validation errors. Wouldn't that be
> simplified if for every (or at least major) glue entity/class to be defined
> in a separate JSON document. This surely won't hamper the developers from
> using the merged documents.****
>
> ** **
>
> [1] http://redmine.ogf.org/dmsf_files/145?download=****
>
> ** **
>
> Cheers,
> Shiraz****
>
>   ****
>
>
>
> Warren
>
>
>
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg****
>
>
>
> ****
>
> ** **
>
> --
> Ahmed Shiraz Memon ****
>
> Federated Systems and Data
> Jülich Supercomputing Centre (JSC)
>
> Phone: +49 2461 61 6899
> Fax:     +49 2461 61 6656****
>
>
>
>
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
>
> Kennen Sie schon unsere app? http://www.fz-juelich.de/app****
>



-- 
Ahmed Shiraz Memon
Federated Systems and Data
Jülich Supercomputing Centre (JSC)

Phone: +49 2461 61 6899
Fax:     +49 2461 61 6656
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20121005/62a3a895/attachment-0001.html>