Re: [oslc-core] Delegate UI use cases - Chained dialogs (wizards) and returning resource representations

[Ian Green1 <ian.green@uk.ibm.com>]

Hi Martin
I see, this makes sense.  What
I didn't understand on first reading is that the postmessage representation
is in fact not required to be authoritative - in fact, it does not even
exist as a resource in the authority of the provider. So the only thing
a consumer should do with such a representation is use it to POST to a
creation factory?

Do you expect that content negotiation
would be required over api so that the observer can choose a resource format
that it knows how to handle?

An alternative design is for the provider
to have a "template" resource which can be instantiated by the
consumer.  This might  have advantages one of which is that existing
content-negotiation just works.  But it does seem a lot like hard
work for providers that don't have such a template facility already, or
otherwise don't want/need additional capabilities.

How would a user (or any REST client)
understand the specified configuration for a given test definition?  You
indicated that the consumer won't understand all the configuration parameters.
 In the template design , a rich hover on the template resource (which
would be linked from the test definition) would explain this.  If
the user wanted more details, they could navigate to the template and take
a look.  A rest client would do a GET on the template resource. In
the postmessage design, the consumer would have to figure out some UI to
present to its user (or did I miss something?) and it might not be able
to do a good job of this, and/or, might lead to unfortunate coupling between
the provider and the consumer.  (The fact that there could be such
coupling doesn't mean that the postmessage api is not valuable, btw.  I'm
just thinking out loud.)

Thanks for explaining this.

best wishes,
    -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational

<oslc-core@lists.oasis-open.org> wrote on 10/03/2014
14:48:30:

> From: Martin P Pain/UK/IBM@IBMGB
> To: Ian Green1/UK/IBM@IBMGB, oslc-core@lists.oasis-open.org
> Date: 10/03/2014 14:48
> Subject: Re: [oslc-core] Delegate UI use cases
- Chained dialogs 
> (wizards) and returning resource representations
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> Hi Ian, 
> 
> Yes, that is a correct understanding of my proposed use case. 
> 
> This is for cases where you want a representation for a resource 
> that is to be created at a later time, perhaps multiple times. That
> is, where you need to configure it while a user is present, but not
> create the resource on the provider until a later schedule or 
> trigger occurs (possibly multiple times) while the user is not present.
> 
> I will outline the sort of scenario that motivated this. 
> 
> Actors: The User (human) who interacts with a Test Management System
> (OSLC Consumer) that consumes the services of a Deployment Manager
> (OSLC Provider). 
> 
> As the User, I want the Deployment Manager ("Provider")
to deploy 
> the system under test ("SUT") and dependencies whenever
an 
> automated/unattended (CI) test on the Test Management System 
> ("Consumer") is about to be executed, in order for the test
to have 
> a unique copy of the SUT and dependencies to avoid contention on 
> these resources from tests running in parallel. 
> 
> Stage 1: attended by the User 
> 1. The Provider exposes the capability of automated deployment for
a
> particular type of resource. 
> 2. The User navigates to (or creates) an automated test definition
> on the Consumer. 
> 3. The User gestures to configure a deployment plan to link to the
> test definition. 
> 4. The Consumer displays an Automation Plan selection dialog from
> the Provider. 
> 5. The User selects the deployment plan that they wish to be linked.
> 6. The Consumer displays a dialog from the Provider, for the User
to
> configure that deployment for that test definition. (This may 
> include provider-specific fields that the consumer does not understand).
> 7. The User enters their configuration. 
> 8. The User defines a schedule or trigger for the test definition
> (e.g. as part of a Continuous Integration test suite which runs 
> whenever a build completes). 
> 9. The User saves the test definition 
> 
> Stage 2: unattended, executed on a trigger or schedule 
> 10. The trigger or schedule occurs, and the Consumer gets ready to
> execute the test definition. 
> 11. The Consumer instructs the Provider to run the deployment plan
> selected by the User, with the configuration they provided. 
> 12. The Provider deploys the required resources. 
> 13. The Consumer runs the tests. 
> 14. Teardown, etc, once the tests have finished 
> 
> (I have deliberately avoided technical details relating to the use
> case in question from the scenario to encourage alternative 
> solutions to be considered). 
> 
> If we supported the proposed use case, then this could be 
> implemented as follows: 
> Step 6 could be a dialog that creates a representation of an 
> AutomationRequest resource, but only returns that representation via
> postMessage, and does not persist it on the Provider. 
> The Consumer could then store this representation, and then POST it
> to an AutomationRequest creation factory (or equivalent in 3.0) when
> it needs the resource to be created, as many times as it needs it
to
> be created. 
> 
> So, in short, this is useful when: 
> 1. A resource needs to be configured in a dialog by a user 
> and 
> 2. The resource should not be created until later when the user is
> not present, or the multiple resources need to be created from that
> configuration at different times. 
> 
> It allows the User to configure the resource via a dialog, but puts
> the Consumer in charge of when it is created, not the Provider. 
> 
> It would be possible to use a standard Creation Dialog, and then 
> DELETE the resource from the Provider (or use a creation dialog that
> specifies somehow that its resources are short-lived and will be 
> garbage collected every so often), but as the intention was not to
> create the resource on the Provider at all (and this may have side-
> effects) it would be cleaner if the representation could be returned
> directly to the Consumer without ever creating a persisted resource
> on the Provider.
> 
> 
> I hope this demonstrates where I was coming from. 
> If you have any more questions, or any suggestions as to better 
> solutions, I'd be happy to hear them.
> 
> Martin Pain
> Software Developer - Green Hat
> Rational Test Virtualization Server, Rational Test Control Panel
> Open Services for Lifecycle Collaboration - Automation WG joint chair

