[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 []
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?