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


Simeon,

Comments interleaved 

> -----Original Message-----
> From: Simeon Greene [mailto:simeon.m.greene@oracle.com] 
> Sent: 28 May 2004 15:39
> To: Furniss, Peter
> Cc: ws-caf-implement@lists.oasis-open.org
> 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/ms
> g00023.html).  I'll be sure to ask Malik to update the wsdl 
> on the website.

the that link seems to have:
        <wsdl:operation name="addItemToCart">
            <soap:operation soapAction="" style="rpc"/>
            <wsdl:input>
                <soap:body use="literal"
namespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/
2002-08/Retailer.wsdl"/>               
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"
namespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/
2002-08/Retailer.wsdl"/>
                <soap:header use="literal" part="content"
message="tns:ContextMessage"/>
            </wsdl:output>
        </wsdl:operation>

with context in the output not the input


> > 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.

that would be good - though possibly extra work for you.

> > 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.

I meant I wasn't sure what the name of the ws-context element was at the
moment. On looking at the text again,
 I believe is "type". 

You'll just need a URI to define the use you are making of ws-context.

> > 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.

yes, but the fact that it is the value for the xsd:any is stated only in
text. I would expect to see a piece of schema defining that we had a
type derived from base ws-context and containing shoppingCart in place
of the xsd:any (and fixing the type uri ?). 

> > 
> > 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.

I think pass-by-reference ends up with a completely different
application - it alters the implied store:customer contract from "I have
added my item to your list" to "I have added your item to our list".  It
does exercise more of ws-context though.


On mountains - in this case it's a question of climbing a molehill :-)
To explain the other argument, 
perform the following substitution on the message containing the
context, and see
what would have to change in the applications. Otherwise its all the
same.

s!wsctx:context
xmlns:wsctx="http://www.webservicestransactions.org/schemas/wsctx/2003/0
3" type=!cart:context xmlns:cart=!


> > 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.

Once the stores know where each other are, what do they say to each
other ? After shopping at store red, blue and green, customer does
submitOrder to green, passing the context with items for all three.
Green can no doubt sort out what to do with its items, but what happens
with red and green ? Need some more interfaces.

One possiblity would be to say that is where ws-cf and higher will come
in, and for now it will just be assumed that all the orders are
fulfilled, so the store getting the submit (green in this case) just
creates a response assuming success.

Peter


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