News Desk

Here we're going to show a FastSOA mid-tier service and data caching architecture applied in three real-world scenarios. The scenarios show how to accelerate SOA performance and mitigate performance problems through mid-tier service caching, native XML persistence, and mid-tier data transformation, aggregation, and federation.

Three Use Cases and the FastSOA Pattern
FastSOA is an appropriate solution for SOA performance and scalability challenges. Each use case shows how pure XML technology used in the mid-tier mitigates and solves performance and scalability problems and delivers flexibility unavailable with object and relational technology. While there are many (sometimes contradictory) definitions of SOA, most software developers and architects recognize and support SOA as a pattern built around consumers, services, and brokers. Figure 1 shows this relationship. The basic SOA patterns make sense for developers building services, Web Services, and composite applications and data services. The pattern lets a consumer who makes a request to learn the location and interface message schema of a service. The consumer binds to the service by sending a request message. The service returns a response message to the consumer's request. The service makes its location known by publishing the ontology of its functions and interface message schema to the broker. SOA is an abstract architecture - for instance, SOA doesn't define a specific protocol such as SOAP in the Web Services standard - but most SOA designs use XML as the message format between consumer, broker, and service.

To understand the SOA pattern in practice, we'll look at three scenarios and show how FastSOA solves scalability, performance, and flexibility challenges in each.

• Accelerating service interface performance and scalability
• Improving SOA performance to access services
• Flexibility needed for Semantic Web, service orchestration, and services dynamically calling other services

Scenario 1: Accelerating Service Interface Performance & Scalability
Suppose a business operates a parts ordering service. The service provides a Web browser user interface to enter a new order and learn the status of an existing order. Behind the UI is a SOAP-based Web Service using ebXML message schemas to track the status of the order from a vendor's legacy inventory system. The service stores orders and customer information in a relational database. Figure 2 illustrates a typical use case.

The use case begins with a customer placing an order. The service validates the order against the current inventory to make sure the part being ordered is in the parts catalog. The service stores the order until the company consolidates all the orders in a nightly batch process with the parts vendor. The service ends the use case by checking the status of the order. Figure 3 illustrates an n-tier architecture often recommended in Java development to implement a parts ordering service.

The architecture divides into three parts: A presentation tier, an application tier, and a data tier. The presentation tier uses a Web browser with AJAX and RSS capabilities to create a rich user interface. The browser makes a combination of HTML and XML requests to the application tier. Also at the presentation tier is a SOAP-based Web Services interface so a customer system can access the parts ordering functions. At the application tier, an Enterprise Java Bean (EJB) or plain old Java object (POJO) implements the business logic to respond to the request. The EJB uses a Model, View, and Controller (MVC) framework - for instance, Struts or Tapestry - to respond to the request by generating a response Web page. The MVC framework uses an object/relational (O/R) mapping framework - for instance, Hibernate or Spring - to store and retrieve data in a relational database.

There are three problem areas that cause scalability and performance problems when using Java objects and relational databases in XML environments. Figure 4 illustrates these problems.

Using the Java/relational architecture leads to performance and scalability problems as the XML messages grow in complexity and size.

• XML/Java mapping requires increasingly more processor time as XML message size and complexity grow.
• Each request operates the entire service. Many times the user will check order status sooner than any status change is realistic. If the system kept track of the most recent response's time-to-live duration then it wouldn't have to operate all of the service to determine the most previously cached response.
• The vendor application requires the request message to be in XML form. The data the EJB previously processed from XML into Java objects now has to be transformed back into XML elements as part of the request message. Many Java-to-XML frameworks - for instance, JAXB, XMLBeans, and Xerces - require processor-intensive transformations. These frameworks challenge developers to write difficult and complex code to do the transformation.
• The service persists order information in a relational database using an object/relational mapping framework. The framework transforms Java objects into relational rowsets and does the joins among multiple tables. As object complexity and size grow, many developers have to debug the O/R mapping to improve speed and performance.

To give you an idea of the extent of the problem, consider the performance advantage of using native XML technology to respond to service requests. Figure 5 contrasts the performance difference. The results in Figure 5 contrast native XML technology and Java technology to implement a service that gets SOAP requests. The test varies the size of the request message among three levels: 68 kilobytes, 202 kilobytes, and 403 kilobytes. The test measures the roundtrip time it takes to respond to the request at the consumer. The test results are from a server with dual-Xeon 3GHz processors running on a gigabit-switched Ethernet network. The code was implemented in two ways:

1.  FastSOA technique. Uses native XML technology to provide a SOAP service interface. Raining Data TigerLogic's XML query (XQuery) engine was used to expose a socket interface that gets the SOAP message, parses its content, and assembles a response SOAP message.

2.  Java technique. Uses the SOAP binding proxy interface generator from a popular commercial Java application server. A simple Java object gets the SOAP request from the binding, parses its content using JAXB-created bindings, and assembles a response SOAP message using the binding. The results show a 2-2.5 times performance improvement when using the FastSOA technique to expose service interfaces.

The FastSOA method is faster because it avoids many of the mappings and transformations that are done in the Java binding approach to work with XML data. The greater the complexity and size of the XML data, the greater the performance improvement.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...