• Choose a category
• All
• Classic-Fiction

By Root 5103 0

field of bioinformatics, where there is a definite need for SOAP-style Web Service architectures. We make use of a project called BioMoby (http://www.biomoby.org) to define Web Services and publish them to a central repository that allows other groups to literally drag and drop our services into a workflow that builds data pipelines to help biologists integrate diverse sets of data and perform varied analysis on the results. This is a perfect example of why someone would choose SOAP over REST. Anonymous users can access our data and tools without any prior knowledge that they even existed.

27.2.1. Define the Service Interface

The first step, as I decided how to implement this software, was to determine how the users will make requests and receive responses. After speaking with a technical representative from the distributor (the primary user), I learned that its new system can send XML documents via an HTTP POST request and examine the results as an XML document. The XML had to be in a format following the Rosettanet e-business protocol (more on that later), but for now it was enough to know that it can communicate over HTTP by posting XML-formatted requests and responses. Figure 27-1 illustrates the general interaction between each of the systems.

The manufacturer had recently been acquired by a larger corporation that dictated the use of IBM products throughout the organization. Therefore, I already knew what application server and corresponding technology to use. I implemented the service interface as a Java Servlet running on an IBM WebSphere application server. This decision was made easier by my knowledge that the software would need to access functions running on an AS/400 server using a Java-based API.

Figure 27-1. Service interface to backend systems

The following code is found in the web.xml file describing the servlet that will provide the necessary interface to the users:

HotKeyService

HotKeyService

com.xxxxxxxxxxxx.hotkey.Service

HotKeyService

/HotKeyService

The servlet itself handles only POST requests, which it does by overriding the doPost method of the Servlet interface and providing default implementations of the standard life cycle methods. The following code shows the complete implementation of the service, but when I first start breaking down a problem and designing a solution, I typically write a series of comments in the code as placeholders where I'll insert the real code later. I then systematically attack each pseudocode comment until I have a working implementation. This helps keep me focused on how each piece relates to the entire solution:

Code View: Scroll / Show All

public class Service extends HttpServlet implements Servlet {

public void doPost(HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException {

// Read in request data and store in a StringBuffer

BufferedReader in = req.getReader();

StringBuffer sb = new StringBuffer();

String line;

while ((line = in.readLine())!= null) {

sb.append(line);

}

HotkeyAdaptor hotkey = null;

if (sb.toString().indexOf("Pip3A2PriceAndAvailabilityRequest") > 0) {

// Price and Availability Request

hotkey = HotkeyAdaptorFactory.getAdaptor(

HotkeyAdaptorFactory.ROSETTANET,

HotkeyAdaptorFactory.PRODUCTAVAILABILITY);

}

else if (sb.toString().indexOf("Pip3A5PurchaseOrderStatusQuery ") > 0) {

// Order Status

hotkey = HotkeyAdaptorFactory.getAdaptor(

HotkeyAdaptorFactory.ROSETTANET,

HotkeyAdaptorFactory.ORDERSTATUS);

}

boolean success = false;

if (hotkey != null) {

/* Pass in the XML request data */

hotkey.setXML(sb.toString());

/* Parse the request data */

if (hotkey.parseXML()) {

/* Execute AS/400 Program */

if (hotkey.executeQuery()) {

/* Return response XML */

resp.setContentType("text/xml");