Subject: Discussion on the demo application
After a silence (Hmmm let say it a “little silence”), let’s re-discuss on the demo application.
Simeon has produced some files to use in demo application. These files concern mainly the Retailer.
I have added hereafter Simeon’s comment explaining the files.
“I've stripped down
the Retailer wsdl from WS-I. I haven't changed the namespaces, but I've
removed dependencies on some other schemas and wsdls. So there are now
only 3 fiels that we need for implementing the Retailer. The
Retailer.wsdl has the operations and messages; RetailerOrder.xsd has type
definitions for product ordering and customer info; RetailCatalog.xsd has the
item definition and descriptions. So the general idea is that when you
invoke the getCatalog operation on Retailer you will get a list of CatalogItem
types. When you make a call to submitOrder on the Retailer you will send
a PartsOrderRequest (which has specifies the quantity and price of each catalog
item you wish to purchase) and then get a response that shows what you've
Let’s consider the following points:
- In the document DemoApplication_WSContext, we have defined a set of components to use for the demo application. Among these components, there is an Activity LifeCycle Service or ALS. We can define only one. When enlisted with the Context Service, it should provide the protocol-uri for this enlistement. This same protocol-uri is the one to be used by the application on context creation and control (begin, complete, …). In order to use a same protocol-uri, let’s consider this simple uri for the demo application “urn:wscafdemo:contextprotocol“
- In the same document, we have indicated that an ALS may be used to augment the context and the context can be augmented by a separate service. We need to clarify the behaviour of the ALS. According to this behaviour we could see how many ALS need to be enlisted (one per company?), when they/it need to be enlisted and with which Context Service they/it are/is enlisted?
- Concerning the shopping card that should define the context, we should agree on its content and decide on the way to propagate it (reference/value).
What we need to do now is enhancing the behaviour of the submitOrder invocation.