> 
> E-mail: martinpain@uk.ibm.com
> Find me on: [image removed]  and within IBM on: [image removed]
  
> 
> [image removed] 
> 
> 
> 
> 
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
3AU 
> 
> 
> 
> From:        Ian Green1/UK/IBM 
> To:        Martin P Pain/UK/IBM@IBMGB, 
> Cc:        Arnaud Le Hors <lehors@us.ibm.com>,
oslc-core@lists.oasis-open.org
> Date:        10/03/2014 13:51 
> Subject:        Re: [oslc-core] Delegate UI use
cases - Chained 
> dialogs (wizards) and returning resource representations 
> 
> 
> Hi Martin 
> re postMessage offering a representation. 
> 
> As I understand it, you are proposing that the observer of the 
> delegated UI will receive (via postmessage) a representation of the
> newly created resource, rather than getting the URI and having to
do a GET. 
> 
> Such a proposal raises for me lots of questions because http 
> protocol is being "bypassed".  Can you motivate when
it would be 
> necessary/desirable for the client to use such a feature? 
> 
> best wishes,
>    -ian
> 
> ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
> IBM Rational 
> 
> <oslc-core@lists.oasis-open.org> wrote on 05/03/2014 11:01:27:
> 
> > From: Martin P Pain/UK/IBM@IBMGB 
> > To: Arnaud Le Hors <lehors@us.ibm.com> 
> > Cc: oslc-core@lists.oasis-open.org 
> > Date: 05/03/2014 11:01 
> > Subject: [oslc-core] Delegate UI use cases - Chained dialogs
> > (wizards) and returning resource representations 
> > Sent by: <oslc-core@lists.oasis-open.org> 
> > 
> > I've submitted two delegated UI use cases to the wiki page [1]:
> > 
> > * (mp) Chaining of dialogs (creating wizards from dialogs). 
> > Scenario: In OSLC Automation, a user might want to use a selection
> > dialog to select an AutomationPlan, then be presented with an
> > AutomationRequest creation dialog for that plan (or AutomationResult
> > selection dialog, if appropriate). (One solution would be to
> > encourage providers to include selection of those prior resources
in
> > their later selection dialogs, but allowing composition on the
> > client side allows more flexibility). 
> > 
> > * (mp) Should we allow creation dialogs to return an entire resource
> > representation through the postMessage result (oslc:result)?
e.g. 
> > this could be used by OSLC Automation 2.1 deferred-execution
> > creation dialog - currently in draft. (If so, we might also want
to 
> > consider moving this result value to be JSON-LD). 
> > 
> > 
> > [1] https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases
> > 
> > Martin 
> > 
> > 
> > <oslc-core@lists.oasis-open.org> wrote on 04/03/2014 22:31:16:
> > 
> > > From: Arnaud Le Hors <lehors@us.ibm.com> 
> > > To: oslc-core@lists.oasis-open.org, 
> > > Date: 04/03/2014 22:31 
> > > Subject: [oslc-core] Agenda for 6 March 2014 
> > > Sent by: <oslc-core@lists.oasis-open.org> 
> > > 
> > > Hi, 
> > > 
> > > The agenda for Thursday's call is now available: 
> > > https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.06
> > > 
> > > Please, note the new call-in info. 
> > > 
> > > Steve Speicher created a new document to capture the use
cases and 
> > > requirements for delegated UI. Please, add your own use
cases and 
> > > requirements as well as those for the Development and evolution
of 
> > > vocabularies which we already started. 
> > > 
> > > We'll discuss these this week. 
> > > 
> > > Best regards.
> > > --
> > > Arnaud  Le Hors - Software Standards Architect - IBM
Software Group
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales
with 
> > number 741598. 
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU