Project Phase 3
In this phase you will once again be working with your stores from phase two. (Try not to break your phase two project while working on phase three because I will probably still be grading them.) Big online stores like your store and Amazon.com have large selections, but they still can't reach every customer especially those who want niche products. In order to diversify, online stores form partnerships where a store like Amazon can 'sell' products for their partners and vice versa. You may 'buy' a book at Amazon.com which really came from who-knows-what.com. Amazon, of course, gets a cut of the money. Likewise, you may buy a book at flyfishing.co.au which really comes from Amazon.
To operate with each others, such stores often use XML web services. You are, in phase two, going to implement web service APIs for your stores so that you can buy and sell products from the other stores in the class. You will technically only have to be able to buy and sell with the demo store, but you need to be able to display products from all stores that successfully complete the product publishing part of the web service. In theory, if all stores can interoperate with the demo store, they should operate with each other too.
Through this phase of the project you will learn:
- How independent data applications can interact with each other
- How XML is used for publishing and transferring data
Notes: (Things your TA has learned from phases 1 and 2)
- I have previously not tied very many points in my rubric to 'on time-ness.' Several of you have noticed this and taken advantage of it. I've made sure to change that this time. Since your classmates depend on your Part A implementations for Part B, you will loose points for being late on either deadline. (See the grading criteria.) This part shouldn't be nearly as time consuming as the last one, but still start early!
- Some of you have had problems accessing ;.web services when running stuff from the lab machines. This is the fault of a permissions problem. To work around, give "Users" read/write/execute permissions on the C:/Windows/Temp directory. That’s not a very secure way to do it, I haven’t had time to figure out exactly what user it is ect ect ect. If someone knows specifically what user needs the permissions feel free to drop me (Nathan) an email.
Rules and Restrictions
- You may change your schema when importing partner data (you will have to in order to keep it separate)
- You need to ensure the consistency of data in different databases. (no breaking phase 2 please)
- Yes, Management Studio has great graphical query tools. Don't use them, write your own queries.
Tips
By tips I mean advice. If you give me the other type of tips, it will not effect your grade. =)
- Don't wait until the last minute (So cliché but true!)
- In your Web.config file, set <customErrors mode ="Off"> (instead of "Remote Only"), so when an exception is thrown it displays the details.
- Make sure you have functionality working before you start making it pretty.
Part A
Due: Friday December 3rd 2005 @ 11:59PM
Working
Example
No need for starter code this time =).
Tasks for Phase 3A are:
- "Import" data from functioning example store
- Enable your store to purchase items from example store
- Update product stock on the fly
- Publish the products in your store and a method for updating stock quantities
You will be expected to turn in:
- Your updated internet store published on IISQLSRV. (Hint: Don't publish to the server
until phase 2 grades are back!)
(I should be able to access it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/default.asmx) - Your public web API published on IISQLSRV.
(I should be able to access it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/PublicAPI.asmx) - Also include in your web root a zip archive with all your source code (.aspx / .cs)
named source3a.zip.
(I should be able to download it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/source3a.zip)
Part B
Due: Friday December 9th 2005 @ 11:59PM
Working
Example
No need for starter code this time =).
Tasks for Phase 3B are:
- "Import" data from other groups stores (links found on group page)
- Update stock quantities from other stores
- Buy your own products through the working example store
- Buy and sell products from and through eachother's stores
You will be expected to turn in:
- Your final internet store published on IISQLSRV.
(I should be able to access it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/default.asmx) - Your final public web API published on IISQLSRV.
(I should be able to access it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/PublicAPI.asmx) - Also include in your web root a zip archive with all your source code (.aspx / .cs)
named source3b.zip.
(I should be able to download it via http://iisqlsrv.cs.washington.edu/phase2/[YOUR GROUP NAME]/source3b.zip)
Details
If you ended phase 2 with inconsistent data or a not-so-functioning checkout, you might want to fix that first. This phase will share a lot of code with the parts of checkout that deal with breaking an order down into packages (your favorite piece right? mine too!) and order confirmation (that’s your other favorite piece right?).
You will be, for this phase, both consuming and producing a web service with the same signature. There are four WebMethods for this service. Please see the .NET quickstart tutorials for information on producing and consuming web services. Also, when you add a "web reference" in Visual Studio, it adds some classes to your project (expand the web reference in the object browser). I suggest checking out these files and figuring out what they do and perhaps consider how they are generated (hint: WSDL)
-
GetProducts
Signature: [WebMethod] string GetProducts(int page);
Description: This method is for publishing the products in a store. Like the data you consumed in phase 2, it is paged. Each contains ten products (unless it's the last page, then its < 10). Sending a small page instead of thousands of products at once helps relieve pressure both on the database and the network.
Returns: An xml fragment in the form of a C# string which represents a page of product. Its up to you how you parse this XML fragment, but the easiest way (hint hint) may be to insert it into a table--xml_fragment(PRIMARY KEY IDENTITY INT id, XML fragment)--in one of your databases. Then you can use XPath/XQuery to extract the data you need just like you did in phase 2B. The return should have a schema that looks like this:
<Products> <ProductCount>[int]</ProductCount> <Page>[int]</Page> <Pages>[int]</Pages> <Store>[string]</Store> <Service>[URL]</Service> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[Int64]</GTIN> <Name>[string]</Name> <Price units="hundredths-USD">[int]</Price> <Weight units="hundredths-pounds">[int]</Weight> <Author>[string]</Author>* <Publisher>[string]</Publisher> <Stock>[int]</Stock> <Detail> [Full Amazon XML Fragment (including <Item/>] v/Detail> </Product>+ </Products>
-
GetCurrentStock
Signature: [WebMethod] string GetCurrentStock(Int64 gtin);
Description: In general, we are pretending that we live in an ideal world where all stores stock the same books all the time, that no new books are published and none go out of print and that prices never change. Even in this ideal little world, we cannot ignore the fact that quantities in stock change. You don't get to know about your partner’s warehouses or their shipping contracts, but they will tell you how many they have in stock. The number that you have for the stock is usually out of date. (Someone from your partners store or another partner buys a book and all the sudden the numbers you have become wrong.) The data in your database is considered stale. In real world partnerships, businesses will often define a maximum length of time you can let data get stale before you have to update it. (The Amazon data we are using became no longer usable for commercial purposes shortly after I downloaded it.) Every time a user requests to see a product detail, add a product to a cart, update cart quantities, or check out, all the involved items should have stock amounts that are less than one hour old. That is, if the stock information is more than an hour old, use this web service call to get an up to date stock ammount, otherwise use the one you have.
Returns: An xml fragment in the form of a C# string defining the current stock of a product. The return should have a schema that looks like this:
<StockUpdate> <Store>[string]</Store> <Service>[URL]</Service> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[int]</GTIN> <Stock>[int]</Stock> </Product> <StockUpdate>
-
PackageDetails
Signature: [WebMethod] string PackageDetails(string shoppingCartXML);
Description: Since your store will have no details for warehouses or shipping contracts for your partner stores, you will need to ask your partners to build some of the packages for orders that include their products. This method does just that. You send them a list of the products your customer is buying from their store, and they send you a list of packages and a list of the shipping options for each package. This method can share a lot of code with your CheckOut.aspx.cs.
Argument: An xml fragment in the form of a C# string defining the contents of a shopping cart. This should be a list items and quantities from store B that a customer at store A is buying. The argument should have a schema that looks like this:
<ShoppingCart> <Store>[string]</Store> <Service>[URL]</Service> <DesinationZipCode>[\d\d\d\d\d]</DestinationZipCode> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[Int64]</GTIN> <Name>[string]</Name> <Quantity>[int]</Quantity> </Product>+ </ShoppingCart>
Returns: An xml fragment in the form of a C# string defining the packages a shopping cart must be broken up into and what shipping options are available for each package. The return should have a schema that looks like this:
<PackageDetails> <Store>[string]</Store> <Service>[URL]</Service> <Package> <Warehouse>[int]</Warehouse> <Items>[int]</Items> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[Int64]</GTIN> <Name>[string]</Name> <Quantity>[int]</Quantity> </Product>+ <ShippingOption> <ID>[int]</ID> <Name>[string]</Name> <Vendor>[string]</Vendor> <Price units="hundredths-USD">[int]</Price> <AgentPickup>[datetime]</AgentPickup> <EstimatedDelivery>[datetime]</EstimatedDelivery> </ShippingOption>+ </Package>+ </PackageDetails>
-
PlaceOrder
Signature: [WebMethod] bool PlaceOrder(string orderDetailsXML);
Description: This method both places and confirms an order with one of your partner stores. This method is assumed to be part of the order confirmation process. Keeping atomicity in a transaction involving web services is complicated, we will not require that. If you are interested in atomic transactions over web services, feel free to study it on your own. We are not requiring atomicity over the web services, but checkout should still be atomic regarding the ordering at individual stores. In other words, a customer may choose products from two or three of these stores. The order may fail from one store, but the transactions at the other three stores should be atomic and should still proceed. This method can share a lot of code with your CheckOut.aspx.cs. Invoices become complecated when buying from multiple stores. So much so, that I have given invoices it's own section below.
Argument: An xml fragment in the form of a C# string that defines a summary of the order being placed and the packages that it has already been broken down into. The argument should have a schema that looks like this:
<OrderDetails> <Store>[string]</Store> <Service>[URL]</Service> <BillingAddress> <ID>[int]</ID> <Name>[string]</Name> <Email>[email]</Email> <Street>[string]</Street> <City>[string]</City> <State>[\c\c]</State> <Zip>[\d\d\d\d\d]</Zip> <PlusFour>[\d\d\d\d]?</PlusFour> </BillingAddress> <ShippingAddress> <ID>[int]</ID> <Name>[string]</Name> <Email>[email]</Email> <Street>[string]</Street> <City>[string]</City> <State>[\c\c]</State> <Zip>[\d\d\d\d\d]</Zip> <PlusFour>[\d\d\d\d]?</PlusFour> </ShippingAddress> <CreditCard> <ID>[int]</ID> <Name>[string]</Name> <CardNum>[\d\d\d\d-\d\d\d\d-\d\d\d\d-\d\d\d\d]</CardNum> <Expiration> <Month>[\d\d]</Month> <Year>[\d\d\d\d]</Year> </Expiration> <CardType>[string]</CardType> </CreditCard> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[Int64]</GTIN> <Name>[string]</Name> <Quantity>[int]</Quantity> </Product>+ <Package> <Warehouse>[int]</Warehouse> <Items>[int]</Items> <ShippingMethod>[int]</ShippingMethod> <ShippingCost units="hundredths-USD">[int]</ShippingCost> <AgentPickup>[date]</AgentPickup> <EstimatedDelivery>[date]</EstimatedDelivery> <SpecialInstructions>[string]</SpecialInstructions> <Product> <Type>["Book"|"Music"]</Type> <GTIN>[Int64]</GTIN> <Name>[string]</Name> <Quantity>[int]</Quantity> </Product>+ </Package>+ </OrderDetails<
Returns: A C# boolean true or false indicating the success of the order confirmation.
Let's talk about invoices.
One big question is "what about invoices for orders that deal with multiple stores?". So, the customer isn't supposed to need to know that he or she is ordering from multiple stores, so the invoice at the store the custom purchased the goods from should reflect all items purchased at all stores and all packages sent regarding the order. (That is, packages shipped from another store will end up in both stores shipping databases.) You will not need to worry about updating package status for this project, but a real store would. There should also be invoices generated at the other stores involved. A question arises, what customer should be attached to invoices for orders that a partner store placed over a web service? It is appropriate to have a user in the database that is associated with each partner store. When partner store A places an order over the webservice, the resulting invoice is generated for partner A's user account.
Dealing with errors.
When importing errors from another store (or when buying or selling products with another store) you might come across XML that is incorectly formatted. It is up to you to contact the owners of this store and explain why their output is broken. (Be professional, these are business associates, not classmates.) Any stores that are not publishing properly at the part A deadline you will not have to import for part B.