Optional
Technical Requirement 4: (Do we want to pose this as a requirement, or are
we comfortable with deferring it - it hasn't come up as a real scenario, and
seems to be a "nice to have" that may indicate a good model, but not a real
requirement)
The
Consumer should be able to re-activate the same transient instance of the
Producer at a later stage.
Optional
Technical Requirement 5: (Do we want to pose this as a requirement, or are
we comfortable with deferring it - it hasn't come up as a real scenario, and
seems to be a "nice to have" that may indicate a good model, but not a real
requirement)
The
Producer should be able to have "optional" exit scenarios, which the Consumer
may decide to handle or not handle. If the Consumer doesn't handle the exit
scenario, the user continues to navigate through the
Producer.
Suggested Model:
The user
clicks on the "Add to Cart" button.
The
Consumer receives an opaque action.
The
Consumer calls performAction (still not knowing
what the action is like, as in TR-3 above).
The
Consumer receives back a notification saying that the Producer is done and also
the semantics of the exit (as in TR-4 above) (see below A).
The
Consumer requests back the information and handles it (see below
B).
Optional
Implementation Models for (A):
A1. The Consumer receives back a SOAP exception that indicates that
the Producer is done.
A2. The Consumer receives back a return value explicit in the API
that indicates termination, and semantics of termination.
A3. The Consumer looks at a pre-defined property to see whether
termination has occurred.
A4. The Consumer calls another API to determine whether the Producer
is done. (Ouch!)
- Any
others?
Optional
Implementation Models for (B):
B1. The Consumer has also received back a property value from the
Producer during the performAction
call
B2. The Consumer requests a property value from the Producer using a
getProperties invocation
B3. The Consumer calls an out-of-band operation (with a separate
signature) to get back the information
- Any
others?
(Note that
piggybacking on the property mechanism presents a tradeoff: simplicity - no
need for a new mechanism, versus clarity - the proliferation of properties that
are declared globally but used locally)
Assuming
(arbitrarily chosen) A3 and B1, the scenario is as follows:
1. The user
clicks on the "Add to Cart" button.
2. The
Consumer receives an opaque action.
3. The
Consumer calls performAction with an opaque action and data.
4. The
Consumer receives back two property values (or possibly more). One is a
pre-defined property called, say, exitState, and
the other is a custom property called, say, productConfiguration.
5. The
Consumer looks at the exitState propertyValue and determines that the value is,
say, productSelectedForCart.
6. The Consumer looks at the
value for productConfiguration, which is a
completely custom schema set up by the memory configuration
vendor.
7. The Consumer adds the
configuration to its shopping cart and forgets about the Producer. (Does this
mean the the Producer transient instance is dead? Probably
not.)
Thoughts, ideas,
comments?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC