MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] Update on Customization Committee
Title: Message
Hi
All,
Attached
are two documents that we discussed in the recent Customization sub-committee,
regarding data customization and "exit points".
Eilon
Attachment:
Customization 20020605.pdf
Description: Adobe PDF document
Title: Message
From: Eilon Reshef [
eilon.reshef@webcollage.com]
Sent:
Wednesday, June 05, 2002 12:08 PM
To: 'Timothy Jones'; 'Charles F
Wiecha'; 'Eilon Reshef'; 'Peter Quintas'; 'Ravi Konuru'; 'Roston Sellman';
'Shankar Ramaswamy'; 'Stefan Beck'; 'Terry Cline'
Subject: Resent:
"Exit Points"
Hi
All,
Per last
week's discussion, here are a few thoughts on the exit
points.
Tim: I did
not put them in the Word document, to avoid versioning issues, so feel free to
place it in the right location in the larger document if
applicable.
Technical
Requirement 1:
The
Consumer must know that the Producer is "done" and must be able to get back
completion information.
Technical Requirement 2:
The need
for multiple "exit points" from a single service. This was illustrated in the
memory configurator example, where a single exit point was "Add to Cart" and
another exit point was "Product Information". In both cases, the Consumer needs
to know the product ID, but they represent different semantics for completion of
the interaction with the user.
Technical
Requirement 3:
The need
for pre-processing of the action by the Producer before determining if the
Producer is done. A good example is the Dell configurator, in which many
configurations may not make sense, and even when you hit the "submit" button,
Dell still has to check the configuration for validity before providing the
completed configuration information to the Consumer.
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