At 3:14 PM -0400 4/30/08, Scott Cytacki wrote: >Is there documentation about the diy talking to the sds? > >Hiroki wants to know how the diy launches activities in the sds. > >Hiroki, if you curl a run link in the diy you can see what happens, but it >would be nice to have some documentation about this. >
There is scattered bits but the code is pretty easy to read. Here's a start: There are two basic parts: 1) How do SDS resource get created when the associated DIY resources are created or changed? 2) How does the DIY launch an SDS session? I think you'll want an overview of both processes but I'll start with #2 because hat was your initial question above. First take a look at the: Understanding how the OTrunk and SAIL examples are started on this page: https://confluence.concord.org/display/CSP/OTrunk+Examples It's a bit out of date but it will give you very useful background. With respect to the DIY: I recommend using curl -i from a command line to follow the redirections. So from this page: http://itsidiy.concord.org/activities Copy the run link for: 25: Temperature of mixing water (TEEMSS) into your clipboard and then in a shell take a look at what happens: curl -i http://itsidiy.concord.org/activities/25/sail_jnlp/8/1 Which will respond with a redirect like this: HTTP/1.1 302 Found Date: Wed, 30 Apr 2008 21:50:31 GMT Server: lighttpd/1.4.15 Content-Type: text/html; charset=utf-8 Location: http://saildataservice.concord.org/7/offering/946/jnlp/1207?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_filename=itsidiy_temperature_of_mixing_water_teemss_vernier_labpro.jnlp&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20(TEEMSS) X-Runtime: 0.50276 Cache-Control: no-cache Content-Length: 405 Set-Cookie: _ITSI_Do_It_Yourself_Tjc8FDLwSBbwH2OOHxJzTg____session_id=7db82b9c3764c88079a965e46a3c1d0b; path=/ <html><body>You are being <a href="http://saildataservice.concord.org/7/offering/946/jnlp/1207?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_filename=itsidiy_temperature_of_mixing_water_teemss_vernier_labpro.jnlp&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20(TEEMSS)">redirected</a>.</body></html>[~/dev]$ To keep following that redirect you'll need to wrap the url in single quotes so the shell doesn't break it up: curl -i 'http://saildataservice.concord.org/7/offering/946/jnlp/1207?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_filename=itsidiy_temperature_of_mixing_water_teemss_vernier_labpro.jnlp&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20(TEEMSS)' Which responds with a jnlp of which he important part is the argument at the end: $ curl -i 'http://saildataservice.concord.org/7/offering/946/jnlp/1207?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_filename=itsidiy_temperature_of_mixing_water_teemss_vernier_labpro.jnlp&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20(TEEMSS)' HTTP/1.1 200 OK Date: Wed, 30 Apr 2008 21:52:13 GMT Server: lighttpd/1.4.15 Content-Type: application/x-java-jnlp-file; charset=utf-8 X-Runtime: 0.21323 ETag: "e625fed16a0c1483d37a3b1fa8f9b1dc" Cache-Control: max-age=1 Content-Disposition: attachment; filename=itsidiy_temperature_of_mixing_water_teemss_vernier_labpro.jnlp Content-Length: 8994 Set-Cookie: _sds_session_id=f7cdf7b783ed0ce5b6c4e3220b8d1342; path=/ <?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="http://jnlp.concord.org/dev"> <information> <title>ITSI</title> <vendor>Created by The Concord Consortium, Inc.</vendor> <homepage href="http://itsi.concord.org/"/> <description>Make your own activities using custom probeware along with rich model-based simulations.</description> <icon href="http://itsi.concord.org/images/itsi-logo.gif" height="64" width="64"/> </information> <security> <all-permissions/> </security> <resources> <j2se version="1.5+" max-heap-size="128m" initial-heap-size="32m"/> <jar href="org/concord/algebra-objects/algebra-objects.jar" version="0.1.0-20071208.223556-20"/> <jar href="org/concord/sensor/sensor-dataharvest/sensor-dataharvest.jar" version="0.1.0-20070607.155431-8"/> ... and lots more jars ... version="2.1.7-r2"/> </resources> <application-desc main-class="net.sf.sail.emf.launch.EMFLauncher2"> <argument>http://saildataservice.concord.org/7/offering/946/config/1207/1?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20%28TEEMSS%29</argument></application-desc></jnlp> All the parameters that need to be used by the SDS for creatingthe config file are either in the url path itself OR in the parameters: curl -i 'http://saildataservice.concord.org/7/offering/946/config/1207/1?sailotrunk.otmlurl=http%3A%2F%2Fitsidiy.concord.org%2Factivities%2F25%2Fotml%2F8%2F1%2F496&jnlp_properties=otrunk.view.frame_title%3DITSI%20DIY%20-%2025%3A%20Temperature%20of%20mixing%20water%20%28TEEMSS%29' Will return the XMLencoded file with the config properties for the sail session. Now you'll see where some of those extra parameters like otrunk.view.frame_title generated in SDSRunnable end up. The sailotrunk.otmlurl property in this case points back at he DIY itself because it's the DIY which will dynamically generate the otml: http://itsidiy.concord.org/activities/25/otml/8/1/496 HTTP/1.1 200 OK Date: Wed, 30 Apr 2008 21:54:45 GMT Server: lighttpd/1.4.15 Content-Type: application/xml; charset=utf-8 X-Runtime: 0.16743 ETag: "e1031e08a8688cb38cfadac5ea585f15" Cache-Control: private, max-age=0, must-revalidate Content-Length: 2265 Set-Cookie: _sds_session_id=c14a5fab366836a41f9fb5da4007706f; path=/ <?xml version="1.0" encoding="UTF-8"?> <java class="java.beans.XMLDecoder" version="1.4.0"> <object class="net.sf.sail.core.service.impl.CurnitUrlProviderImpl"> <void property="url"> <string>http://rails.dev.concord.org/curnits/otrunk-curnit-external-diytest.jar</string> </void> </object> <object class="net.sf.sail.emf.launch.PortfolioManagerService"> <void property="portfolioUrlProvider"> <object class="net.sf.sail.emf.launch.XmlUrlStringProviderImpl"> <void property="urlString"> <string>http://saildataservice.concord.org/7/offering/946/bundle/1207/1</string> </void> </object> </void> <void property="bundlePoster"> <object class="net.sf.sail.emf.launch.BundlePoster"> <void property="postUrl"> <string>http://saildataservice.concord.org/7/offering/946/bundle/1207/1</string> </void> </object> </void> </object> <object class="net.sf.sail.core.service.impl.LauncherServiceImpl"> <void property="properties"> <object class="java.util.Properties"> <void method="setProperty"> <string>amp;jnlp_properties</string> <string>otrunk.view.frame_title=ITSI DIY - 25: Temperature of mixing water (TEEMSS)</string> </void> <void method="setProperty"> <string>sailotrunk.otmlurl</string> <string>http://itsidiy.concord.org/activities/25/otml/8/1/496</string> </void> </object> </void> </object> <object class="net.sf.sail.emf.launch.EMFSailDataStoreService2"/> <object class="net.sf.sail.core.service.impl.UserServiceImpl"> <void property="participants"> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>91612b50-095a-11dc-add0-0014c2c34555</string> </object> <string>Anonymous User</string> </object> </void> </void> <void property="userLookupService"> <object class="net.sf.sail.core.service.impl.UserLookupServiceImpl"/> </void> </object> <object class="net.sf.sail.core.service.impl.SessionLoadMonitor"/> <object class="net.sf.sail.core.service.impl.SessionManagerImpl"/> </java> DIY code review: Start at the sail_jnlp action in the Activities controller: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/app/controllers/activities_controller.rb#L226 I'm setting up a bunch of variables based on the loggeed in user and values passed in the url and ending with a redirect that in the code looks like this: redirect_to @activity.sds_url(@user, self, {:nobundles => nobundles, :reporting => false, :savedata => savedata, :authoring => authoring}) The @activity variable is an instance of the Activity class which inherits from ActiveRecord::Base. There is an Activity#sds_url method as part of that class so lets look at the class itself: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/app/models/activity.rb The sds_url method doesn't appear in the code here because it's actually in a Module called SdsRunnable, see this statement on line 5: include SdsRunnable which is mixed-in to any AciveRecord class which wants to implement this functionality: in the DIY this includes Activities, Models, ExternalOtrunkActivities, and Reports. All these classes are called Runnables. Opening lib/sds_runnable.rb: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/lib/sds_runnable.rb The first method is sds_url. This method is quite complex and is well-overdue for a refactoring but the end result is to return a jnlp_url which is used for the redirecting. Any Runnable model has to include these attributes in heir schema (AR derives the the base ORM from the schema and things added in your class layer on top): integer "sds_offering_id" string "short_name" string "uuid" This gives you a clue about #1 above -- whenever a Runnable is created an SDS Offering is created. At line 27-28: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/lib/sds_runnable.rb#L27 a DIY learner object is created unless it exists -- this is analogous to a workgroup. If you look at the schema for a learner here: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/db/schema.rb#L269 You'll see it includes a value for an sds workgroup id: t.integer "user_id" t.integer "runnable_id" t.string "runnable_type" t.integer "sds_workgroup_id" When a learner is created it relates a DIY user with a DIY activity and creates the SDS workgroup for that user in the Offering for that Activity. At this point the DIY puts all the learners for one Activity into one Offering. Line 33 starts the construction of the otml portion of the full url. The DIY supports two types of otml. Activities use otml generated by the DIY using data generated by an author using a web interface and web forms. ExternalOtrunkActivities use otml created in other systems. Line 48 encodes the value of the sailotrunk.otmlurl property and appends it to the jnlp_url being constructed. Line 51 appends a jnlp_filename property which specifies what the name of the jnlp should be when it is cached on the learners computer. Lines 53-68 setup the title of the Activity when it is instantiated in Java and setep how the frame should be displayed when the window first opens. There is some additional properties setup if the run mode is authoring or reporting. The otrunk.rest_enabled=true property set for Authoring represents some ongoing work that will allow the SAIL-OTrunk instance to save authored changes back to the DIY. This work is in process. Regarding how the DIY actually creates SDS resources when the associated DIY resources are created or changed? The communication with the SDS is based on the lib/sds_connect.rb library. You can see the code here: http://trac.cosmos.concord.org/teemss2/browser/branches/diy_rails_2.0.2/lib/sds_connect.rb There are some simplifications the DIY makes. Right now any one DIY instance assumes that all of it's activities are using just one SDS portal realm, one specific jnlp and a stub curnit. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
