| WebSphere Application Server 5.0 was a major new release of the WAS product. V5 includes comprehensive J2EE 1.3 support; a completely different approach to product packaging and installation of single and multiserver configurations; an all new server administration architecture (including an XML-based administrative repository, a Web-based Administrative Console, and a completely new scripting facility); substantial security, availability, and performance enhancements; and many new programming extensions. Feature Details WAS V5 brought major changes to IBM's strategic application server. This section gives details on WAS 5.0 features, along with some advice on using those features. WAS Product Packages -
WAS Express is a lightweight server that supports static content, servlets, and JSPs ”but not EJBs. Its features simplify installation and administration. -
WAS is the core application server. It provides full J2EE 1.3 support and many additional features. WAS is licensed for a single system and doesn't support workload management. This V5 product is the successor to WAS Advanced Single Server Edition (WAS AEs) in V4. -
WAS Network Deployment ( WAS ND) is the core WAS product plus the Network Deployment add-on module, which enables multiserver configurations and workload management. This product is the successor to WAS Advanced Edition (WAS AE) V4. -
WAS Extended Deployment ( WAS XD) is WAS ND plus the Extended Deployment module, which adds more configuration, runtime, and administration features for large-scale, multiserver environments. -
WAS Enterprise is WAS XD plus the Enterprise Extensions module, which includes a set of additional programming features. This product is the successor to WAS Enterprise Edition V4. -
WAS for z/ OS is a platform-specific implementation of WAS Enterprise (except for those features that don't make sense on z/OS). WAS Enterprise, WAS XD, and WAS ND are delivered as a set of modules that you install on top of the base WAS product. Unlike in V4, you don't have to uninstall one edition of WAS to upgrade to a higher-level edition. For example, you can initially install WAS V5 on a machine and later install the Network Deployment module to upgrade to WAS ND. This packaging should simplify upgrades and provide more consistent behavior among different editions. New Administration Architecture WAS V5 no longer requires a relational database management system (RDBMS) as the administrative repository for multiserver configurations. All editions now use XML files to store configuration information. IBM says this change is a response to market resistance to the requirement of an RDBMS just for the repository. The Java application used for the WAS AE Administrative Console in V4 has been replaced by a Web application, which all editions use. The V5 Web-based console is much expanded and improved over the Web-based console used for WAS AE in V4. The WebSphere Control Program (WSCP), available in WAS AE V4, was replaced by a more flexible and coherent facility (known as wsadmin) that's available in all V5 editions. You can use wsadmin in interactive or batch modes and perform any operation that you can do with the Administrative Console. The wsadmin utility is based on IBM's Bean Scripting Framework (BSF) and supports a variety of scripting languages, including JavaScript, JPython, and Jacl (a Tcl derivative). The new V5 administrative architecture uses 30 or so Java Management Extensions (JMX) managed beans (MBeans) to control WAS servers, and these MBeans are accessible in wsadmin scripts. The V5 support for JMX is important not just for wsadmin; JMX also lets independent developers use a standards-based interface to develop WAS administrative tools. Workload Management Multiserver configurations and workload management (WLM) have also been redesigned in V5. In WAS ND and higher, distributed configurations are organized as cells (comparable to a V4 administrative domain). A cell is a set of nodes, and a node is a set of managed servers. A node cannot span multiple machines, but a machine can have multiple nodes. In WAS terminology, a managed server means an instance of WAS ”that is, a single JVM running in its own process. A cell has one master administrative repository file, and each node and server also has its own local administrative repository file. Changes to a node or server repository file are temporary and while in effect override specifications in higher-level repository files. Changes to the cell repository file are permanent and are propagated to the node and server files when the next synchronization action occurs (e.g., when a server starts). A cell manager process runs on one of the systems encompassed by the cell and communicates with one or more node managers, each of which runs in its own lightweight (i.e., not a full J2EE environment) JVM process on the same machine as the associated node. Having independent cell manager and node agent processes increases the independence of node and server operations, while maintaining coordination among them. For example, you can start a node's servers and run applications on them whether or not the cell manager is running. Any necessary synchronization occurs among servers and nodes whenever a server, a node agent, or the cell manager is started (or possibly at other defined synchronization points). You also can attach an administrative client (such as the Administrative Console) at any of the three levels and manage the server(s) encompassed by that level. This lets you administer parts of a cell even when the cell manager is down. Within a cell, a cluster is a workload-managed set of servers. (Clusters replace the V4 server group feature.) A cell can have multiple clusters, and servers in a cluster can all be on the same node (vertical cluster) or in multiple nodes (horizontal cluster). New in V5 is the ability to define a backup cluster, which mirrors and provides failover for an entire (primary) cluster. V5 WLM also supports a new server-weighted, round- robin routing mechanism that adds better control over load distribution. Application deployment is greatly simplified in a V5 cluster because you need only install the application on a single node, and WAS will replicate the application to other nodes as needed. The WAS ND module also bundles the DMZ CD, which includes WebSphere Edge Server components , such as the IBM HTTP Server, the Network Dispatcher router, and a caching proxy. WAS XD adds features that allow dynamic and custom tuning of WLM, asynchronous application distribution, Simple Network Management Protocol (SNMP) support, and proximity-based (i.e., tiered) name lookups. Security V5 supports the full Java 2 and J2EE 1.3 security architecture, including the Java Authentication and Authorization Service (JAAS). JAAS provides for plug-in authentication modules, and the base WAS product supports Simple WebSphere Access Mechanism (SWAM), which is equivalent to V4 LocalOS, as well as Lightweight Directory Access Protocol (LDAP) and custom user registries. When you add the ND module, you also get Lightweight Third-Party Authentication (LTPA) support. The WAS XD module will add Kerberos support in a point release to follow V5. Version 5 also supports the OMG Common Secure Interoperability (CSI version 2) standard for communication within a distributed environment. WAS administration now supports roles that have different sets of capabilities. The base WAS edition provides Administrator, Operator, Configurator, and Monitor roles, and WAS XD adds other, finer-grained roles. You authorize users to appropriate roles so they can perform the administrative operations related to their job responsibilities. In a point release to follow V5.0, WAS XD will bundle the Tivoli Access Manager (formerly called Policy Director), which provides an integrated user administration facility and allows access policies to be changed dynamically. For Web services, WAS V5 supports the Web Service Security (WS-Security) standard developed by IBM, Microsoft, and Verisign. WS-Security supports digital signatures and identity propagation. Performance In addition to server code optimization, several other enhancements have been made to improve performance under WAS V5. There's a new memory-to-memory option for sharing session data among multiple WAS instances, which lets you avoid the cost of using RDBMS persistence for this type of sharing. The existing Dynacache facility has been expanded to support edge-side includes using the Akamai ESI product. Also available are new caching policies and cache replication across nodes. The V4 Performance Analyzer tool was enhanced and renamed as Tivoli Performance Viewer. A "technology preview" for Performance Viewer will provide tuning advice, a first step in what IBM plans as automated WAS performance tuning. The Performance Monitoring Interface (PMI) adds new instrumentation for session times, Dynacache, WLM, JDBC, and other WAS components. The new information available from PMI can be exploited by third-party and locally written tools, as well as by IBM products. Problem Diagnosis WAS V5 has several enhancements that should aid in problem diagnosis. Diagnostic messages have been improved to include help on probable causes and suggestions for corrective actions. All internal exception handling (i.e., catch blocks) has been equipped with a system known as First Failure Data Capture (FFDC). FFDC makes it easier to diagnose the root cause of a problem, and WAS provides an analysis engine that matches FFDC data against a knowledge base of common errors and fixes to provide help in correcting a problem. V5 also includes a new end-to-end transaction trace facility to examine application execution flow. J2EE 1.3 Support Perhaps the most important aspect of V5 is the support for J2EE 1.3, especially EJB 2.0. The EJB persistence manager has been completely redesigned. Not only does the new facility support EJB 2.0 features, but much of the implementation support has been moved out of the code-generation tools that are in VisualAge for Java and WebSphere Studio Application Developer and into WAS runtime components. This change should substantially reduce the need to regenerate code as the persistence manager evolves. Another notable change brought about by J2EE 1.3 is that access to data in an RDBMS is through new relational resource adapters (RRAs) that are part of the Java Connector Architecture (JCA). (Older-style, direct JDBC access is still supported, but it's not the recommended approach.) This change will impact application coding and administration tasks . The base WAS product and WAS ND both contain a limited version of WebSphere MQ as the Java Messaging Service (JMS) provider. This limited version doesn't support non-WAS applications or many of the management functions of the full-blown WebSphere MQ product, which is bundled with WAS XD and WAS Enterprise. Web Services WAS V5 expands on the previous version's support of Web Services. Version 5 will use the new AXIS engine (aka SOAP 3.0), which should improve performance. WAS ND includes a private UDDI registry that companies can use to store service definitions. WAS ND also provides a Web Services Gateway that acts as an intermediary between services available on an enterprise's intranet and those on the Internet. This feature lets an organization control the services it exposes and how to make public services available to local applications. The gateway also provides for uniform deployment of Web services delivered by WAS and by other means regardless of which protocols are used (e.g., SOAP/HTTP, SOAP/JMS, or Java over JMS). Support for the new JAX-RPC and JSR 109 (enterprise Web services) standards will appear in additional "technology previews." Programming Extensions WAS Enterprise includes a raft of interesting programming extensions, including the following enhancements to EJBs: -
SQLJ support for CMP beans (this feature is also in WAS XD) -
Specifying EJB access intent (concurrency strategy, type of access, read-ahead, and pre-fetch ) -
Defining CMP beans over procedural code rather than a DBMS -
Defining EJBs by composition of other EJBs -
Runtime creation of EJB (QL) queries -
Ability to incorporate nontransactional, or one-phase commit, resources into a transaction -
Container-managed messaging WAS Enterprise V5 also supports asynchronous execution of EJBs ” essentially enabling a "batch" subsystem for executing code. Building on this feature, WAS Enterprise also includes a scheduler for running work within WAS, along with support for callback notification of execution events or status. These features take WAS further along the road to providing more and more of the capabilities traditionally provided by enterprise operating systems. A significant feature in WAS Enterprise is the WebSphere Workflow facility. This feature lets you use a graphical workflow editor to assemble a variety of services, rules, and lower-level flows into a large-scale, transactional, potentially long-running business process. One of the key underlying concepts is that individual processes within a workflow define a "compensation" process that the workflow engine can invoke to undo work if a downstream process fails. It will be interesting to watch how the WebSphere workflow capability impacts the Lotus Domino product that has traditionally been IBM's strategic product in this area. JDK 1.4 Performance Improvements WebSphere Application Server V5 supports Java Developer Kit (JDK) 1.4. One of the hottest features of JDK 1.4 is its new server optimization feature. If you use the -server option, the JDK will scan loaded classes as they are being run, eliminate methods by inlining them, turn methods into their native code equivalents, remove content evaluations from loops , and perform a number of other code optimizations. Those optimizations can potentially yield a ten-fold performance improvement in CPU- intensive sections of code. wsadmin , WAS 5.0's Replacement for WSCP and XMLConfig WAS V5 replaces both the XMLConfig and WSCP administration utilities with wsadmin . So, with WAS V5, there is one utility to become familiar with rather than two. In addition, wsadmin is based on Java Management Extensions (JMX). JMX requires the use of MBeans, which are Management JavaBeans. JMX and MBeans follow a standard API, allowing tool vendors such as IBM and BEA to develop sophisticated interfaces to their Web application servers. Furthermore, developers also can easily create custom utilities for managing their application servers. wsadmin uses a JACL interface to WebSphere's JMX MBeans. JACL is basically a Java/TCL language. You can directly access WebSphere's MBeans from within wsadmin 's shell or with JACL scripts. The main MBeans available for WAS 5.0 are AdminControl , AdminConfig , and AdminApp . Those three MBeans each have a set of methods that you can access from wsadmin and JACL commands. All this JMX, MBean, JACL, and TCL material can be overwhelming, so let's experiment a bit. For example, to add a WAR file to WAS, you could use the following commands from wsadmin 's shell. First, start wsadmin with wsadmin.bat or sh wsadmin.sh; then enter the following from the wsadmin prompt key:
wsadmin> $AdminApp installInteractive C:\dir\to\some\test.war {- contextroot testuri}
Note that the dollar ($) symbol is not a Unix symbol but a JACL symbol. $AdminApp refers to the MBean, installInteractive is a method name, and the test.war and curly braced contextroot setting are parameters to the installInteractive method. The tool will then prompt you for several items:
Pre-compile JSP: [No]: No Directory to Install Application: []: Distribute Application: [Yes]: Use Binary Configuration: [No]: Deploy EJBs: [No]: Application Name: [test.war]: Create MBeans for Resources: [Yes]: Enable class reloading: [No]: Reload Interval: []:
After the installInteractive tool finishes, tell wsadmin to save the changes and exit by entering the following:
wsadmin> $AdminConfig save wsadmin> exit
Some of the wsadmin command sets get somewhat verbose, but you can put them in a file and reference the file with the hyphen " f " option:
c:\wasroot\bin\wsadmin.bat -f importwar.jacl
If you added that test WAR file to your WebSphere server, here's how to remove it:
wsadmin> $AdminApp unin`stall test.war wsadmin> $AdminConfig save
To show you a bit of the strengths of wsadmin and JACL, here's a JACL file that lists all your servers and the applications hosted by those servers:
<!--text or script--> # Begin listapps.jacl set cells [$AdminConfig list Cell] foreach cell $cells { set nodes [$AdminConfig list Node $cell] foreach node $nodes { set cname [$AdminConfig showAttribute $cell name] set nname [$AdminConfig showAttribute $node name] set servs [$AdminControl queryNames type=Server,cell=$cname,node=$nname,*] puts "node $nname server count: [llength $servs]" foreach server $servs { set sname [$AdminControl getAttribute $server name] set ptype [$AdminControl getAttribute $server processType] set pid [$AdminControl getAttribute $server pid] set state [$AdminControl getAttribute $server state] set jvm [$AdminControl queryNames type=JVM,cell=$cname,node=$nname,process=$sname,*] set osname [$AdminControl invoke $jvm getProperty os.name] puts " $sname process Id: $pid State: $state O/S: $osname" set apps [$AdminControl queryNames type=Application,cell=$cname,node=$nname  ,process=$sname,*] puts " $sname application count: [llength $apps]" foreach app $apps { set aname [$AdminControl getAttribute $app name] puts " $aname" } } } } # End listapps.jacl <!--text or script-->
The following is what will appear on your test server when you run the listapps.jacl script:
c:\wasroot\bin\wsadmin.bat -f listapps.jacl Number of running servers on node DefaultNode: 1 server1 (UnManagedProcess) has pid 3789; state: STARTED; on Linux Number of applications running on server1: 2 IBMUTC insuraceEAR test.war
Exploiting Dynamic Caching in WAS 5.0 At the heart of all caching features in WAS is the WebSphere Dynamic Cache. This caching feature provides a declarative-based caching service for J2EE applications. Dynamic Cache works within a WAS instance, intercepting requests to cacheable objects. If the object resides in the cache, it's served immediately; otherwise , the request is processed as normal, and the output is used to populate a cache entry. Cached content is generally served in a fraction of the time it normally takes to complete a noncached request. Web Page/Fragment Caching WAS Dynamic Cache provides caching for static and dynamic content of servlet and JavaServer Pages (JSP) pages and fragments making up Web pages. You cache servlets and JSPs in WAS declaratively and configure the caching by using a cache policy defined as an XML deployment descriptor included in your Web application. The cache policy file ”named Cachespec .XML ”is located in your Web module's WEB-INF directory along with the standard Web.XML file. When configuring the cache policy for Dynamic Cache, you must consider which servlets or JSPs to cache, what makes an invocation of that servlet or JSP unique, and when to remove content from the cache. Identifying Servlets or JSPs to Cache WAS Dynamic Cache parses the Cachespec.XML deployment descriptor on application startup and extracts from each <cache-entry>...</cache-entry> element a set of configuration parameters. Then, every time a new servlet or JSP is initialized (e.g., when the servlet is first accessed), the cache attempts to match that servlet/JSP to each cache-entry element to find the configuration information for that servlet. You can indicate which servlets or JSPs to cache by either specifying the class name of the servlet or using its relative URI. For example, if you want to cache the servlet class com.ibm.samples.MyServlet.class , use the <name> and <class> tags, as the following code shows:
<cache-entry> <name>com.ibm.samples.MyServlet.class </name> <class>servlet </class> </cache-entry>
Whenever a servlet of the specified class is initialized, WAS Dynamic Cache will match that servlet with the configuration for this element. The <class> tag identifies the type of object being specified in the <name> tag. For servlets and JSPs, the <class> tag always has a value of servlet. Other types of cacheable entities (e.g., commands) use different values for the <class> tag. You can also identify a servlet or JSP using its Web URL path . For example, the following specification defines a cache policy for a servlet with a mapping in Web.XML of /action/view:
<cache-entry> <name>/action/view</name> <class>servlet</class> </cache-entry>
The specification of the Web path is relative to the Web application's context root; therefore, the context root isn't included in the servlet's name. Identifying What Makes a Cache Entry Unique Most servlets and JSPs make use of a variety of inputs to generate unique dynamic content (otherwise, static HTML is used). This variable input usually comes in the form of request parameters, browser cookies, request headers, session attributes, path information, and request attributes from parent or peer servlets. To correctly cache a servlet or JSP, the cache policy author must identify the minimum set of input variables that makes a servlet's or JSP's output unique. Dynamic Cache supports declaring these inputs through the use of <cache-id> and <component> tags. For example, the following code shows that the viewQuote servlet's output is dependent on a request parameter named " ticker " and on a style attribute that was previously stored in the user's HTTP session.
<cache-entry> <name>/viewQuote </name> <class>servlet </class> <cache-id> <component type="parameter" /> <component type="session" /> </cache-id> </cache-entry
When a request is made to the URL http:/myhost/quoteapp/viewQuote?ticker=IBM by a user with an HTTP session attribute of style= frames , the following cache ID is generated:
/quoteapp/viewQuote:ticker=IBM:style=frames
Each request to the viewQuote servlet with unique ticker and style attribute values will produce a unique cache entry instance. WAS supports many different input variable types that you can use to uniquely identify requests. Table A-1 displays a list of valid types supported for use in generating cache IDs. Table A-1. List of Valid Types Supported for Generating Cache IDs | Input Variable Type | Valid Classes | Description | | Method | Command | Calls the indicated method on the command or object. | | Field | Command | Retrieves the named field in the command or object. | | Parameter | Servlet | Retrieves the named parameter from the request object. | | Session | Servlet | Retrieves the named attribute from the HTTP Session. | | Cookie | Servlet | Retrieves the named cookie value. | | Attribute | Servlet | Retrieves the named request attribute. | | Header | Servlet and Webservice | Retrieves the named request header. | | Pathinfo | Servlet | Retrieves the path information from the request. | | Servletpath | Servlet | Retrieves the servlet path. | | Locale | Servlet | Retrieves the request locale. | | SOAPEnvelope | Webservice | Retrieves the SOAP Envelope from a Web services request; an ID attribute of Hash uses a hash of the SOAP Envelope, and Literal uses the SOAP Envelope as received. | | SOAPAction | Webservice | Retrieves the SOAP Action header, if available, for a Web services request. | | ServiceOperation | Webservice | Retrieves the service operation for a Web services request. | | ServiceOperation Parameter | Webservice | Retrieves the specified parameter. |
Another important element in Cachespec.XML is the dependency ID ”a secondary key that describes when to invalidate a cache entry. Dependency IDs are composed of an optional static string and/or one or more input variables as used in cache ID generation. The static string and component values are appended together to form the dependency ID. One example of using a dependency ID is to invalidate a cache entry of a stock ticker when the stock price is updated, as we'll see in a moment. Removing Entries from the Cache After populating the cache with servlet and JSP content, the next important consideration is how to remove the content. Dynamic Cache removes content based on an explicit timeout , an explicit invalidation based on cache ID or dependency ID, and replacement due to being selected for eviction by the cache's replacement algorithm. Dynamic Cache manages the replacement algorithm, which uses a cache entry's priority and frequency of access to determine which entry to evict when the cache has exceeded its capacity. The cache policy in the code below sets each cache entry to have a timeout value of five minutes (300 seconds).
<cache-entry> <name>/viewQuote</name> <class>servlet</class> <cache-id> <component type="parameter" /> <component type="session" /> <timeout>300</timeout> </cache-id> </cache-entry>
There are three ways to explicitly remove entries from the cache: programmatically by cache ID, programmatically by dependency ID, and declaratively by dependency ID. Programmatic Invalidation An application can programmatically invalidate entries in the cache by passing a cache entry's ID as an argument into the cache's invalidateById API, as indicated in the following code:
import com.ibm.websphere.cache.*; public class Test { public void invalidate(String id) { Cache cache = DynamicCacheAccessor.getCache(); cache.invalidateById(id); } }
An easier (and preferred) way to invalidate cache entries is to use dependency IDs. Each cache entry can have one or more dependency ID(s) for use as invalidation keys. As described earlier, you can create dependency IDs declaratively inside the Cachespec.XML deployment descriptor, as indicated in the following code:
<cache-entry> <name>/viewQuote </name> <class>servlet </class> <cache-id> <component type="parameter" /> <component type="session" /> <timeout>300 </timeout> </cache-id> <dependency-id> stockTicker <component type="parameter" /> </dependency-id> </cache-entry>
When a request is made to the URL http:/myhost/quoteapp/viewQuote?ticker=IBM , the following dependency ID is generated:
stockTicker:IBM
To remove this entry from the cache, execute the following code snippet:
import com.ibm.websphere.cache.*; public class Test { public void invalidate(String id) { Cache cache = DynamicCacheAccessor.getCache(); cache.invalidateById("stockTicker:IBM"); } }
All cache entries that shared the stockTicker:IBM dependency ID are invalidated at the same time. Declarative Invalidation You can declare invalidation rules in the Cachespec.XML file to invalidate content based on dependency IDs. If the example in the code above had contained a servlet /updateQuote that updates the stock price, we could have defined the cache policy in the code below to declaratively invalidate the cached /viewQuote output for the updated stock ticker:
<cache-entry> <name>/updateQuote </name> <class>servlet </class> <invalidation> stockTicker <component type="parameter" /> </invalidation> </cache-entry>
Because we defined no cache ID rules for the /updateQuote servlet, its cache policy will invalidate only other cached content; its contents won't be cached. A Declarative Caching Sample: Rich Site Summaries Rich Site Summaries (RSS) is an XML document format that's widely used on the Internet to provide syndicated information summaries. Various Web sites make RSS files available for other sites to use to embed up-to-date information in their own Web pages. Many RSS-enabled Web sites provide current news headlines, stock quotes, and other dynamic content. The simple servlet in the following code retrieves an RSS file from a Web site, applies an eXtensible Stylesheet Language (XSL) transform to the document, and sends the result back to the client browser.
package com.ibm.websphere.samples.rdf; import java.io.IOException; import java.io.PrintWriter; import java.net.URL; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.xml.transform.Source; import javax.xml.transform.Transformer; import javax.xml.transform.TransformerFactory; import javax.xml.transform.stream.StreamSource; public class RDFServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Set content type for HTML. response.setContentType("text/html; charset=UTF-8"); // Output goes to the response PrintWriter. PrintWriter out = response.getWriter(); try { TransformerFactory tFactory = TransformerFactory.newInstance(); // Get the XML input document and the stylesheet, both in // the web application document directory. Source xmlSource = new StreamSource(new URL(request.getParameter("url")) .openStream()); Source xslSource = new StreamSource(RDFServlet.class.getResourceAsStream("/rss .xsl")); // Generate the transformer. Transformer transformer = tFactory.newTransformer(xslSource); // Perform the transformation, sending the output to the response. transformer.transform(xmlSource, new javax.xml.transform.stream.StreamResult(out)); } catch (Exception e) { // If an Exception occurs, return the error to the client. out.write(e.getMessage()); e.printStackTrace(out); } } }
The simple design of this servlet won't perform well because it's retrieving the RSS file from a remote Web site on each request and transforming the XML document to HTML on every page request. We can employ servlet caching to make the servlet perform better without any additional coding on our part. We simply need to create a cache policy that specifies the Servlet to cache , the parameters that make the servlet invocation unique , and the time we want the cached response to live in the cache. Here's a sample cache policy for the servlet:
<cache-entry> <name>/RDFServlet</name> <class>servlet</class> <cache-id> <component type="parameter" /> <timeout>600</timeout> </cache-id> </cache-entry>
The cache policy indicates that the /RDFServlet should be cached for 10 minutes and that the request parameter URL should be used in the generated cache ID. The following code shows a snippet of a sample RDF XML document providing current news on IBM:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/"> <item> <title>IBM extends leadership in identity and security ... </title> <link>http://www.ibm.com/news/us/2003/01/301.html </link> <description>IBM has announced that dozens of new customers ... </description> </item> <item> ...
Performance Comparison Using RSS Servlet Employing the RSS sample servlet, we conducted a set of performance tests to compare the throughput and response time of content delivered using WAS Dynamic Cache to noncached content. For this test, we set up all the components, including the servlet and RDF XML file, on the same local server. Caching the RDFServlet provides significant performance and scalability improvements. The cached servlet provides 10 times the throughput of the noncached version at the peak load of 1,000 clients . Also, the response time for the cached version is a fraction of the noncached one. Although this benchmark is fairly simple and may not reflect the results of a more complex application mix, these tests nevertheless indicate the potential for performance and scalability improvements you can achieve using WAS Dynamic Cache. Command Caching Command caching is a new feature in WAS that provides the capability to cache Java object instances. For example, we can cache a Java class that accesses database data or Enterprise Java Beans (EJBs) just as we cached the Web pages previously described. This provides a much finer-grain approach to caching data. Because you can combine servlet/JSP caching with Command caching, a flexible caching solution exists for almost any e-business application. Consider Command caching when the same application data is reused on multiple servlets or JSP pages. By caching the data before it's transformed into each page view, the application can avoid redundant re-retrievals or recalculations. Cacheable commands are stored in the cache for reuse with a similar mechanism for servlets and JSP files. However, in this case, the unique cache IDs are generated based on methods and fields present in the command as input parameters. For example, a GetStockQuote command can have a stock ticker as its input parameter; a unique cache ID is generated from the name of the command and the value of the stock ticker. Cacheable commands in WAS use the Command pattern programming model. Cacheable command implementations extend the com.ibm.websphere.command. CacheableCommandImpl base class. A command is invoked by first setting object attributes required for executing the command. This is followed by calling the execute() method on the Command bean. If there is a cache hit, the results of the execute() method invocation are served from the cache; otherwise, code within the execute() method is run, and the command's output properties are cached appropriately. After the execute() method has been invoked, results are obtained by invoking the getter methods on the Command bean. A complete example of Command caching is provided in the WAS Info Center at http://publib7b.boulder.ibm.com/wasinfo1/en/ info /aes/ae/rprf_commandxmp.html. Flexible, Portable Caching WAS Dynamic Cache provides a declarative method for caching Web page content and Java object data. The key benefit of declarative-based caching is that it requires no modifications to the application source code. This advantage, combined with Dynamic Cache's page, fragment, and object-based caching, results in a flexible yet portable means to enable caching for virtually any J2EE application. Dynamic Cache works within the WAS runtime, intercepting and processing requests for cacheable objects and content. Leveraging caching features in WAS can provide tremendous performance benefits for most e-business applications. | 