CS 639 – class 28 Last Class: do teacher evals

Final Exam: Thursday, 5/17 3pm, M-2-209

New posting: pa3 done entirely with POJOs, no DOM: $cs639/pa3soln_pojos—thanks to Mohamed Kahin and David Lowery.

Review:

Since midterm, we covered WebServices, more on XML Schemas,

Recall reading guide for Harold for midterm, still useful.

Since midterm: basic SOAP, pp. 96-99, Ex. 2.20-21 on p. 103, but drop encodingStyle=…attribute., pp 116-118.

REST in Practice Reading

Chap. 1—intro, resources, URIs, intro hypermedia. Figure 1-7 shows how to think about the hypermedia UI states. The user visits various URIs, and each URI represents a certain resource, and a state in this diagram. The links returned when the user visits new URI show what the next step can be.

However, when we try to draw such a diagram for the Chap. 5 hypermedia example, we see that the links presented to the user for the order URI depend on the order’s state. We need to differentiate hypermedia UI state from resource state here.

We have previously looked at the FSM for the order resource itself, Fig. 5-5, pg. 113.

Different Links from order URI based on its internal state:

· After original order (order status UNPAID): links presented to user are to update, cancel, pay, or self.

· After order is paid (order status PREPARING): links presented to user are: just the “self” link, useful to find out status.

Thus to make one box for the order URI, we need show the links as conditional on the order status. We drew a box with top side showing UNPAID links, right side showing PREPARING links. Then we can draw the hypermedia state diagram:

[order URI] -à[payment URI] à[receipt URI]

^ ^ / /

\ \________/ /

\_____________________ /

This is finally shown on pg. 130, beyond where we reached, though without the update and cancel operations from order, and with extra nodes for the URIs.

Continuing on REST in Practice Reading

Chap. 2—Restbucks

Chap. 3—Web Architectures: idempotent operations, GET semantics. Can skip from pg. 37 to end of chapter—just covers various ways not to do things.

Chap 4: the core orderService example, all important to pg. 83. Then that subsection of Consuming CRUD Services (client programming) is not useful. Recall that JAX-RS only standardizes the server-side REST support, but Jersey provides support for both server and client sides. See online examples for client-side programming.

Pg. 86—example WADL.

Chap. 5 Hypermedia

Pg. 98: hypermedia publishes one URL to start from, and clients discover the other URIs as they navigate the hypermedia states, vs. ordinary REST publishes URI Templates.

Pg. 109: mediaTypes are important

Pg. 116-121: the actual messages for this protocol, very important for understanding

That’s as far as we got.

Web Services

We studied the REST Web Services, then SOAP WebServices, just the “document style”, no SOAP encoding.

An HTTP web service, whether REST or SOAP, has the following characteristics:

· Is offered at a certain URL or base URL, the SOAP service endpoint, or the REST base URL.

· Offers services that are each “stateless”, meaning that the server is not expected to remember a previous call when servicing the present call (except through the first call’s changes to the server’s persistent data) . Each call comes in with all the needed specification of the requested service. Each call is self-contained, except for persistent data held by the server.

· Is defined by international standards, so clients are not restricted to Java or .NET execution environments, for example.

· Is internationalized. It uses UTF-8 for text in any language.

· Uses XML for structured data in messages (or JSON in REST case)

· Typically, but not universally, uses XML Schema to describe XML.

· Uses TCP stream connections (from being HTTP), which provide reliable, flow-controlled data transmission.

· Although the protocol is stateless, the objects (orders, payments, or whatever) being manipulated via the protocol and held by the server, can change state, and this can be described by FSMs such as Fig. 4-1.

· Being HTTP, is “pull technology”: client always does a request to get information, i.e., no notifications are sent out from the server to the client without a specific client request. Makes it easy to use layers on the server.

· Can return image data or other binary data as well as structured data in XML.

Example of a non-stateless service

GetFirstOrder

GetNextOrder

Here the server needs to keep track of where an individual client is in the sequence of receiving orders.

Making this into a stateless service: make the client say which one to return

Because of all these similarities, it is relatively easy to convert from one to another, or offer both, as we saw with Amazon S3. With the layered approach, it’s just a matter of having two presentation layers on top of a common business layer.

Specific to REST

· Everything is a resource, i.e., each object handled by the server has its own URI.

· Uses HTTP verbs the way they were designed to be used. Specifically, GET must not change the state of the representation, so GET results can be cached.

· Uses HTTP error codes the way they were designed for, so clients can understand better what went wrong.

· Uses HTTP headers, more or less the way they were designed, specifically, Content-Length, Content-Type, Accepts, Location, Authorization

· Uses mediatypes as metadata, including vendor-specific mediatypes.

· Can use JSON instead of XML. Also plain text, image files, etc., described by mediatype in header.

· Has a standard way to handle collections of elements

· Has concept of URI template, very helpful for compact description

· Has idea of WADL, but not supported well or used much.

Specific to SOAP

· Uses SOAP envelope around messages

· Has WSDL, hard to read but very commonly supported because it makes building a client easy using Java, .NET, other tools. WSDL contains or points to XSD for messages.

· Ignores HTTP verbs (just uses POST), detailed error codes (uses HTTP 500 for a lot of errors, 404, etc. are generated by web server),

· Ignores mediatypes (just uses “text/xml”)

· Because it only uses POST, nothing can be cached.

· Uses only XML for structured data, i.e., can’t use JSON. Can return an image file but not just an image file, because it needs the SOAP envelope. Can use “attachments” of image files, etc.

· Is considered “heavyweight” compared to REST “lightweight”

What we did in PAs: REST examples

PA2: XML servlet, a read-only RESTful service.

PA3: REST client of orderService, using Jersey client support (itself not spec’d by JAX-WS, but closely related). Used WADL only to locate XSD. Mined XSD for options.

PA4: REST server using JAX-WS, or orderDap client

Advanced XML Topics

XML Schema Simple types: Enumerations, SKUType, etc. (class 21)

JAXB annotations (class 21, 22)

Using multiple schemas, schema import, NCName and QName types assigned in the schema of schemas, etc. (class 25)

Example of Link.xsd and OrderDap.xsd for Chap 5 orderDap.

Using <xsd:any> to allow handoff to another schema on validation (class 25), used in the SOAP envelope schema.

WSDL: don’t worry about details here. We see it describes the WS’s in terms of the XSDs for their messages, plus the service endpoint URL.

Other Important topics

—everything we need for PA3 and HWs, their posted solutions.

also the firstRest example, since PA4 is optional

Designing WSs—being self-contained, sending full information to avoid back-and-forth traffic

Service objects: BL and DAO layers, setting up correctly

Understanding build.xml tasks we set up