First some definitions:
portal: WISE or something like it
SDS: SAIL data service (this is really a sail run/data/portal-helper service)
portaldata: data that comes from the portal, is specific to a workgroup, is needed by steps that access portal resources (like WobbleModule), and can be either delivered to a step in the plr by the sds or referenced from a step.
I'm not certain there is a good generalization so for now I am assuming that there is specific knowledge about data types shared by a portal and a step that works with resources managed by that portal. More specifically right now we are looking at data a web-rendering type step needs to access WISE steps in the WISE project associated with the PAS project.
Without understanding the WISE data model very well I am assuming that only a workgroup reference is needed for the portal to generate: userID, groupID, projectID, groupRealnames, groupUsernames. Is that correct? In the current SDS a workgroup is created for an offering and consists of a membership of 1..n users. So from any specific workgroup the SDS can generate and map the following:
Offering => projectID
workgroup => groupID,
workgroup.membership.names => groupRealnames
I have implemented a data element in the SDS generically called portal-token. I haven't been sure whether this element makes sense. I intended it to be the portal database id for the associated portal specification of the data element. So for example when a curnit is created in the sds the sds creates a curnit id and also saves a portal_token string which consist of data supplied by the portal when the sds curnit is created. This would in theory allow the portal to reference sds objects using portal ids/references. This is not implemented and in general I would prefer not to unless there is a better use case. When sds resources are created a sds object id (and REST url for accessing the resource) is passed back. I intend that the portal manage sds resources using the REST urls (or generating the url using the object type and it's id).
There is a case where I would like more portal specific information kept by the sds however and that's the case where he plr supports off-line operation. In this case the SDS should pass the information needed for a user to authenticate when not connected to the network. I hav a good design for this based on earlier work I did for the MAC project at CC however it has not been on the critical path.
BUT ... if the portal username was saved in the portal_token element of the sds user OR I extend the sds user data model to include portal-username then the sds could also hand to the plr:
workgroup.membership.portal_usernames => groupUsernames
The only item in your list that I don't think I have accounted for is userID – what is that and what is it ysed for? Is it the portal id for the user in the workgroup that actually logged in to start the session? Is this important? If so I could add this the sds definition of how to start the plr. Right now I only ask that the workgroup be specified for an offering. See this page:
http://rails.dev.concord.org/sds/1/offering/1
There are links like this on that page to run the plr
http://rails.dev.concord.org/sds/1/offering/1/jnlp/2
This starts the plr for for portal: 1, offering: 1, and workgroup: 2
Workgroup 2 consists of four users with sds user ids of 1, 2, 3, and 4. So if user 3 was logged in to start the plr I could instead require that the plr be started with this url:
http://rails.dev.concord.org/sds/1/offering/1/jnlp/2/3
Where the position of the "2" is for the workgroup, and "3" is for the logged in user.
In general this problem can be handled by either:
1) The portal creates a bundle of portaldata associated with a workgroup, passes that data to the sds when a workgroup's membership is created/changed, the sds passes that data to a plr session (or passes a reference to get the data from the sds), the plr makes it available to steps, the steps use it to access portal resources.
2) The portal creates a token for the Offering-workgroup, passes this to the sds, the portal implements a service which delivers portaldata to a step in the plr, the portal passes a reference to this service to the sds (this could be a REST url or something SOAP, etc), the step uses this reference to get the portaldata needed.
Right now the config xml delivered to the plr looks like this
http://rails.dev.concord.org/sds/1/offering/1/config/2/2
<?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://tels-develop.soe.berkeley.edu:8080/maven-jnlp//curnit-airbag.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://rails.dev.concord.org/sds/1/offering/1/bundle/2/2</string> </void> </object> </void> <void property="bundlePoster"> <object class="net.sf.sail.emf.launch.BundlePoster"> <void property="postUrl"> <string>http://rails.dev.concord.org/sds/1/offering/1/bundle/2/2</string> </void> </object> </void> </object> <object class="net.sf.sail.core.service.impl.LauncherServiceImpl"/> <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>44dabb34-2d50-11db-b8c6-0014c2c34555</string> </object> <string>Stephen Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>b291f0a4-37da-11db-af98-0014c2c34555</string> </object> <string>Grace Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>bd775798-37da-11db-af98-0014c2c34555</string> </object> <string>Rebecca Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>c9c721cc-37da-11db-af98-0014c2c34555</string> </object> <string>Eliza Bannasch</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>
There are two forms of data passed: one supplies a url reference to a service (like: net.sf.sail.emf.launch.BundlePoster), the other supplies all the data in the enclosed xml elements (net.sf.sail.core.service.impl.UserServiceImpl).
At this point the sds is not explicitly passing a reference to the workgroup but it could. If this was done and implementation #2 was done above the workgroup id could be passed to the portal service which would return all he data your new step types need.
However with small modifications (adding portal usernames to the specification of an sds-user, and adding a logged-in user sds-id to the start plr jnlp and the config file) I think I can generate all the data need for your steps types from the sds. In that case I'd suggest subsuming net.sf.sail.core.service.impl.UserServiceImpl into net.sf.sail.core.service.impl.WorkgroupServiceImpl and passing all this data in the config.
So instead of net.sf.sail.core.service.impl.UserServiceImpl perhaps the config file (and Scott's emf and Java classes) could implement net.sf.sail.core.service.impl.UserServiceImpl. Here's what it might look like in the config file in xml encoder format:
<object class="net.sf.sail.core.service.impl.WorkgroupServiceImpl"> <void property="workgroup"> <void method="add"> <object class="net.sf.sail.core.entity.Workgroup"> <object class="net.sf.sail.core.uuid.workgroupUuid"> <string>44dabb34-2d50-11db-b8c6-0014c2c34666</string> </object> <string>workgroup name</string> </object> </void> </void> <void property="logged_in_user"> <void method="add"> <object class="net.sf.sail.core.entity.LoggedInUser"> <object class="net.sf.sail.core.uuid.userUuid"> <string>b291f0a4-37da-11db-af98-0014c2c34555</string> </object> </object> </void> </void> <void property="participants"> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>44dabb34-2d50-11db-b8c6-0014c2c34555</string> </object> <string>Stephen Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>b291f0a4-37da-11db-af98-0014c2c34555</string> </object> <string>Grace Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>bd775798-37da-11db-af98-0014c2c34555</string> </object> <string>Rebecca Bannasch</string> </object> </void> <void method="add"> <object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>c9c721cc-37da-11db-af98-0014c2c34555</string> </object> <string>Eliza Bannasch</string> </object> </void> </void> <void property="userLookupService"> <object class="net.sf.sail.core.service.impl.UserLookupServiceImpl"/> </void> </object>
I'm not sure where to put (or how to specify) participant or workgroup portal-tokens or more specifically sds-user portal_usernames. The names are just passed as a generic string element. I suppose I could just specify it as follows:
<object class="net.sf.sail.core.entity.User"> <object class="net.sf.sail.core.uuid.UserUuid"> <string>c9c721cc-37da-11db-af98-0014c2c34555</string> </object> <string>Eliza Bannasch</string> <string>ebannasch</string> </object>
No the xml decoder has to know the magic information that the first string is the name and the second is the portal_username.
Anyways there are many elements of all of this that are relatively hackish but lets do the most reasonable and least damaging hack to get this working for TELS/WISE. We can improve the model when we know more.
