Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

2011-06-24 Thread Alan Garny
Hi,

Having just read the minutes, I was wondering whether you guys could clarify
the situation with regards to web service support for PMR2? Tommy said that
REST support is iffy and that's also what I understood from the email he
sent around earlier this week. However, the minutes read that the general
upshot is that REST is likely to be the technology of choice...?! I can't
see the rationale here. So, would it be possible to have some explanations?
Also, in Tommy's email, he mentioned JSON (in addition to SOAP and REST).
So, what about JSON?

Cheers, Alan.

 -Original Message-
 From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
 boun...@cellml.org] On Behalf Of Tommy Yu
 Sent: 24 June 2011 06:49
 To: CellML Discussion Group
 Subject: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011
 
 Greetings,
 
 The minutes of the Auckland Bioengineering Institute CellML meeting of
22nd
 June 2011 can now be found at:
 
 http://www.cellml.org/community/meeting/minutes/2011/06.22
 
 Kind Regards,
 Tommy.
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://lists.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

2011-06-24 Thread Tommy Yu

Alan Garny wrote:

Hi,

Having just read the minutes, I was wondering whether you guys could clarify
the situation with regards to web service support for PMR2? Tommy said that
REST support is iffy and that's also what I understood from the email he
sent around earlier this week. However, the minutes read that the general
upshot is that REST is likely to be the technology of choice...?! I can't
see the rationale here. So, would it be possible to have some explanations?
Also, in Tommy's email, he mentioned JSON (in addition to SOAP and REST).
So, what about JSON?



Hi Alan,

REST support is iffy is in relation to standards/libraries that provide/support 
within the standard Zope/Plone environment.  What this means is I will have to 
implement anything that isn't there natively.  However, REST really is a 
methodology for transferring of states, and in PMR2's case there isn't really 
that much to add.

As for how these states are transfered, there are many ways to do so, either 
via XML, JSON or other formats.  Since JSON is the preferred encoding method 
for values this is why we tentatively decide to do so.  JSON and REST are two 
complete independent entities and are completely different types of concepts 
that gets used together a lot.

SOAP on the other hand is a design-by-committee standard that ends up being 
excessively verbose for what we are trying to do, which is to provide a 
lightweight method to retrieve values from PMR2.  I did start off doing this in 
SOAP with a library that the Zope community provided.  It was easy to get going 
because SOAP is an established standard, but under the hood it was anything but 
simple.  This is the request body to get the title of an object generated by 
the SOAPpy library:

?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
 SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
 xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
 xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;



SOAP-ENV:Body
get_title SOAP-ENC:root=1
/get_title
/SOAP-ENV:Body
/SOAP-ENV:Envelope

This is the response by the Zope SOAP library I added:

SOAP-ENV:Envelope
   xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; 
   xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;

   xmlns:ZSI=http://www.zolera.com/schemas/ZSI/;
   xmlns:xsd=http://www.w3.org/2001/XMLSchema;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 SOAP-ENV:Header
 /SOAP-ENV:Header
 SOAP-ENV:Body
   get_titleResponse
   SOAP-ENC:arrayType=xsd:anyType[1] xsi:type=SOAP-ENC:Array
 element id=ob2d7f20 xsi:type=xsd:stringWorkspaces/element
   /get_titleResponse
 /SOAP-ENV:Body
/SOAP-ENV:Envelope

Whereas with JSON it's more of a simple standard HTTP GET to a specific URL 
(which we will have to define) and response body would look something like

{
 title: Workspace
}

An order of magnitude of reduction in bytes.

A response for a list of workspace with its URL looks something like this per 
entry:

{
...
Per Pixel Lighting: http://localhost:8380/pmr/workspace/per_pixel_lighting;,
...
}

Rather than this

SOAP-ENV:Envelope ...
...
Eoceb8bec
 Eoced4c60 id=oced4c60 xsi:type=xsd:string
   Per Pixel Lighting
 /Eoced4c60
 Eocedc260 id=ocedc260 xsi:type=xsd:string
   http://localhost:8380/pmr/workspace/per_pixel_lighting
 /Eocedc260
/Eoceb8bec
...
/SOAP-ENV:Envelope

For JSON, all you need is to use a standard JSON library, load the string, and 
you have the values you need.  Ditto for SOAP, but the transport body is just 
excessively verbose - added bytes for no added benefits in our case.

To submit changes in the REST protocol I plan to implement for PMR2, you should 
be able to construct a standard POST request to one of our standard forms and 
things will be done.  While some people would argue we should allow users to 
PUT stuff, we don't actually support that with our current web front-end anyway 
because PMR2 generates the content (i.e. exposures and their associated 
pages/views) based on commands user sends via standard http POST forms.

If you want to know more as to why REST is displacing SOAP, search 'REST vs. 
SOAP' in your favorite search engine - evidence for why is too numerous to list 
here.

Okay, I will try anyway:

Popularity between REST and SOAP
http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/

Google deprecated SOAP API two years ago (their encoding is in atom and json):
http://googlecode.blogspot.com/2009/03/introducing-labs-for-google-code.html

BioModels are moving to a REST API, not sure what their encoding will be but I 
heard it will be json.

So yeah, these are the justifications.

Regards,
Tommy.


