Difference between revisions of "2008 Summer Project Week:XNATandXCEDE"

From NAMIC Wiki
Jump to: navigation, search
 
(5 intermediate revisions by 3 users not shown)
Line 45: Line 45:
  
 
</div>
 
</div>
 +
 +
===Detailed Project Goals===
 +
* The XCEDE REST service shall implement the full XCEDE capabilities as a stand-alone application
 +
** When connected to a data service such as XNAT, it's functionality will replace the stand-alone app's, e.g. XCEDE will pass data query requests through to XNAT or perhaps to a DICOM QR provider.
 +
* Users, Roles and Permissions will be incorporated through the [http://www.jsecurity.org/ JSecurity] library.  While user authentication will not be added in the first release, the scaffolding will be in place and authentication may be added where required.
 +
* Interaction with the REST interface will not require a sophisticated client.
 +
** "curl" or "wget" will be sufficient.
 +
** Most languages have some form of HTTP libraries, making them suitable client platforms.
 +
* Deployment
 +
** The REST service will be deployed as a .war file.  Many servlet engines immediately handle .war applications.
 +
** The REST service may be deployed as part of an XNAT instance.  It may allow fast-path access to XNAT queries.
 +
 +
=== REST interface ===
 +
[http://en.wikipedia.org/wiki/Representational_State_Transfer REST] is a simple idea: expose all your resources as URI's.  The URI's are nouns, with 4 basic verbs that act on them.
 +
 +
{| border="1" cellpadding="5"
 +
|-style="background:#ebeced; color:black" align="left"
 +
! HTTP Method
 +
! CRUD concept
 +
! Usage
 +
|-
 +
| PUT
 +
| Create
 +
| Create a new instances of a resource.  In some cases, the user can choose the URI, e.g. http://www.example.org/XCEDE/project/MyFancyProject, in other cases, the REST service chooses the URI, e.g. http://www.example.org/XCEDE/project which will create http://www.example.org/XCEDE/project/1 (then /2, /3, etc).
 +
|-
 +
| GET
 +
| Read
 +
| Fetch a representation of the resource.  This will be XCEDE by default, generic [http://xstream.codehaus.org/ XStream] XML, and JSON provided as debug information.
 +
|-
 +
| POST
 +
| Update
 +
| POST can be thought of as '''append'''.  If POST'ing to an existing URI, update the representation with the POST'ed data, returning the new representation.
 +
|-
 +
| DELETE
 +
| Delete
 +
| Obviously deletes a resource, if the user has privileges.
 +
|}
 +
 +
===References===
 +
 +
* Sample grails-based excee interface: http://boggs.bwh.harvard.edu:8080/XCEDE/
 +
* Grails: http://www.grails.org
 +
* XCEDE: http://www.xcede.org
 +
* XNAT: http://www.xnat.org
 +
* [http://slicer.spl.harvard.edu/slicerWiki/index.php/Slicer3:XCEDE_use_cases#XCEDE_REST_Interface XCEDE use cases]

Latest revision as of 14:30, 24 June 2008

Home < 2008 Summer Project Week:XNATandXCEDE
Return to Project Week Main Page



Key Investigators

  • Dan M.
  • Dan B.
  • Julien
  • Steve
  • Wendy


Objectives

Improve Slicer's informatics support and its integration with XNAT Tools; Design XCEDE Web Services using several Slicer3 use scenarios as drivers.

Approach, Plan

  • Work with existing Grails-based REST interface to XCEDE
  • Evaluate use cases for Slicer3
  • Work on design of XCEDE web services API to support these.

Progress

A straw man REST interface to XCEDE has been implemented using Grails (Groovy on Rails). Grails is a rapid application development environment patterned after Rails (Ruby on Rails). Grails, however, is completely Java-based utilizing industry standard components (Spring, Hibernate, Groovy). In addition, Grails supports many of the common AJAX frameworks and can be compiled and deployed as a .war file.

A server has been set up on slicerl using code in the NAMICSandbox. Two interfaces are available, a human-friendly web site and a machine-friendly REST interface. The command line program curl can interact with the REST interface, and is useful for learning and debugging.


Detailed Project Goals

  • The XCEDE REST service shall implement the full XCEDE capabilities as a stand-alone application
    • When connected to a data service such as XNAT, it's functionality will replace the stand-alone app's, e.g. XCEDE will pass data query requests through to XNAT or perhaps to a DICOM QR provider.
  • Users, Roles and Permissions will be incorporated through the JSecurity library. While user authentication will not be added in the first release, the scaffolding will be in place and authentication may be added where required.
  • Interaction with the REST interface will not require a sophisticated client.
    • "curl" or "wget" will be sufficient.
    • Most languages have some form of HTTP libraries, making them suitable client platforms.
  • Deployment
    • The REST service will be deployed as a .war file. Many servlet engines immediately handle .war applications.
    • The REST service may be deployed as part of an XNAT instance. It may allow fast-path access to XNAT queries.

REST interface

REST is a simple idea: expose all your resources as URI's. The URI's are nouns, with 4 basic verbs that act on them.

HTTP Method CRUD concept Usage
PUT Create Create a new instances of a resource. In some cases, the user can choose the URI, e.g. http://www.example.org/XCEDE/project/MyFancyProject, in other cases, the REST service chooses the URI, e.g. http://www.example.org/XCEDE/project which will create http://www.example.org/XCEDE/project/1 (then /2, /3, etc).
GET Read Fetch a representation of the resource. This will be XCEDE by default, generic XStream XML, and JSON provided as debug information.
POST Update POST can be thought of as append. If POST'ing to an existing URI, update the representation with the POST'ed data, returning the new representation.
DELETE Delete Obviously deletes a resource, if the user has privileges.

References

Retrieved from "https://www.na-mic.org/w/index.php?title=2008_Summer_Project_Week:XNATandXCEDE&oldid=27433"