[wsia] Update on Customization Committee

[Eilon Reshef <eilon.reshef@webcollage.com>]

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?