Cheers, Alan.


-Original Message-
From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
boun...@cellml.org] On Behalf Of Tommy Yu
Sent: 24 June 2011 06:49
To: CellML Discussion Group
Subject: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

Greetings,

The minutes of the Auckland Bioengineering

Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

2011-06-24 Thread Alan Garny
  Having just read the minutes, I was wondering whether you guys could
  clarify the situation with regards to web service support for PMR2?
  Tommy said that REST support is iffy and that's also what I
  understood from the email he sent around earlier this week. However,
  the minutes read that the general upshot is that REST is likely to be
  the technology of choice...?! I can't see the rationale here. So, would
it be
 possible to have some explanations?
  Also, in Tommy's email, he mentioned JSON (in addition to SOAP and
REST).
  So, what about JSON?
 
 REST support is iffy is in relation to standards/libraries that
provide/support
 within the standard Zope/Plone environment.  What this means is I will
have
 to implement anything that isn't there natively.  However, REST really is
a
 methodology for transferring of states, and in PMR2's case there isn't
really
 that much to add.
 
 As for how these states are transfered, there are many ways to do so,
either
 via XML, JSON or other formats.  Since JSON is the preferred encoding
 method for values this is why we tentatively decide to do so.  JSON and
REST
 are two complete independent entities and are completely different types
of
 concepts that gets used together a lot.
 
 SOAP on the other hand is a design-by-committee standard that ends up
 being excessively verbose for what we are trying to do, which is to
provide a
 lightweight method to retrieve values from PMR2.  I did start off doing
this in
 SOAP with a library that the Zope community provided.  It was easy to get
 going because SOAP is an established standard, but under the hood it was
 anything but simple.  This is the request body to get the title of an
object
 generated by the SOAPpy library:
 
 ?xml version=1.0 encoding=UTF-8?
 SOAP-ENV:Envelope
   SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
   xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
   xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
 
 SOAP-ENV:Body
 get_title SOAP-ENC:root=1
 /get_title
 /SOAP-ENV:Body
 /SOAP-ENV:Envelope
 
 This is the response by the Zope SOAP library I added:
 
 SOAP-ENV:Envelope
 xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
 xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:ZSI=http://www.zolera.com/schemas/ZSI/;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   SOAP-ENV:Header
   /SOAP-ENV:Header
   SOAP-ENV:Body
 get_titleResponse
 SOAP-ENC:arrayType=xsd:anyType[1] xsi:type=SOAP-ENC:Array
   element id=ob2d7f20 xsi:type=xsd:stringWorkspaces/element
 /get_titleResponse
   /SOAP-ENV:Body
 /SOAP-ENV:Envelope
 
 Whereas with JSON it's more of a simple standard HTTP GET to a specific
 URL (which we will have to define) and response body would look something
 like
 
 {
   title: Workspace
 }
 
 An order of magnitude of reduction in bytes.
 
 A response for a list of workspace with its URL looks something like this
per
 entry:
 
 {
 ...
 Per Pixel Lighting:
 http://localhost:8380/pmr/workspace/per_pixel_lighting;,
 ...
 }
 
 Rather than this
 
 SOAP-ENV:Envelope ...
 ...
 Eoceb8bec
   Eoced4c60 id=oced4c60 xsi:type=xsd:string
 Per Pixel Lighting
   /Eoced4c60
   Eocedc260 id=ocedc260 xsi:type=xsd:string
 http://localhost:8380/pmr/workspace/per_pixel_lighting
   /Eocedc260
 /Eoceb8bec
 ...
 /SOAP-ENV:Envelope
 
 For JSON, all you need is to use a standard JSON library, load the string,
and
 you have the values you need.  Ditto for SOAP, but the transport body is
just
 excessively verbose - added bytes for no added benefits in our case.
 
 To submit changes in the REST protocol I plan to implement for PMR2, you
 should be able to construct a standard POST request to one of our standard
 forms and things will be done.  While some people would argue we should
 allow users to PUT stuff, we don't actually support that with our current
web
 front-end anyway because PMR2 generates the content (i.e. exposures and
 their associated pages/views) based on commands user sends via standard
 http POST forms.
 
 If you want to know more as to why REST is displacing SOAP, search 'REST
vs.
 SOAP' in your favorite search engine - evidence for why is too numerous to
 list here.
 
 Okay, I will try anyway:
 
 Popularity between REST and SOAP
 http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/
 
 Google deprecated SOAP API two years ago (their encoding is in atom and
 json):
 http://googlecode.blogspot.com/2009/03/introducing-labs-for-google-
 code.html
 
 BioModels are moving to a REST API, not sure what their encoding will be
but
 I heard it will be json.
 
 So yeah, these are the justifications.

Thanks a lot, Tommy. I am clearly not a web service expert and therefore
assumed that the choice was between SOAP, REST and JSON. From what I now
understand (which may still not be right!), it would seem that the choice is
between SOAP and REST while regarding JSON it 

[cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

2011-06-23 Thread Tommy Yu

Greetings,

The minutes of the Auckland Bioengineering Institute CellML meeting of 22nd 
June 2011 can now be found at:

http://www.cellml.org/community/meeting/minutes/2011/06.22

Kind Regards,
Tommy. 
___

cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion