[CITE-Forum] [REST.SC] [CITE.SC] Resource Oriented Architecture (was: Re: Dec 14th Client Testing Webinar)

Pat Cappelaere pat at cappelaere.com
Wed Dec 15 10:47:49 EST 2010


John & al,

I certainly understand the need for automated testing.  This is something that the Web Community has really done well.
There are many tools out there to do just that.  That's why I am asking.
You can even write testable requirements as user stories (Behavior Driven Development / Stories)
Once defined, these run automatically every time a file is changed in the system.

here is an example:
http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/

Pat.

On Dec 15, 2010, at 10:15 AM, John Herring wrote:

> Pat,
>  
> The problem is in two parts, both of which may be simple, but to both of which we must come to some sort of agreement.
>  
> 1.    How do you state testable requirements on a RESTful application in an OGC implementation standard?
> 2.    Once those requirements are clear, how do we build an automated testing system that verifies those requirements are met, so that OGC can grant certified conformance to the implementations of those standards?
>  
> It may be quite easy to describe how those requirements might be tested by a person; the question at hand is how do we automate and instrument those tests.
>  
> Regards,
> John
>  
> There is inherent danger in being the second lemming in a parade.
>  
> The opinions expressed in this email are purely my own and do not necessarily
> represent the opinions of any organization or otherwise sane person or persons.
>  
> John R. Herring
> Architect, Spatial Products
> Oracle Corporation
> One Oracle Drive
> Nashua, New Hampshire 03062
> ph: +1 (603) 897 3216
> fx:  +1 (603) 897 3334
>  
> Annue cœptis - Novus Ordo Seclorum
>  
>  
>  
> -----Original Message-----
> From: Pat Cappelaere [mailto:pat at cappelaere.com] 
> Sent: Wednesday, December 15, 2010 9:56 AM
> To: John Herring
> Cc: 'Arnulf Christl'; architecture.dwg at lists.opengeospatial.org; rest.sc at lists.opengeospatial.org; cite-forum at lists.opengeospatial.org; cite.sc at lists.opengeospatial.org
> Subject: Re: [REST.SC] [CITE.SC] Resource Oriented Architecture (was: Re: Dec 14th Client Testing Webinar)
>  
> John,
> Where do you think the problem is?
> I have no problem testing my RESTful service.
> From the service document, I can find the published collections and end-points and follow the urls from there.
> Regards,
> Pat.
>  
> On Dec 15, 2010, at 9:49 AM, John Herring wrote:
>  
> > I think we may need a little input from the REST.sc on this puppy. If we are going to write
> > implementation standards using REST mechanisms, we need to know how we want to test
> > implementations of those standards.
> >
> > BTW, I understand why there are no "servers" as the resources and representations play that
> > role, but are there not still "clients" in the sense that something has to be able to navigate
> > through the RESTful representation graph, possibly a user, a piece of intelligent software or a
> > web crawler?
> >
> > Regards,
> > John
> >
> > There is inherent danger in being the second lemming in a parade.
> >
> > The opinions expressed in this email are purely my own and do not necessarily
> > represent the opinions of any organization or otherwise sane person or persons.
> >
> > John R. Herring
> > Architect, Spatial Products
> > Oracle Corporation
> > One Oracle Drive
> > Nashua, New Hampshire 03062
> > ph: +1 (603) 897 3216
> > fx:  +1 (603) 897 3334
> >
> > Annue cœptis - Novus Ordo Seclorum
> >  
> >
> > -----Original Message-----
> > From: cite.sc-bounces+john.herring=oracle.com at lists.opengeospatial.org
> > [mailto:cite.sc-bounces+john.herring=oracle.com at lists.opengeospatial.org] On Behalf Of Arnulf
> > Christl
> > Sent: Wednesday, December 15, 2010 7:40 AM
> > To: architecture.dwg at lists.opengeospatial.org
> > Cc: cite-forum at lists.opengeospatial.org; cite.sc at lists.opengeospatial.org
> > Subject: [CITE.SC] Resource Oriented Architecture (was: Re: Dec 14th Client Testing Webinar)
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Just some thoughts that came to me after John asked a question about how
> > to test RESTful clients.
> >
> > Looking at this problem from an architectural point of view (instead of
> > from a "RESTful software" perspective) the resources are the inportant
> > entities and there are no clients and no servers but only resources and
> > representations. In the ideal Resource Oriented Architecture the state
> > of an "application" is transferred with each request as part of the
> > resource's representation. This would mean that a (WMS) map that is
> > returned from a server would simply include a FeatureInfo request "hint"
> > encoded as a URL - if the service supports querying. The client can use
> > this "hint" to offer this feature to the user (if the client implements
> > querying). The user clicks on the map (pixel coordinates) which are
> > added to the request including the real world coordinates of the map
> > image (which always need to be delivered together with the response map
> > from the service - er - the resource state).
> >
> > The rest is unchanged standard WMS processing, take the local pixel
> > coordinates + real world coordinates, calculate click position, query
> > the data, send the representation of whatever was found back to the client.
> >
> > The important bit in the whole story is that the client does not need
> > any a priori knowledge of the service to be able to query it - and can
> > thus not really create "wrong" queries. IUt is being told what it can do
> > anytime it can do it. In real life we would all expect some intelligence
> > in the client, if only for convenience. But the interesting bit is that
> > the test is done way before implmenting any software, it is more like
> > test driven standard development (if that term did not exist then it was
> > just invented).
> >
> > If we go back to unloved Richardson's and Ruby's RestFUL Web Services
> > book they have a simple recipe how to design RESTful services. It
> > involves 4 steps:
> >
> > 1. Identify the resources and accordingly define the URIs
> > 2. Deciding the data format for each resource (representations of the
> > resource).
> > 3. Methods supported at each URI (~which of the 4 HTTP CRUD operations
> > are supported for each resource).
> > 4. Deciding the response and status code to be returned to the client.
> >
> > And in more detail -
> > 1. Figure out the data set.
> > 2. Split the data set into resource.
> > For each kind of resource -
> > 3. Name the resource with URIs
> > 4. Expose a subset of the uniform interface
> > 5. Design the representation(s) accepted from the client
> > 6. Design the representation(s) served to the client
> > 7. Integrate the resource into existing resources, using hypermedia
> > links and forms
> > 8. Consider the typical course of events: event flow
> > 9. Handle the error conditions (an example error could be an Update to a
> > resource that does not exist yet).
> >
> > Step 9 sort of polishes the process off and immediately takes care of
> > testing. This all happens before we implement any software. For us this
> > could mean that we standardize the process of designing a resource and
> > responses instead of designing interface standards, letting them loose
> > on developers and afterwards ask ourselves how we could test what we
> > invented.
> >
> > Talking about "Testing RESTful APIs of OGC service" (which have not been
> > designed to be RESTful at all) waters down the clear resource oriented
> > principles quite a bit. They seem to suggest that the request to a
> > resource could be in a way "wrong" - which is probably a "wrong"
> > interpretation of the whole REST idea.
> >
> > Is this only brain damaged nit picking or does it make any sense?
> >
> > Have fun,
> > Arnulf.
> >
> > Luis Bermudez wrote:
> >> All,
> >>
> >> We had a fantastic session today with about 10 participants. where Chuck Morris from Northrop
> > Grumman presented a client testing capability. The  steps presented were as follows:
> >>
> >> - Following a similar procedure as for a server testing, a new session was started
> >> - A WMS test suite was selected: OGC WMS client  1.3.0
> >> - A form appeared
> >> - A get Capabilities URL for an existing server was provided: A WMS service from a local
> > degree installation.
> >> - A proxy URL was then provided by TEAMEngine to be invoked by the client
> >> - A client (Gaia) was opened
> >> - The client was given the proxy URL
> >> - Several operations were triggered from the user interface in the client (zoom ,etc..)
> >> - TEAMEngine reported on the validity of the request perform by the client.
> >>
> >> From the discussion:
> >> - Need a set of operations for a client to be tested.
> >> - If the client doesn't performed all the expected operations then the report should say so.
> >> - The report should also tell about operations that the client performed but that were not
> > tested.
> >> - Need to do a comprehensive revision to make sure that the current WMS 1.3.0 client CTL tests
> > take into account all the WMS 1.3.0 client-related requirements.
> >> - This client testing will be merged to the main code and the test will be available soon in
> > the beta web site.
> >>
> >> The recording is available here:
> >>
> > https://opengeospatial.webex.com/opengeospatial/ldr.php?AT=pb&SP=MC&rID=19707657&rKey=cf1de92d2f
> > 5f2017
> >>
> >> The last 10 minutes of the recording has a discussion about details of the source code, which
> > may or may not be of interest to some folks.
> >>
> >> Cheers !
> >>
> >> Luis
> >> -------------
> >> Luis Bermudez
> >> lbermudez at opengeospatial.org 
> >> +1 (301) 760-7323
> >>
> >> The OGC: Making Location Count...
> >> http://www.opengeospatial.org/contact
> >>
> >>
> >>
> >>
> >> On Dec 14, 2010, at 9:52 AM, Luis Bermudez wrote:
> >>
> >>> All,
> >>>
> >>> This is a reminder that we are going to have a CITE Client Testing meeting at 10:00 am,
> > Eastern Standard Time (New York, GMT-05:00)
> >>>
> >>>
> > https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&RT=MiM
> > xMQ%3D%3D
> >>>
> >>> meeting password: Cite2010
> >>>
> >>> +1 512 225 3050 passcode:36429#
> >>>
> >>>
> >>> Luis
> >>> -------------
> >>> Luis Bermudez
> >>> lbermudez at opengeospatial.org 
> >>> +1 (301) 760-7323
> >>>
> >>> The OGC: Making Location Count...
> >>> http://www.opengeospatial.org/contact
> >>>
> >>>
> >>>
> >>> On Dec 9, 2010, at 1:50 PM, Luis Bermudez wrote:
> >>>
> >>>> All,
> >>>>
> >>>> On Dec 14th we are going to have a webinar at 10 AM eastern time to show case and discuss
> > the latest work related to Client testing done by Chuck Morris from Northrop Grumman. Enclosed
> > is the meeting information. I invite you all interested on this topic to participate.
> >>>>
> >>>> Topic: Client Testing
> >>>> Date: Tuesday, December 14, 2010
> >>>> Time: 10:00 am, Eastern Standard Time (New York, GMT-05:00)
> >>>> Meeting Number: 797 435 997
> >>>> Meeting Password: Cite2010
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> To join the online meeting (Now from mobile devices!)
> >>>> -------------------------------------------------------
> >>>> 1. Go to
> > https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&RT=MiM
> > xMQ%3D%3D
> >>>> 2. If requested, enter your name and email address.
> >>>> 3. If a password is required, enter the meeting password: Cite2010
> >>>> 4. Click "Join".
> >>>>
> >>>> To view in other time zones or languages, please click the link:
> >>>>
> > https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&ORT=Mi
> > MxMQ%3D%3D
> >>>>
> >>>> -------------------------------------------------------
> >>>> To join the audio conference only
> >>>> -------------------------------------------------------
> >>>> +1 512 225 3050 passcode:36429#
> >>>>
> >>>> -------------------------------------------------------
> >>>> For assistance
> >>>> -------------------------------------------------------
> >>>> 1. Go to https://opengeospatial.webex.com/opengeospatial/mc
> >>>> 2. On the left navigation bar, click "Support".
> >>>>
> >>>> You can contact me at:
> >>>> lbermudez at opengeospatial.org
> >>>>
> >>>>
> >>>> To add this meeting to your calendar program (for example Microsoft Outlook), click this
> > link:
> >>>>
> > https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&ICS=MI&LD=1&RD=2&ST=1&S
> > HA2=d8QzvwbABa3sWVcIU1FluaZBcGcGHlsshXRzPqSTnC8=&RT=MiMxMQ%3D%3D
> >>>>
> >>>> The playback of UCF (Universal Communications Format) rich media files requires appropriate
> > players. To view this type of rich media files in the meeting, please check whether you have the
> > players installed on your computer by going to
> > https://opengeospatial.webex.com/opengeospatial/systemdiagnosis.php
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> http://www.webex.com
> >>>>
> >>>>
> >>>>
> >>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents
> > and other materials exchanged or viewed during the session to be recorded. By joining this
> > session, you automatically consent to such recordings. If you do not consent to the recording,
> > discuss your concerns with the meeting host prior to the start of the recording or do not join
> > the session. Please note that any such recordings may be subject to discovery in the event of
> > litigation.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Luis
> >>>> -------------
> >>>> Luis Bermudez
> >>>> lbermudez at opengeospatial.org 
> >>>> +1 (301) 760-7323
> >>>>
> >>>> The OGC: Making Location Count...
> >>>> http://www.opengeospatial.org/contact
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> CITE.SC mailing list
> >>>> CITE.SC at lists.opengeospatial.org
> >>>> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
> >>> _______________________________________________
> >>> CITE.SC mailing list
> >>> CITE.SC at lists.opengeospatial.org
> >>> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
> >>
> >>
> >>
> >> _______________________________________________
> >> CITE.SC mailing list
> >> CITE.SC at lists.opengeospatial.org
> >> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
> >
> >
> > - --
> > Nothing makes sense, except we make it.
> > http://www.metaspatial.net
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iEYEARECAAYFAk0Itw4ACgkQXmFKW+BJ1b0sYgCfVxkjkUuwz6ew/5AZ2s7BUgzv
> > JJcAn1IfRgaovhT7CSPavu1PQt9sMLuW
> > =XF4x
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > CITE.SC mailing list
> > CITE.SC at lists.opengeospatial.org
> > https://lists.opengeospatial.org/mailman/listinfo/cite.sc
> >
> > _______________________________________________
> > REST.SC mailing list
> > REST.SC at lists.opengeospatial.org
> > https://lists.opengeospatial.org/mailman/listinfo/rest.sc
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20101215/dde004a4/attachment-0001.htm>


More information about the CITE-Forum mailing list