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:]
> Sent: 16 April 2004 01:12
> To:
> 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
>
