[glue-wg] JSON rendering

Fri Oct 5 09:03:28 EDT 2012

I don't have a need for any Service or Endpoint objects right this minute, so I don't have examples. I've got ComputingService and ComputingEndpoint in the glue2_pbs_public.json file that I sent earlier, though. I'd expect to do Service and Endpoint the same way, but with a subset of the attributes.

Warren

From: Shiraz Memon [mailto:a.memon at fz-juelich.de]
Sent: Friday, October 05, 2012 4:58 AM
To: Warren Smith
Cc: OGF GLUE WG
Subject: Re: [glue-wg] JSON rendering

On Thu, Oct 4, 2012 at 7:35 PM, Warren Smith <wsmith at tacc.utexas.edu<mailto: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<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<mailto: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<tel:%2B49%202461%2061%206899>
Fax:     +49 2461 61 6656<tel:%2B49%202461%2061%206656>

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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/f20222dd/attachment-0001.html>