The hypermedia version of orderService, described in Chap. 5, with order, payment and receipt resources is available as the orderDap project. (DAP for domain application protocol, see pg. 112). Copy code from it as needed, but (for option A) be sure to drop the Link and RestbucksUri dependencies. Note that we will use a slightly different URI scheme. For Option B, just use orderDap as the server, without changing it.
Option A. Server-side REST Programming with Jersey. Add a payments and receipts to orderService, to make it follow Fig. 4-1 and more exactly, Fig. 5-9, which shows the additional resources involved. The orders go through states UNPAID, PREPARING, READY, and TAKEN. For this option A, we won’t use the hypermedia approach however.
or
Option B. Client-side Programming for a hypermedia service. Alternatively, if you would like to experiment with the hypermedia approach, write a client of orderDap that uses the hypermedia links to guide the user through the ordering process, always using a URI from a link after the first order is sent. This is an interactive client program, but keep it simple, that is, just use line-oriented input and output with the user.
New services over those in orderService, for Option A:
· POST /order/{orderId}/payment to pay for this order, receipt is returned, with URI /order/{orderId}/receipt
· GET /order/{orderId}/receipt
· DELETE /order/{orderId}/receipt to finish
As in orderDap, receipts and payments have POJOs in representation, but receipts have no domain object, since their information is derived from Payment information. As in orderDap, we need only two repositories, for Orders and Payments.
For Option A, start from orderService and expand it as follows:
1. Add new OrderStatus values: add UNPAID as the initial state, and TAKEN as the final state, as in orderDap. Search the sources (including the tests) for uses of the old values and make sure they are fixed up properly to fit the new system.
2. Copy the Payment repository from orderDap for long-term storage of Payments.
3. Add new simple wget tests to build.xml to test POSTing a payment (target restPay), GETing a receipt.(target get-receipt)
4. Add new payment and receipt resources (preferably as subresources) and their XML messages and corresponding schema and JAXB POJOs. There are two ways to design these: add the POJOS and use them to create the schema, or create the schema and use it to generate the POJOs. Use the namespace as in orderService. Create new activity classes for their code. Note points 5 and 6: it’s recommended to add tests first, then code for them.
5. Port the following unit tests from orderDap: PaymentActivityTest and ReadReceiptActivityTest
6. Port the following methods from orderDap’s EndToEndTest into orderService’s EndToEndTest and get them working: shouldBeAbleToPlaceAndPayForAnOrderOnceOnly, shouldBeAbleToOrderPayAndGetReceiptThenWaitForOrderCompletion (using poke()), and shouldNotBeAbleToCancelPaidOrder.
7. Make sure you can generate schema, preferably by getting Jersey to provide it via the WADL file, else by “ant gen-schema-from-pojos”
Start from orderService, don't change existent files in the repository, domain, representation, or activities packages, except for values of order status, if possible.
For Option B, start from TakeOrder1 (yours or from the pa3 solution), port it to orderDap (this should be easy) as TakeOrder2. Replace the command line arguments by prompted user input. Assume that the user wants to make an order when they run the program and thus get the order options from the served schema without prompting. Display the order options and let the user choose what they want, then compose the order and send it to the server.
Now we need a loop of the form:
· interpret the response
· show the user the possible next actions from the links
· additionally allow quit
· do the chosen action
Try to make this code as generic as possible. Ideally you would have only one such loop, with lookups to resolve data that is not directly available from the links themselves, such as the needed HTTP verb or the format of the needed XML. To get an order ready, we can use “ant restPoke” in a separate process.
Files for Grading:
Top-level
directory: pa4, either option:
README: partnerships, notes for grading.
memo.txt: provide a guide to your sources with one sentence descriptions
of any new or changed source files, listed by packages.
Option A: a server project
Java
Sources: use the package structure of orderService, with new files
build.xml
for compiling/deploying code, etc., as in orderService, plus targets restPay
and get-receipt
resources: PaymentResource, ReceiptResource
repositories: PaymentRepository, from orderDap
representations: PaymentRepresentation, ReceiptRepresentation
domain: Payment, (OrderStatus has new values)
activities: PaymentActivity, ReadReceiptActivity, CompleteOrderActivity, any
exceptions for them
Option B: a client project
Note that TakeOrder will need to interact with the user, offering choices derived from the hypermedia links, so we can’t expect to run it well under ant.
Java Sources: same package structure
as pa3, but under pa4/src
Expected Packages, like pa3
build.xml: at
least targets build, clean, restAdd
cs639.ordering.client: TakeOrder2 as top level again, other classes as needed
cs639.ordering.representations: POJOs annotated by JAXB (only if you use JAXB)