OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-implement message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Peter,
Thanks very much for your comments.  See my replies inline:
On Wed, 2004-05-26 at 07:38, Furniss, Peter wrote:
> 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
Yes... It actually has already been added to the wsdl.  You're probably
looking at the Retailer.wsdl on the website.  This wsdl is outdated and
I sent an update in my email on April 15th
(http://www.oasis-open.org/archives/ws-caf-implement/200404/msg00023.html).  I'll be sure to ask Malik to update the wsdl on the website.
> 
> 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.
We should remove those examples... I agree.  Either that or perhaps I
could alter them so that they are more appropriate to our example.
> 
> 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)
We'll need to define something.  It isn't called anything 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".
See the new RetailOrder.xsd (not the one on the website) from my prior
email to this group.  It has a new complex type called shoppingCart. 
This is the type that get's propagated in the xsd:any of the context.
> 
> 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 :-)
I think the decision to only demonstrate pass by value was made as a
last ditch attempt to get the demo ready for the New Orleans f2f with a
minimum amount of functionality.  Now that that's behind us, I agree
with you that pass-by-reference will be a more interesting exercise.  It
would give us more spec coverage.  So I'd like to see that added to the
demo myself.  Perhaps Malik would like to chime in on this.
As for "why bother with ws-context"... where not going to climb Mt.
Everest here ;-)  However, if you'd like, propose an alternative to
ws-context for the demo and I'll at least read it ;-)  Keep in mind
though that you'd also need to come up with a new name.
> 
> 6. Including by reference would at least cover more of the ws-context
> spec, including the context manager.
agreed.
> 
> 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. 
I need more info here.  What do you mean by inter-store protocol?  I
think we'll need a way for stores to identify/discover each other.  The
WS-I Sample App WG used UDDI for this.  Perhaps we could use this or
some sort of home grown registry.
> 
> 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
> > 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]