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

[Martin P Pain <martinpain@uk.ibm.com>]

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:  and within IBM on:

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