CS 634 - class 21st of March

CS 639 - class 17

Return midterms

Note hw3 is available, due Mon, Apr. 11

Also Resources on class web page now has JUnit4, REST links

How many have used JUnit?

XML Design

In problem 1 of the midterm, you designed XML to describe a checking account where

An account has owners and a group of checks/

This containment hierarchy is easily turned into XML. The main difference between solutions was whether or not to have elements for <checks> as well as <check>. That can go either way.

A harder case involves cases where we would use inheritance in Java classes modeling the data.

Let’s look at some classic examples of this kind of modeling of a “generalization hierarchy”.

A shape is a circle or a rectangle

\ radius \length \width

Here the relevant attributes (using “attribute” in a generic way here, not meaning XML attributes) are completely different for the two cases, and to associate length and width with a rectangle, we should have (in our element-centric way)

</rectangle>

so shape can be

<shape>

</rectangle>

</shape>

<shape>

</circle>

</shape>

In a DTD, we have that a shape has content model (circle|rectangle)

Or if we have sets of them, <shapes> could be rectangles, then circles

(rectangle*, circle*)

While circle has (radius) and rectangle has (length, width)

In XML Schema, we haven’t used <xsd: choice>, but that can do the same content model for us. Works like <xsd:sequence>. See end of pg. 93 of Harold for example of use.

An employee is a man or a woman. In this case both the man and the woman have the same attributes: name, address, ssn, hireDate, etc. Here we can change ISA to HASA easily. A man IS-A person converts to a person HAS-A gender. The man vs. woman can be recorded as an simple attribute, gender, so

Employee has content model (name, address, ssn, gender, hireDate, …)

A vehicle is a car or truck, where a car has vin (vehicle id number) color, owner, and trunkSpace, and truck has color, owner, and height. In OO modeling, we use a base class vehicle with subclasses car and truck, but database modeling and ordinary XML schemas do not have such a special treatment applicable to this case. By ordinary XML schemas I mean what is used in Harold, i.e., what we’re covering.

In fact full XML Schema has a way to extend a base element complex type to another type. If interested, see the XML Primer for:

· an element type “Address” with name, street, and city child elements

· an element type USAddress with additional “state” and “zip” elements (using <extension base=”ipo:Address”>...</extension>)

· an element type UKAddress with additional “postcode” and “exportCode” elements

But note that using this construct puts you into advanced schemas, so I would tend to avoid it.

We want to stick with ordinary, Harold-approved, XML Schemas, so we need to think of design without inheritance. That’s the situation we are in when we do database modeling. The database world of tables and foreign keys does not naturally support inheritance. It can be done awkwardly.

In DB schemas in the real world, we often stuff everything together into one vehicle table with nullable make and height, or more cleanly (normalized), have a vehicle table with vin, color, and owner, and a car table with vin and make, and a truck table with vin and height, and join vehicle and car on vin to get all the car info together, etc.

Similarly, in simple XML, we can have <vehicle> with content model (vin, color, owner, trunkSpace?, height?), or more cleanly

<vehicle> with content model (color, model, carDetail|truckDetail), and carDetail (trunkSpace) and truckDetail (height)

Like nulls in tables, we can just use “minOccurs = “0” for the schema for the <implements> element, to allow the case of no implements elements for interfaces. Sort of a kludge.

Another challenge for modeling is the N-1 relationship.

Example: we have 10,000 orders for 1000 customers, about 10 orders for each customer. A customer has several attributes, so a full listing of all orders with customer data for each is a huge document with a lot of repeated sequences.

In databases, we use the customer id as a foreign key in the orders table, referencing a single customer row in the customers table for each of the 10 orders, a much more compact setup.

We can reference from one place to another in an XML doc using id-idref or the more complicated/powerful key-keyref mechanisms. We have seen id-idref in build.xml, where the classpath is defined once with an id and used by idref in various places.

Using ID-IDREF (for example) we can mimic the database setup by this doc:

<orderdb> ßdon’t forget we always need a single root element!

<order>

</order>

<order>

…

</order>

</orders>

…

</customer>

…

</customer>

</customers>

The DTD will say that cidref is an IDREF and cid is an ID XML attribute. I rhink of this as ordinary XML, but can’t find a use in our XML text. There is a use of an ID-type attribute in Harold’s XML book, in the free schema chapter, for PersonType. I guess we have to classify it as marginally ordinary XML. Some tools may not be able to handle this, so the voluminous document with duplicate Customer elements may be safer in practice.

This is covered in by Eric van der Vlist’s book on XML Schema on XML Schema Chap 9, including the XML schema for ID/IDREF uses.

Note that if you really need to work hard with data like this, you should put it in a database. A good database can export its data in XML.

Intro to REST (Representation State Transfer)

Chap. 4 Order Service

A CRUD service:

1. Create an order

2. Retrieve the order to check status

3. Update/replace the order

4. Delete the order

Maps into HTTP verbs as shown on pg. 57

First task: write a client for this Chap 4 service, say deployed at http://sf08.cs.umb.edu:11600/orderService, with schema for messages available at

http://sf08.cs.umb.edu:11600/orderService/OrderService.xsd.

From client viewpoint: Order a coffee:

POST XML for order to http://sf06.cs.umb.edu:11600/orderService/rest/order

get back XML for order with id filled in, say order 22, status = PREPARING

This means this order’s resource is /orderService/rest/order/22.

Find out the order status:

GET to /orderService/rest/order/22, to get the current “resource” there, see same old status in the XML response

Separately, the admin sends POST to .../rest/poke: make oldest order ready.

GET to /orderService/rest/order/22, to see if it’s ready, see status=READY in the XML, time to pick it up.

Nifty way: use JAXB to turn provided schema into Java objects for client to use.

The service can also provide JSON if we want.

The idea of REST is to use HTTP directly, rather than reducing it to a carrier of SOAP messages. With REST, we use multiple HTTP verbs:

· GET for reading data (no changes allowed in server!)

· POST for creating new data items

· PUT for updating old data items

· DELETE for deleting old data items

Flip through Chap. 4 to see these actions in diagrams.

How do we specify the data item to work on?

In REST, we use individual URLs for data items, i.e. “resources”.

Chap. 4 example: pg. 57:

GET /order/1234 read order # 1234 (in XML)

POST /order add a new order (server determines new id).

(also PUT and DELETE)

How does the client find out the new id after a POST?

The HTTP Location header in the response gives this. See pg. 60 for full response: HTTP headers + XML body

Note: in the orderService project, the id is returned also in the XML for the order coming back from the POST.

So we see that REST uses HTTP directly, including its headers. So we don’t have a “REST protocol” or “REST envelope” in the usual sense, although there are strong conventions on how to use HTTP for REST.

We can say it’s a software architectural style for distributed systems. It was created by Roy Fielding, and described in his widely-read PhD thesis. He got a degree in 2000 after doing a lot of important work on the HTTP and URL specs.

REST design Principles (using HTTP. Conceivably, could use something else.)

1. “Stateless” Client/Server Protocol: Each message contains all the information needed by the receiver to understand and process it. Simplest way. Note that SOAP Web services also follow this design point.

2. Use a set of uniquely addressable (by URIs) resources: “everything is a resource”, the RESTful way.

3. Use a set of well-defined operations that can be applied to all resources: HTTP verbs

4. Use “hypermedia”: return a document with links to the user, giving the user choices of what to do next.

In our current effort, considering Chap. 4, we are not yet doing the hypermedia part. That’s in Chap. 5.

Note the Wikipedia article on REST

Next time we’ll look at the big chart from there, actually from Richardson and Ruby, “Restful Web Services”, the first important book with implementations: