Handout: Intro to Amazon S3
Final, scheduled for Fri evening: we decided to move it to Thursday, 5/17, 3pm in M-2-209.
Pa3 notes: Thanks to Max Ward for a nice solution using DOM, already posted. I would also like to post David Lowery’s nice solution using JAXB, to show that approach.
I learned from your code that DOM with namespaces can use doc.createElement(“ns:foo”) rather than doc.createElementNS(NSURI, “foo”), after setting up the root node the same way we did in SimpleSVG.java, providing the NSURI at that point.
Also, some projects were getting away with using namespace-unaware DOMs created from namespace-using XML (OrderService.xsd), queried by namespace-prefix-free XPath queries ("//simpleType/@name"). Apparently this works for various complicated XPath queries, but not for the simplest such as “//simpleType”. Big mystery to me. All I can say is that to be sure, use a NamespaceContext as we did in $cs639/xpath/XPathExample.java. The pa3 solution uses a NamespaceContext.
Servlets for SOAP
We can do a lot with Servlets + SOAP -> basic SOAP Web Service
SOAP Client, pg. 142, like AdminTool of pa3: just uses JDK.
SOAP Servlet, pg. 146, also very primitive, but obviously we could do better.
The basic Web Service works OK between the two cooperating sites. (their developers in communication -> share DTDs, schemas etc).
Java EE support: SAAJ and JAX-WS
SAAJ is the lower-level package, and JAX-WS is layered on it.
SAAJ is a DOM-like approach: build up or break down the message like you work with an ordinary DOM. No WSDL support.
Sun’s CoffeeBreak SAAJ/JAX-WS example uses DTDs instead of XML Schemas to describe SAAJ messages. A little unusual, but with plain SAAJ, DTDs and schemas are “off to one side” anyway.
CoffeeBreak Example: in Java EE Tutorial
Web retailer of coffee has two suppliers
--one uses SAAJ, the more basic SOAP service
--other one uses JAX-WS, the higher-level SOAP package, like JAX-RS
JAX-WS is layered on SAAJ, and does more for us, specifically it generates to and from WSDL, web service definition language, for standardized declaration of message formats, other things.
Let’s look at JAX-WS.
Like JAX-RS, JAX-WS provides a servlet, so we don’t have to code doPost ourselves, just put the right entries in our web.xml to get the servlet going.
We use annotation on server methods called on by SOAP services. We use JAXB markup on POJO classes related to the XML messages.
Unlike JAX-RS and WADL, it is easy and commonplace to generate almost a whole service or client from WSDL, so WSDL is much more important than WADL.
Like WADL, WSDL includes or points to XML schema(s) describing the XML messages needed for the service, that is, the payloads inside the SOAP envelope.
Almost the whole service, including JAXB POJOs for business objects, can be generated from the WSDL file. Of course we have to program the actual actions done by the service, by filling in code in provided stubs.
Similarly, client stubs can be generated from the WSDL.
Clearly WSDL is intimidating, so few people would want to try to write it out by hand for a new service! But being able to read it is really useful. And tools exist to help edit it.
WSDL: an XML doc that describes the web services of a certain server
Can be obtained from a proper Web Services site by ?wsdl query
Ex: StockQuoteService of s08 (still online, but using old libs) had URL
http://sf06.cs.umb.edu:11600/jaxws-stockquoteservice/quotes
Get wsdl by GET to
http://sf06.cs.umb.edu:11600/jaxws-stockquoteservice/quotes?wsdl
Similarly, you can get eBay WSDL by public URL, also Amazon services
WSDL doc contains
--XML Schemas for message bodies
--abstract SEI: service endpoint interface, i.e., what the calls look like
--spec. of SOAP, HTTP, endpoint address for services
Usually have one service URL for multiple WSs, usually discriminated by top-level element name in request body XML.
Once we have the WSDL doc, we can use tools to help build server-side and client code.
The tools allow the client and server to use the SEI as a Java API.
JAX-WS: Sun’s Web Services platform
Server side:
--provides tools for turning WSDL into a skeleton service: we fill it out
--tools needed are set up in a build.xml that can be reused pretty easily
--provides a Web Services delivery servlet, so we don’t have to write the servlet itself
--the servlet serves as a framework for our service code: its code calls our service implementation code
--runs as an ordinary servlet of a webapp on tomcat 6 or other app server
--once we deploy our project to tomcat, JAX-WS servlet handles WS calls and ?wsdl queries
Client side:
JAX-WS provides tools for turning WSDL into a client-side Java API to use, plus objects needed for the API. Again set up in a build.xml.
See $cs639/StockQuoteClient project if interested.
Big pic:
WSDL
/ \
/
\
Tool Tool’ ß
JAX-WS tools (or .NET, with Java->C# below)
/
\
/
\
Service Client
Skeleton objects
Code, Java ready for
SEI, objects Client code, Java SEI
| |
We fill out, We write top-level
code,
implement SEI call SEI
|
Deploy service
With WSServlet to
tomcat
|
Servlet provides
WSDL ----------à WSDL for clients (wrap arrow
to top of pic)
Both these sides use Data Binding: XML to Java objects and back
At WS-execution time
client sends a SOAP message with the top level element in the body with its name = operation name and the XML described by the XML Schema.
Server :sends back a SOAP message according to its schema.
System configuration: ordinary webapp, once deployed
Deployment: build.xml creates .war file, zipped-up deployment
webapps/myservice.war ß war file dropped in webapps by build.xml “ant deploy”
webapps/myservice/WEB-INF/classes
/lib
/web.xml ßsee
WSServlet listed in here
Go over WSDL handout
Can read both ends first: message payloads, service endpoint.
Stuff in middle needs to be consistent. Get some help from eclipse WTP WSDL editor.
As see in tutorial: 4 major elements inside <definitions>, plus <types>
<types> schema for message bodies, each an <element> at top level.
<message> an individual message body defined by a top-level <element> in <types>
<portType> set of operations (WSs), each with appropriate input, output <message>s
<binding> how the <portType> WSs are to be actually done: SOAP/HTTP for us
<service> location of services described by a <binding>: the endpoint address
At top: two app NSs. We’ll follow the pattern that the whole app service has appURI, the types for it have typesURI = appURI+”/xsd”.
For pa4, the content of <types> is provided, a big help.
NCName/QName linkage is used in WSDL, as in XML schema.
In handout, NCNames are in bold that are used as anchors, pointed to by QNames: find them, link them up.
Recall rule of thumb for schemas: name=”NCName” introduces a new name into the namespace, while for example, type = “QName”, QName refers to that name, intro’d elsewhere, and using a prefix here. QName means qualified name, prefix:localname, and NCName is just the localname part.
Here in WSDL it’s the same idea: name=”NCName” is used to intro new names, use elsewhere with prefix. Here in WSDL the QName-typed attributes have more different uses than just type: we see element = “QName” (ns: getPrice. in <message>), message=”QName” , as well as type = “QName” (used in <binding>), binding = “QName” Each of these QNames points to the matching NCName, in one case across namespace boundaries (to get to the app types schema).
WSDL targetNamespace=”…”
Another idea from schema used in WSDL: targetNamespace=”…” to document where the name=”NSName” names are expected to go.
We checked the NCName/QName linkages (to the NCNames in bold on the handout) individually in class.
We see NSName/NSName linkage between <operations> in <portType> and <binding>. We saw this before in web.xml, where <servlet-name> value links the <servlet> and <servlet-mapping> elements together for one particular servlet. Also note there is no ambiguity between these two <operation> elements because they have different parent elements.
Easy to sign up, use as backup space.
Each bucket appears as a “site”, so / is the root of the site, which holds a collection of objects. A GET to / gets a list of object metadata in a <ListBucketResult> with NS http://s3.amazonaws.com/doc/2006-03-01/. Each object’s metadata is in a <Contents> element with a client-supplied <Key>.
To get the data of that first object, use GET /my-image.jpg. We see that the objects have <LastModified> dates and <ETag> entity tags, i.e., server-supplied unique IDs used in headers. See R in P, pg. 79-80 for info on ETags.
Look at WSDL on handout. Note that unlike the StockQuoteService example, this WSDL uses only one app namespace, "http://s3.amazonaws.com/doc/2006-03-01/", for both the message XSD and the WSDL service XSD. Because of this, it can just <xsd:include> the message-level XSD into the WSDL file.
Other apps:
· Holding large files for websites. S3 can even host a static website.
· Holding data for cloud computing: you get some computing nodes from EC2, pull data from S3, so you don’t have to rent the computing nodes just to hold data.
Note it takes time to back up a GB: my test ran with DragonDisk about 200KB/s, so 1MB in about 5 sec, 1GB in 5000 sec = 1.5 hr. May be faster on big files. Depends on your ISP service too. Big problem: speed of light slows TCP acks between here and Virginia, where the east coast servers are.
Because of transfer slowness, getting 1 TB or more loaded into S3 is usually done by mailing the disk to Amazon’s site, where they load it for you.