RE: [ws-caf-implement] Shopping Cart Context

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Simeon,

I've sent a message on the main list about the general difficulties of
ws-context, leaving some
particulars to here. It's possible I've misunderstood some stuff.

0. The overall intent and design seems useful - it seems to me more like
a department store, where one wanders around departments collecting
stuff and you can pay for the whole order at any department. There's
some dis-similarities because you are only collecting a list of
purchases, not the goods themselves, but even that's like some
old-fashioned department stores.

1. the AddItemToCart binding surely needs an optional context header in
the request - this is referenced in the text but isn't in the wsdl

2. the examples at the end of the wsdl file appear to be for the
original ws-I version, and although they illuminate that, they confuse
our case.

3. since this is a particular use of ws-context, there needs to be a
definition of the context-type uri (I'm not sure what the uri is called
at the moment)

4. shouldn't there be a definition of the shopping cart-specific
ws-context, derived from ws-context's Context, filling in the xsd:any.
It seems odd to have all this syntactic mechanism about us, and just
drop down to free text to say "put this in here".

5. I realise the purpose of the demo is to exercise ws-context, not the
application, but if the context is just passed by value, there isn't
really anything being exercised - just loading and reading a header.
Apart from generating an identifier, what is there to be done that is
general to ws-context ? Indeed, why bother with ws-context - no sorry,
that's the discussion for the main list :-)

6. Including by reference would at least cover more of the ws-context
spec, including the context manager.

7. If stores are to be independent (i.e. different implementors) there
needs to be a definition of the inter-store protocol - or perhaps this
should be the basis for the higher-level bits of ws-caf, so all this one
does is assume everything worked, and reproduce the cart contents as the
order response. 

Peter 



> -----Original Message-----
> From: Simeon Greene [mailto:simeon.m.greene@oracle.com] 
> Sent: 16 April 2004 01:12
> To: ws-caf-implement@lists.oasis-open.org
> Subject: [ws-caf-implement] Shopping Cart Context
> 
> 
> Hi,
> My apologies for taking so long to send this.  Unfortunately 
> I was temporarily reassigned to a high priority project here 
> at Oracle and will not be attending the F2F.  However, per 
> our last meeting I had an action item to describe the 
> contents of the shopping cart and how they are to be 
> propagated in the Context.
> 
> First, a quick overview of the demo system:
> 
> Each ws-ctx implementation participating in the demo is known 
> as a store.  All stores participating in the demo are aware 
> of each others location (i.e. the location of all the 
> webservice endpoints).  How this awareness is achieved is not 
> my concern for now... it can be static or dynamic (for 
> example WS-I Sample Apps uses a uddi registry).  Each store 
> must have a unique id known as the store id (we'll need this 
> for referencing and mapping stores).  A user can browse any 
> of the stores for a catalog of items.  He adds items to his 
> cart from as many stores as he desires and then checks out 
> from any store.
> 
> Details:
> A context is started once a user issues the addToCart 
> operation for the first time.  Here is the addToCart 
> operation (this has been added to the
> Retailer.wsdl):
> 
> <wsdl:operation name="addItemToCart">
>             <wsdl:input message="tns:addItemToCartRequest"
> name="additemToCartRequest"/>
>             <wsdl:output message="tns:addItemToCartResponse"
> name="addItemToCartResponse"/>
>         </wsdl:operation>
> 
> The outbound message also contains the Context in the header 
> (this is done in the wsdl binding, not shown).  addItemToCart 
> contains the Item to add to the cart.  If the input message 
> contains a context in the header, then the item will be added 
> to the <xsd:any> element of that context.  This can be done 
> by an ALS or by the context itself.  Here is the propose xml 
> structure for the <xsd:any> in the demo's context.  This 
> structure can be known as the cart:
> 
> <xsd:complexType name="shoppingCart">
> 	    <xsd:sequence>
> 	        <xsd:element name="item" 
> type="tns:PartsOrderItem" minOccurs="0" maxOccurs="unbounded"/>
> 	    </xsd:sequence>
> 	</xsd:complexType>
> 
> Note that only the items need to be stored in this element, 
> the context identifier and timeout etc are stored in the 
> context itself.  I've added this new structure to 
> PartsOrder.xsd (attached).  
> Note that store id's are encoded in the PartsOrderItem (this 
> is also a new addition):
> 
> <xsd:complexType name="PartsOrderItem">
> 		<xsd:sequence>
> 			<xsd:element name="productNumber" 
> type="tns:productNumber" minOccurs="1" maxOccurs="1"/>
> 			<xsd:element name="quantity" 
> type="xsd:nonNegativeInteger" minOccurs="1" maxOccurs="1"/>
> 			<xsd:element name="price"    
> type="xsd:decimal" minOccurs="1"
> maxOccurs="1"/>
> 			<xsd:element name="storeId" 
> type="xsd:string" minOccurs="1" maxOccurs="1"/>
> 		</xsd:sequence>
> 	</xsd:complexType>
> 
> This storeId can be used at checkout time.  At checkout time 
> the user app will issue a submitOrder.  Here is the 
> submitOrder operation:
> 
> <wsdl:operation name="submitOrder">
>             <wsdl:documentation>Accept an order for 
> quantities of multiple products</wsdl:documentation>
>             <wsdl:input message="tns:submitOrderRequest" 
> name="submitOrderRequest"/>
>             <wsdl:output message="tns:submitOrderResponse" 
> name="submitOrderResponse"/>
>             <wsdl:fault name="BadOrder" message="tns:BadOrderFault"/>
>             <wsdl:fault name="InvalidProductCode" 
> message="tns:InvalidProductCodeFault"/>
>         </wsdl:operation>  
> 
> The submitOrderRequest must contain the Context in the header. 
> Carefully read the attached Retailer wsdl because I've 
> changed this operation considerably.  The response should 
> return a Context in the header and also a list of orders that 
> can be viewed as a receipt.  Here is this structure (two types):
> 
> <xsd:complexType name="PartsOrderResponseType">
> 		<xsd:sequence>
> 			<xsd:element name="Item" 
> type="tns:PartsOrderResponseItem" maxOccurs="unbounded"/>
> 		</xsd:sequence>
> 	</xsd:complexType>
> 	<xsd:complexType name="PartsOrderResponseItem">
> 		<xsd:sequence>
> 			<xsd:element name="productNumber" 
> type="tns:productNumber" minOccurs="1" maxOccurs="1"/>
> 			<xsd:element name="quantity" 
> type="xsd:nonNegativeInteger" minOccurs="1" maxOccurs="1"/>
> 			<xsd:element name="price"    
> type="xsd:decimal" minOccurs="1"
> maxOccurs="1"/>
> 			<xsd:element name="comment"  
> type="xsd:string" minOccurs="0" maxOccurs="1"/>
> 			<xsd:element name="storeId" 
> type="xsd:string" minOccurs="1" maxOccurs="1"/>
> 		</xsd:sequence>
> 	</xsd:complexType> 
> 
> Note that each of these response items has the storeId which 
> is used to track the store where the item was purchased.  
> Also note, this structure may resemble the same structure for 
> request, but they are very different.  For example, quantity 
> in the response, means quantity that can be fulfilled not 
> quantity requested.  For the context demo I think we should 
> ignore this... I believe it will come in handy once we start 
> to demo the transactional parts of ws-caf.
> 
> I have attached all the wsdls and schemas with these types.  
> I believe this will generate a lot of questions and 
> discussions... looking forward to it.  Overall I hope you 
> find this email helpful.
> 
> Cheers,
> Simeon
>