FastSOA is equally applicable to improving the performance of SOA application requests that require access to data. FastSOA implements a mid-tier cache to commonly accessed data. Caching is a powerful and proven technique for database systems. For instance, RDBMS tools vendors perform caching strategies at three points in an SOA environment, as illustrated in Figure 6.

In the presentation tier, a Web cache provides cached data to Java Server Faces (JSF) dynamic pages. At the application tier, caching at the object/relational mapping (ORM) and in the connection layer to the relational database (RDBMS) is recommended using an in-memory cache. Caching in this environment works well to mitigate relational performance problems.

These caching techniques should, but don't, take advantage of the unique features of XML data. Many SOA XML messages include a time-to-live value in the message itself. This gives the cache intelligence about the lifetime of data that's usually unavailable in generic data caching approaches. To achieve this, cache intelligence requires a programming language and persistence engine of its own.

Figure 7 shows a FastSOA architecture using native XML technology to provide a service interface, accelerate service performance by caching response data, and implement flexible and rapidly changed policies to operate the cache engine.

The advantage to using the FastSOA architecture as a mid-tier service cache is its ability to store any general type of data, as well as its strength in quickly matching services with sets of complex parameters to determine efficiently when a service request can be serviced from the cache. The FastSOA mid-tier service cache architecture does this by maintaining two databases.

• The service database holds the cached message payloads.For instance, the service database holds a SOAP message in XML form, an HTML Web page, text from a short message, and binary from a JPEG or GIF image.
• The policy database holds units of business logic that look into the service database contents and make decisions on servicing requests with data from the service database or passing through the request to the application tier. For instance, a policy that gets a SOAP request validates security information in the SOAP header to validate that a user can get previously cached response data. In another instance, a policy checks the time-to-live value from a stock market price quote to see if it can respond to a request from the stock value stored in the service database.

FastSOA uses the XQuery data model to implement policies. The XQuery data model supports any general type of document and any general dynamic parameter used to fetch and construct the document. Used to implement policies, the XQuery engine lets FastSOA efficiently assess common criteria of the data in the service cache, and the flexibility of XQuery allows for user-driven fuzzy pattern matches to efficiently represent the cache.

FastSOA uses native XML database technology for the service and policy databases for performance and scalability reasons. Relational database technology delivers satisfactory performance to persist policy and service data in a mid-tier cache provided the XML message schemas being stored are consistent and the message sizes small. To understand this in greater depth, consider the following results from a comparison of native XML database technology to relational databases.

The test runs multiple test cases where each test case varies the number of concurrent requests made to the database host and varies the size of the XML message. The test environment makes requests to a relational database and a native XML database. For the relational database the test used an XML CLOB field type. The use case is modeled around a mid-tier cache's need to rapidly persist and query an unknown quantity of data with multiple and unknown schemas.

The test environment monitors the time it takes to get a response at the consumer. The test produces a report showing transactions per second (TPS) at each level of concurrent requests and message payload sizes. Figure 8 shows a scalability index report for querying a database of stored XML documents.

In the query performance test, the native XML database starts at 45TPS and goes up to 186TPS while the relational database stays at 15TPS or less. Figure 9 compares performance characteristics while inserting XML documents into the database. The insert document performance test shows that native XML database and relational database performances are evenly matched at 20 and 17TPS at the lowest number of concurrent requests. At 32 concurrent requests, the native XML database performs 3.4 times (48TPS/14TPS) as many inserts than the relational database performs.

These results are not meant to knock relational database technology out of the running for XML persistence, because there are undoubtedly a large number of optimizations that could be employed to improve performance. Instead, these numbers are meant to prepare you for the performance and scalability challenges in SOA environments that use an unknown variety of XML message sizes and schemas.

There's no gatekeeper to the number and form of XML message schemas in an SOA environment. Mid-tier caching strategies need the best-performing and most flexible database available that can handle multiple and unknown message schemas and data formats. The benefits to a business running a FastSOA mid-tier service cache include:

• Fewer CPU licenses for commercial application servers
• Less network overhead
• Improved performance as compared with other mid-tier cache architectures
• Advanced SOAP in-line processing for a two-three times performance improvement over binding proxies created with Java application server utilities
• More efficient relational-to-XML transformation processing

The next scenario shows how FastSOA is used as a service data cache to improve data retrieval performance.

Scenario 2: Improving SOA Performance to Access Services
Imagine that a business operates a portal for employees to sign up for a retirement plan, medical insurance plan, and other programs. The portal application interfaces to an external database using a JDBC driver to retrieve company news. It also interfaces using REST protocols (XML over HTTP) for employee benefits data from the human resources service. The portal permits single sign-in to these services by interoperating with the corporate directory using LDAP protocols. Figure 10 illustrates a typical use case.

The use case begins with an employee signing in. The portal application validates the user credentials. Validated users sign up for alerts to enable the system to send an email notification when new healthcare plans become available. The employee uses the portal to browse healthcare plans and choose a plan. The service ends the use case by confirming the plan choice.

Figure 11 illustrates an architecture often recommended in the Java development community to implement the employee portal. The architecture divides into three portions: 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 portal application also presents data to systems in other departments using SOAP and Java interfaces. At the application tier, an Enterprise Java Bean (EJB) implements the business logic to respond to the request. The EJB interoperates with a relational database, security manager, and human resources service. Corporate mandates require the system to store the plans offered to the employees in its original XML form.