CS 639 Class 7
Return pa1a, hw1
Notes for pa1b schema testing now available, linked with pa1 on the class web page.
Requests using Query Strings
Recall that a query string is just after the ? in the URL. In hw1 we saw that we can request google searches this way.
The info in the query string is delivered to the application that serves this URL.
Suppose we are serving out stock quotes this way: (like pg. 77)
oursite.com/ourservlet?mode=stock&symbol=IBM
query string
provided to servlet
As we will see in detail later, the servlet support parses the query string & puts the name = value info into the “request” object as its “parameters”. The request object is available to the Java code of the servlet. Suppose its name is req.
String symbol = req.getParameter(“symbol”);
//Servlet does lookup of
data, sends back XML--
out.write(“<quote>100</quote>”)
// OutputStreamWriter, outputting UTF-8
As Harold points out, doing requests by query strings is limited:
- better to send in XML to describe what we want. (& get back XML). (the SOAP way)
- or express resources in URIs, the REST way
Example from pg 81 How POST Works
At pg 82 you see a query string in the content body. This is hidden from the browser URL window of the browser that the user sees.
Here we see content type application/x-www-form-urlencoding (format for query strings) See p 77-78, but not essential, since this is not needed if there is XML in the body, and our tools handle decoding.
POST with XML body ex, pg 98-99
We see content type: text/xml (this is in HTTP header of POST)
XML-RPC
XML RPC like a prototype for Web RPC. It has good basic ideas, has XML both ways.
See ex at pg 85-85, DTD and XSD at pp 90-95 (another useful example of XML much like pa1’s, with DTD and XML Schema)
It handles faults, and it does have data types as commonly used data types, but runs out: only 6 fixed data types in ASCII! Should allow UTF-8 for internationalization.
Quick Intro to SOAP
SOAP is the descendent of XML RPC and this does allow the internationalization. It is better XML, UTF-8 or … and it allows any XML in the app part. We need to use namespaces with it, because we need to use the SOAP vocabulary for the “envelope”, app-specific vocabulary for the body, enclosed within the envelope.
See ex on pg 97, also an example in REST book, pg. 378, Example 11-2
SOAP envelope: has names Envelope and Body here, in the SOAP Envelope “namespace”, id’d by URI http://schemas.xmlsoap.org/soap/envelope/, which has been given the prefix SOAP-ENV by the xmlns:SOAP-ENV=”…” construct, a special XML attribute for namespaces.
The body of the SOAP message is application-specific XML, with its own namespace id’d by a URI involving the author’s website. Here we see xmlns=”…”, which says that this namespace is the “default namespace”, so no prefix needs to be (or is allowed to be) used for its names “getQuote” and “symbol” See pp. 28-32 for an intro to namespaces. We’ll cover this again.
In current SOAP web services, the application messages contained within the SOAP envelopes are usually described by XML Schemas. So be sure to skip everything with SOAP-ENC (SOAP encoding)—this was an earlier attempt to describe message structure within the message itself.
Note that SOAP does not have to use HTTP for transport. For example, you could send a SOAP request by email (SMTP rather than HTTP) and get a response by email. The SOAP request is self contained, i.e., doesn’t use HTTP headers or different HTTP verbs, just POST when used over HTTP.
SOAP
· uses SOAP Envelope around XML messages designed for the particular service
· XML messages are typically described by XML Schema
· Is platform-neutral: can have JEE server, .NET client or vice versa (sometimes problems, though)
· WSDL (Web Services Description Language) is an XML document used for describing SOAP services
· In particular, there are tools that read WSDL and create client app skeletons, for both JEE and .NET
SOAP over HTTP
· uses POST only
· ignores headers except possibly Content-length
· typically uses a single URL “service endpoint” at a particular server, no query string
SOAP web services took over (2000-2005 say) from older technologies that were much less open and portable, a big step forward. Now REST is more popular.
Quick Intro to
REST
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!)
· 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
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.
SOAP and REST both need a HTTP server, i.e., application server, to do the necessary actions.
Now we see the basic idea of SOAP and REST. We need to turn to the execution environment for web services under J2EE, i.e., servlets, so we’ll talk about tomcat, and you will be able to install it on Linux users2 and on your home PC.
Tomcat is a web server, and thus runs a server process, listening on a certain TCP port. Though web servers usually listen on port 80, tomcat normally runs on another port, often 8080, to avoid conflicting with the “real” web server.
For example, eoneil's tomcat runs on port 11600 on users2.cs.umb.edu.
Browsing to http://users2.cs.umb.edu:11600 (via tunnel, if from off-site) will show the tomcat default home page with the tomcat icon
You will need a specific port to run your own copy of tomcat on Linux. At home or in the weblab, you can use the “normal” port 8080.
Actually you need 2 ports, one for the service and one to command tomcat to stop.
TCP ports at CS.UMB (UNIX/Linux systems)
· port 80 is reserved for site webservers, like our whole CS department
· low-numbered ports are “well known” ports (see /etc/services on any Unix machine) with definite assignments, like ssh
· port numbers above 1023 are non-priviledged on Unix (any user can run a server on them, but should be authorized locally)
· at UMB we have static allocation of port numbers by professor. numbers 51250 – 51499 are reserved for eoneil
· each class member will get 5 port numbers, good on any Unix/Linux machine at our site. You'll run Tomcat on these ports.
Note the new Resource links to a tutorial on servlets if you have time before next class to get started.
Handout: Example servlets that come with tomcat. You can find them via links from the Tomcat home page.
Tomcat
· Tomcat is a webserver and a servlet container
· the Tomcat home page has links to JSP examples and servlet examples
· eoneil’s tomcat is running on users2.cs.umb.edu on port 11600: browse to http://users2.cs.umb.edu:11600
· read the servlet tutorials linked under Resources on the class web page
JSP vs. servlets
· JSP is a server-side scripting language usually used for producing HTML, but also can produce XML.
· We won't be using it in this course, since we will be using the underlying technology, servlets, directly
· JSP is compiled into a servlet, so servlets are more basic anyway
· PHP is another server-side scripting language, also ASP for Microsoft .NET
· Also there are client-side scripting languages, notably Javascript
Look at the HelloWorld servlet, which can be found by browsing to http://users2.cs.umb.edu:11600 and following the link to Example Servlets
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld
extends HttpServlet {
public
void doGet(HttpServletRequest
request, HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head>");
out.println("<title>Hello
World!</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Hello
World!</h1>");
out.println("</body>");
out.println("</html>");
}
}
· The HttpServlet object provides a framework for constructing servlets and provides many services
· In the HelloWorld servlet, the code overrides the the doGet method for handling GET requests
· The HttpServletRequest and HttpServletResponse provided as arguments to doGet are important objects, ready to use
· The first thing to do is to set the content type. This is a form of typing for the output message.
· This content type sets encoding character set for response object's Writer: Latin-1 for text/html, UTF-8 for text/xml.
· Here we see text/html, so the Latin1 character set (ISO 8859) is used here.