Publishing Engine Programmer's Guide > The Arbortext Publishing Engine Sub-Process > Writing Arbortext PE Applications in Java > Request Processing
  
Request Processing
After loading and initializing the Java application, if necessary, the Arbortext PE Application Context calls the application’s doGet or doPost method to handle the HTTP request. The parameters for both methods are a request object and a response object. The request object contains all available information about the request. The response object, which is empty initially, is a location in which the Java application can build the response. After doGet or doPost returns, the Arbortext PE Application Context returns the response object to the Arbortext PE Request Manager, which transmits the response to the client using the same protocol as the request, either HTTP.
The request and response objects, which implement the interfaces com.arbortext.e3.E3ApplicationRequest and com.arbortext.e3.E3ApplicationResponse, are modeled upon the Java Servlet standard request and response interfaces. Developers familiar with a Java Servlet implementation will find only minor differences. For requests, the only difference is that the E3ApplicationRequest object lacks the methods associated with authentication support.
The response object, E3ApplicationResponse, has more significant differences. In a standard Java servlet, the Java code generates a response body by obtaining an output stream from the response object and writing to it; the data is transmitted to the client as it is written. In a PE Java application, it is necessary to construct the entire response before transmitting it to the client. A PE Java application should write the response data to either a file on disk or a string variable. The application must then call setOutputFile or setOutputPage to add the response file or string to the response object for eventual return to the Arbortext PE Request Manager.
An Arbortext Publishing Engine Java application begins processing a request when the Arbortext PE Application Context calls the doGet or doPost method. Processing finishes when doGet or doPost returns or throws an exception. For a normal return, the content of the response object passed to doGet or doPost is returned to the client. If the doGet or doPost methods throw an exception, the content of the response object (if any) is discarded and an error page describing the exception is returned instead.
The Arbortext PE Application Context calls the doGet or doPost methods only after a call to the init method has successfully returned. Request processing within a single Arbortext PE sub-process is serial, so there's no parallel request processing within a single Arbortext PE sub-process. The Arbortext PE Application Context never calls doGet or doPost to process a second request while a previous call to doGet or doPost is in progress.
However, Arbortext Publishing Engine Java application developers do need to consider two concurrency issues:
• It's possible that several Arbortext PE sub-processes might receive simultaneous requests for the same Arbortext PE Application from the Arbortext PE Request Manager on behalf of different clients. Therefore, it's possible that multiple instances of the same Arbortext PE Application might be running simultaneously in different Arbortext PE sub-processes. To prevent interference with one another, the Arbortext PE Application must use unique files, directories, and other resources.
• An Arbortext PE Application must be serially reusable to handle requests from different clients. An Arbortext PE Application must be prepared to accept calls to doGet or doPost, one after another. Before returning a response or throwing an exception for doGet or doPost, the Arbortext PE Application must clean up files and resources, and leave its internal data in a state suitable for a subsequent call to doGet or doPost.
Note that Arbortext Publishing Engine Java developers do not need to worry about overlapping temporary file name spaces. As described earlier, each Arbortext PE sub-process has its own unique temporary directory. When an Arbortext PE sub-process starts an embedded JVM, it sets the java.io.tmpdir system property to this value. Java programmers who create temporary files and allow the JVM to pick the location are safe from having their temporary files overwritten by other JVMs.