New SIP RFCs Supported by WebSphere 7 (Join, Replace and Update)

Support was added in WAS 7.0 for the following three RFCs: 3911 (Join Header) and 3891 (Replaces Header). These are very similar RFCs but are used for different purposes. Join is used to join an existing dialog and replaces is used to replace an old dialog with a new dialog.

From abstract of RFC 3911:

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring".

From abstract of RFC 3891:

The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: Attended Transfer and Call Pickup.

In terms of RFC 3911, the Join header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag) to the new dialog being created. From the JSR 116 perspective, the join header can be used to add a new dialog/SIP session to an existing SIP Application session in much the same way that an encoded URI is used. This is achieved by setting the call-id, to-tag and from-tag in the join header of the INVITE to match that of an existing dialog.

In terms of RFC 3991, the Replaces header contains information used to match and replace an existing SIP dialog (call-id, to-tag, and from-tag) to the new dialog being created. From the JSR 116 perspective, the join header can be used to replace an existing SIP session associated with a SIP Application Session with a new dialog/session. This is achieved by setting the call-id, to-tag and from-tag in the replaces header of the INVITE to match that of an existing dialog. Note that it is up to the application to send a BYE on the original dialog, the container will not take care of this for you so that from the JSR perspective there really is not much difference between Join and Replaces.

RFC 3311 support was also added to WAS 7. This RFC defines the use of the Update method. From abstract of RFC 3311:

UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.

Asynchronous Request Dispaching, Part 2

This is part two of my previous blog where I said I would discuss the differences between WebSphere’s Asynchronous Request Dispatcher and the Asynchronous Servlet Proposal from the Java Community Process.

The initial Servlet EG proposal introduced a different model of asynchronous servlet processing through suspend, resume, and complete methods. The basic idea is to allow a servlet to initiate asynchronous operations and re-dispatch to the same servlet once these operations are complete. A suspend tells the container to disable the response so that additional logic in the initial dispatch doesn’t affect the response. Meanwhile, the application programmer uses another thread to do some asynchronous work required by the request. Once that is complete, resume is called which tells the container to schedule a dispatch of the request back through the filters and servlets. Alternatively, complete can be called to simply close the output without a re-dispatch. This has been debated thoroughly, and there are still competing proposals which are arguably less powerful. However, since this is the only publicly discussed proposal, I will use that for comparison.

I will present a few scenarios and show the way they can be solved in ARD and the Servlet EG proposal. This should help you understand the pluses and minuses of using one paradigm over the other.

Example 1: A request needs to print out a table that will be filled in with the results of two slow queries to external resources.

EG Proposal:

1. Original servlet prints out the table up to the point query 1 results are required

2. Suspend the request

3. Kick off query 1

4. Resume/re-dispatch the request after query 1 completion

5. Write results of query 1

6. Write next portion of the table

7. Suspend the request

8. Kick off query 2

9. Resume/re-dispatch the request after query 2 completion

10. Write results of query 2

11. Finish writing the table from the original servlet

ARD:

1. Original servlet prints out the table up to the point the query results are required on thread 0
2. Do async include on thread 1 to the servlet that does query 1
1. Concurrently, thread 0 continues writing the table
3. Do async include on thread 2 to the servlet that does query 2
1. Concurrently, thread 0 continues writing the table
4. Thread 1 returns and flushes content to the client up to query 2
5. Thread 2 returns and finishes the response

ARD Advantages:

1. ARD can finish sooner because query 1 and 2 are running simultaneously. The EG Proposal kicks them off 1 at a time.
2. With the EG Proposal, the application programmer could emulate query 1 and 2 running simultaneously, but they would have to do their own threading.
3. With ARD, the original thread can write out the full outline of the page because the container has the smarts to go back in and find the correct position for the response content. The EG Proposal does not.
4. The EG Proposal would have more issues with tracking state because the resume goes back through the filter and servlet request handling methods. The filters and servlets would have to make sure they are not duplicating output that was written before the initial or subsequent suspend.
5. Order of completion is not important when using ARD.

ARD Disadvantages

1. ARD only allows asynchronous operations inside of includes.
2. More threads are used.

Example 2: A request requires the results of two slow queries to external resources where state from query 1 is required for query 2 to work.

EG Proposal:

1. Enter the original servlet
2. Suspend the request and kick off query 1
3. Resume the request after query 1 completion
4. Re-enter the original servlet
5. Suspend the request and kick off query 2 with state from query 1
6. Resume the request after query 2 completion
7. Re-enter the original servlet and finish

ARD:

1. Enter the original servlet using thread pool A.
2. Do async include using thread pool B to the servlet that does query 1

1. Concurrently, the original servlet processing continues

3. Thread from thread pool A waits for results from query 1.
4. Do async include using thread pool B to the servlet that does query 2
5. Query 2 returns and finishes the response

ARD Disadvantages:

1. Because ARD does not have the ability to re-dispatch, we end up blocking the original thread to wait on the results of query 1.

From these examples, I conclude that ARD is best used for executing requests that each have multiple asynchronous operations that are independent of one another. Also, the context propagation that ARD provides is an added benefit. Similar context propagation may be introduced as an additional specification in Java EE 6, but it will not likely be a prerequisite for asynchronous servlets.

There are certain caveats that should be considered in both the ARD and RRD features and they are not one size fits all solutions. Feel free to check out details in the Information Center. There is also a good article on RRD at Developer Works.

Using WS-Policy to configure WS-ReliableMessaging

My good friend Eleanor Harley sent me this link to 'Real Snail Mail' the other day. It seems like a fantastic idea; probably carbon neutral although arguably not the simplest thing that could possibly work. It is however an entertaining use case for WS-ReliableMessaging which I have been working on for WebSphere Application Server v7.0. Those snail's squish very easily, and without your Acknowledgement snail you'd never know if that vital message was delivered, or had come under some salty security attack.

Did I mention that WS-ReliableMessaging has just shipped in WebSphere Application Server v7.0? Previously delivered as part of the Web Services Feature Pack for WebSphere Application Server v6.1, the function has been enhanced by conformance to the WS-I Reliable Secure Profile and the impact of WS-Policy on configuring WS-ReliableMessaging.

Using WS-Policy with WS-ReliableMessaging provides improved levels of flexibility on when this quality of service is applied to your Web Service messages. We have introduced a new 'strictlyEnforceWSRM' property that can be applied to the client and the service.

It enables you to chose whether your service and client want to enforce Reliable Messaging or simply support Reliable Messaging. WS-Policy then determines what the common configuration option is between the client and server. For example, if your server policy states that it supports WS-ReliableMessaging , and the client is configured to enforce WS-ReliableMessaging , then WS-ReliableMessaging will be used. However, if the client has no WS-ReliableMessaging configured then the server will not use it.

Finally, unlike Real Snail Mail, we have been working hard on WS-ReliableMessaging performance this release as well. I hope you'll appreciate the results.

Using the Spring Framework with WebSphere Application Server v7.0

IBM has been working with SpringSource for a few years now to ensure that WebSphere Application Server continues to be an excellent platform for customers wishing to use the Spring Framework. WebSphere Application Server v7.0 is no exception, and there are a number of new features that you can take advantage of.

AspectJ support
From Spring 2.5 onwards, Spring’s AspectJ support can be utilised. In this example we first define a <tx:advice> that indicates that all methods starting with "get" are PROPAGATION_REQUIRED and all methods starting with "set" are PROPAGATION_REQUIRES_NEW. All other methods use the default transaction settings.

<tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="get*" propagation="REQUIRED" read-only="true" /> <tx:method name="set*" propagation="REQUIRES_NEW" /> <tx:method name="*" /> </tx:attributes> </tx:advice>

Then use <aop:config> to apply those settings to any executed operation defined within the class MyService.

<aop:config> <aop:pointcut id="myServiceOperation" expression="execution(* sample.service.MyService.*(..))"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="myServiceOperation"/> </aop:config>

Annotation based configuration
Another alternative mechanism for declaring transaction settings is to use the Spring annotation-based transaction support. This requires the use of Java 5+, and therefore cannot be used with WebSphere Application Server V6.0.2.x.
First add the following to the spring.xml configuration:

<tx:annotation-driven/>

Any methods that require transactional attributes should then be marked with the @Transactional annotation:

@Transactional(readOnly = true) public String getUserName() { ...

JPA configuration
The EJB 3.0 specification defines the Java Persistence API (JPA) as the means for providing portable persistent Java entities. WebSphere Application Server V7 and the WebSphere Application Server V6.1 EJB 3 feature pack both provide implementations of EJB 3 and JPA; it is also possible to use the Apache OpenJPA implementation of JPA with WebSphere Application Server V6.1

Using an Annotation style injection of a JPA EntityManager is possible:

@PersistenceContext private EntityManager em;

You need this XML code to turn on EntityManager injection in the Spring XML configuration:

<!-- bean post-processor for JPA annotations --> <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>

JMS templates
For JMS message sending or synchronous JMS message receipt, JMSTemplates can be used. This includes the use of Spring’s dynamic destination resolution functionality both via JNDI and true dynamic resolution.

The following example shows the configuration of a resource reference for a ConnectionFactory. This reference is mapped during application deployment to point to a configured, managed ConnectionFactory stored in the application server’s JNDI namespace. The ConnectionFactory is required to perform messaging and should be injected into the Spring JMSTemplate.

<resource-ref> <res-ref-name>jms/myCF</res-ref-name> <res-type>javax.jms.ConnectionFactory</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>

There is now a defined JNDI name for your ConnectionFactory within the application that can be looked up and injected into the JMSTemplate:

<jee:jndi-lookup id="jmsConnectionFactory" jndi-name=" jms/myCF "/> <bean id="jmsQueueTemplate" class="org.springframework.jms.core.JmsTemplate"> <property name="connectionFactory"> <ref bean="jmsConnectionFactory"/> </property> <property name="destinationResolver"> <ref bean="jmsDestResolver"/> </property> ... </bean> <!-- A dynamic resolver --> <bean id="jmsDestResolver" class=" org.springframework.jms.support.destination.DynamicDestinationResolver"/> <!-- A JNDI resolver --> <bean id="jmsDestResolver" class=" org.springframework.jms.support.destination.JndiDestinationResolver"/>

At run time, the JMSTemplate can locate destinations based on either their JNDI name (as configured in an application resource reference) or through "dynamic resolution," based on the administrative name of the destination configured in WebSphere Application Server; for example, for the JMS myQueue queue, bound to a JNDI reference of jms/myQueue:

JNDI resolution:
jmsTemplate.send("java:comp/env/jms/myQueue", messageCreator);

Dynamic resolution:
jmsTemplate.send("myQueue", messageCreator);

If you have been using the Spring Framework with WebSphere Application Server already, you may have come across this developerWorks article http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

It has had a facelift recently, and is updated with new content including further configuration details of using WebSphere Application Server with the Spring Framework.

Asynchronous Request Dispatching, Part 1

This is my first blog so I should say a little about myself before I get into things. My name is Maxim, or Max for short, and I’ve been working on the WebContainer since 2003 in various capacities. In Version 7 of WebSphere Application Server (WAS), I acted as the WebContainer architect and the Servlet Expert Group (EG) member representing IBM.

If you have been following the latest in Servlet technology, you would know that the expert group has finally decided to try to standardize asynchronous servlet support for Servlet 3.0. This came as somewhat of a surprise because I had already been working with my colleague Erinn Koonce on a related feature for WAS version 7 called the Asynchronous Request Dispatcher (ARD). Naturally, as options are discussed in the Servlet EG, I compare them to ARD and think about why you’d want to adopt one over the other.

ARD came about as a result of another feature we put in WAS Version 6.1 called the Remote Request Dispatcher (RRD). RRD was a requirement from WebSphere Portal to help them support Web Services for Remote Portlets (WSRP). The problem that WSRP tries to solve is that in some Portal environments one problem web module can bring down the entire application server and its applications. The natural response is to just add more resources to the deployment. However, this may be overkill for the web modules that are well behaved. Since many applications consist of multiple web modules that interact with one another through request dispatcher includes, each web module had to reside on the same server.

RRD provided the mechanism to separate up these applications into other servers or clusters without having to rewrite the interaction logic between web modules. However, there was a major drawback resulting from the cost of packaging and sending of the metadata across the network that each remote request dispatch required. To help alleviate this, Portal wanted a mechanism to execute these remote request dispatches asynchronously. Thus, ARD was born.

The Asynchronous Request Dispatcher does the following:

• Allows request dispatch includes to execute asynchronously and concurrently
• Maintains proper ordering of response output
• Propagates request and thread context
• Allows decoupling of the dispatching of the request with the position where the content should be inserted
• Allows for client side aggregation of results

In my next blog, I will discuss the differences between the two proposals.

New WAS v7.0 Web Services Functionality

The Feature Pack for Web Services that WebSphere released on top of WebSphere v6.1 dropped a large chunk of new Java EE 5 functionality related to Web Services in an early fashion. However, version 7.0 completes that work plus introduces some new capabilities that make it easier to developer web services for application developers.

The work (from a technology perspective) focused on 2 specific areas:

• JCP-based programming model updates
• Continuation of filling out the Web Services Roadmap

From a JCP-based perspective, the support for JAX-WS and JAXB have been upgraded from the Feature Pack to their 2.1 equivalents. This adds several minor maturity improvements in both cases (such as @XmlSeeAlso support for type substitution) as well as support for a WS-Addressing API for usage within JAX-WS. What this means for end-users is easier and better support for using/developing web services. From an integration perspective, version 7.0 now allows EJB 3.0 developed beans to also be exposed natively as web services. Lastly, v7.0 also introduces support for JSR 109 metadata. This allows annotation information to be overridden, handlers to be defined, and allows testcases like common JAX-WS providers to be used with different types of metadata.

Extending beyond what's in just the JCP specification, the combination of EJB 3.0 beans and JAX-WS annotations also brings support for SOAP/JMS-based beans to JAX-WS-based services. This makes it consistent for those developers looking to use existing reliable transports as a way to send/receive their web services requests. As part of that support, we are tracking the emerging SOAP/JMS standard being developed at W3C.

With respect to filling out the Web Services roadmap, WebSphere v7.0 upgrades support for numerous OASIS and W3C specifications to their official standardized levels (as well as providing support for their pre-OASIS levels for versions previously introduced within WebSphere). OASIS WS-AtomicTransactions and WS-BusinessActivity were both upgraded to their 1.1 levels (so WebSphere supports both 1.0 and 1.1 levels now). The OASIS WS-Trust and WS-SecureConversation specifications have also been upgraded to their OASIS 1.3 levels as well as support for OASIS WS-SecurityPolicy 1.2 being introduced. The OASIS Kerberos Token Profile 1.1 is also now supported in v7.0 providing support for single signon with Keberos tokens.
With the addition of WS-SecurityPolicy also means that we've introduced support for W3C's WS-Policy 1.5 specification. As such, WebSphere now supports the ability to expose WS-Policy assertions for services exposing WSDL endpoints supporting the qualities of service attached at that endpoint (including Security, ReliableMessaging, Addressing, and Transactions). That information is available via the typical ?wsdl exposed for the service as well as a WS-MetadataExchange request to the service endpoint too.

To continue focusing on improving the ease-of-use experience for WS-Policy, WebSphere has also exposed the ability on the client side to configure itself based on the policy assertions exposed in the published service's WSDL file. This makes it easy to have the client configure itself (or calculate an effective policy based on the clients capabilities).

In addition to the standards upgrades, v7.0 continues to focus on other enhancements to the existing functionality (both functional and non-functional) which continues to enhance the maturity and ease-of-use to the development and adminstration of web services. For example, WS-Notification services now can take advantage of PolicySets. PolicySets themselves have been enhanced to support naming the configurations as well as the bindings. These can now be imported and exported easily to allow these pre-configured systems to be moved from one topology to another. For example, moving from a development environment to a test environment to a production environment.

Andrew Spyker had already talked about some of the dramatic performance improvements introduced in v7.0 for web services.

I guess to make a long story short, there's lots of good new stuff in the web services space. I hope that you find the links provided above as a good starting point to quickly get pointers to more information on the topics discussed.

New WAS v7.0 SIP Function

In our last major release of WebSphere Application Server (WAS), we released our Session Initiation Protocol (SIP) functionality. If you need more background on that, you can read this article on developerWorks or check out this presentation to a WebSphere Users Group. In v7.0, we added several pieces of function and further increased our performance.

First, we added support for the following RFCs:

• 3263 - Locating SIP Servers
  
• 3311 - The SIP Update method
  
• 3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
  
• 3891 - The SIP Replaces Header
  
• 3911 - The SIP Join Header
  
• 4475 - SIP Torture Test Messages
  

In WAS v6.1, we had supported RFC 3263 aside from section 5 but completed section 5 in this release. The final RFC there, the SIP torture test messages, refers more to a testing effort than function. This torture testing combined with our already rigorous telco carrier grade testing will help WAS v7.0 be one of the most stabile SIP application servers on the market.

Beyond the additional standards support, our SIP Proxy which fronts the application server had several enhancements. It can now support DMZ deployments as discussed here, clustering of the proxy servers when behind the firewall, and an improved load balancing to further reduce call loss in some error conditions associated with retransmissions. Finally, also in our converged Servlet Container, users will notice that the digest authentication support has been made much better.

What's NEW in WebSphere v7

Just wanted to drop a quick post announcing a technical chat for WebSphere version 7 with 6 of our lead architects/developers in WebSphere Application Server and Tom Alcott from our Technical Sales Support Team which will take place on developerWorks. It is scheduled for October 16th, 1-3 pm Eastern time. It's a good opportunity to ask your questions directly to WebSphere lead architects and developers.

Here are links to the developerWorks PodCast site and a little teaser posted as a podcast announcing the chat.

DMZ-hardened WebSphere Proxy

One of the main frustrations for customers who have wanted to move from legacy proxy solutions such as the IHS plug-in or Edge Caching Proxy to the WebSphere Proxy (introduced in WAS 6.0.2) has been the additional network hop needed for deployment. The WAS proxy offers significant advantages over the legacy solutions in terms of usability, performance, and systems management integration (see Erik Burckart's Article). However, it is not recommended for deployment inside of a demilitarized zone for security reasons. Thus, deployments with the WebSphere Proxy often required an extra network hop from a DMZ-hardened solution to the proxy itself. The rules have changed in WAS v7.

In WAS v7, customers have access to a DMZ-hardened version of the proxy server. This server ships on a separate installer that contains a subset of the full WAS ND installation. It contains a few notable differences from the ND install that make it suitable for installation in a DMZ:

• No JDK: The secure proxy utilizes only the JRE, so no compiler is available in the DMZ.
• Fewer Listening Ports: The security proxy can be configured to have as few as two listening ports (HTTP and HTTPS).
• Slimmer set of jars: Since the proxy does not require certain functionality (e.g. web container, EJB container, web services, etc.), jars containing this function are omitted from the install for security and memory footprint purposes.
• Slimmer set of active services: The secure proxy utilizes runtime provisioning (new in v7) to start only the required services. Services like JNDI, application install, and ORB are not started.
  

In addition to these security features, customers can also toggle certain pieces of function on or off to increase usability or security. Four pieces of function can be toggled for enhanced security/usability: Startup permissions, error handling, remote administration, and dynamic routing.

The DMZ Secure Proxy Server is a nice upgrade over the IHS plug-in and Edge Proxy in terms of feature set, scalability, performance, and WAS integration and I am very excited to see customers begin reaping the benefits of deploying it.

Join me in Harrisburg, PA on the 15th to talk about BPM and SOA

I will be providing development lab and architecture support for one of the many events that are part of the Smart SOA World Tour happening across 100 cities in 10 days. I'm helping out at the one in Harrisburg, PA on Wednesday, October 15th. I just happened to have grown up very near to Harrisburg. Please feel free to join us if you're in the local area. Here is the link to the event. Andrew Sweet will be covering Business Process Management powered by Smart SOA. Christel Slater will be covering Business and IT Alignment. Edward S. Bowlen from Pennsylvania Department of Labor & Industry will also be speaking.

v7 UPDI "Update Installer" and v7 IF "Installation Factory" (a really nifty tool)

Both the WebSphere Update Installer (UPDI-v7) and WebSphere Installation Factory (IF-v7) are tools that ship with the WebSphere product, and they are both downloadable and/or updateable to newer versions from the WebSphere support and download site. Customers have commented that they hate having to install and manage multiple versions of such tools, so when the v6.1 tools were updated to support WebSphere v7 there was a major design emphasis on ensuring that each of the resulting v7 tools could also be used to replace the existing v6.1 tools in a mixed v6.1 and v7.0 environment (you don't need both 6.1 and 7.0 copies). In other words, UPDI-v7 can update either v7 or v6.1 servers, and IF-v7 can generate either v7 or v6.1 Customized Install Packages (CIPs) and/or Integrated Install Packages (IIPs).

Since UPDI is the only way to update WebSphere servers, every customer already knows about it (if you really don't, please immediately see the WebSphere v7 InfoCenter UPDI information).

Many (most?) customers have still not discovered the nifty "Installation Factory" (IF) tool. In a nutshell, IF is a way for a customer to merge an initial WebSphere 6.1.0.0 (or 7.0.0.0) plus a FixPack (say 6.1.0.17) plus multiple interim fixes (iFixes) into a single, smaller, install called a "Customized Install Package" (CIP). The resulting CIP can be used to do a "scratch" install of that combination, or it can do a "slip" upgrade of an existing installation. IF is even capable of merging several product CIPs into a combined single "Integrated Install Package" (IIP). If you are not familiar with IF the I suggest you browse the WebSphere v7 InfoCenter IF information, and also read the DeveloperWorks article "Using Custom Installation Packages to install and update WebSphere Application Server in large development environments". Even if you are still on v6.1, you can download and use the IF-v7 to great advantage. Give the preceeding IF-v6.1 article (but still fully applicable to v7) a read and I guarantee you will be pleasantly surprised. The most common comment I hear from customers is "why didn't someone tell me about IF" - so, you have now been told. :-)

64-bit Performance Thoughput/Memory Improvements in WAS V7.0

I'll use the below graphs to tell a story of 64-bit performance.  In the past, your WAS application was using 32-bit memory spaces.  Hardware vendors started making machines 64-bit.  You moved your application to a 64-bit hardware/OS platform hoping you'd get improved performance.  Instead you saw the application decrease in performance to 85% of the original 32-bit performance and the heap requirements went up by almost 50% (shown by the comparison between the first bar and second bar in each graph).  Ouch!

The reason for the heap requirements going up is simple.  The memory references are now twice the size as before.  The reason for this decrease in performance is actually very much related to the increase in memory.  The memory references under the covers of Java became twice the size increasing the size of memory structures in the WAS runtime and your application's objects.  Unfortunately the processor memory cache sizes didn't get larger at the same time.  This means more memory cache misses, which means more busy work for the hardware dealing with the larger memory, which means worse application performance.

We introduced 64-bit support in WAS 6.1 for customers that needed to store database caches, etc. in memory that were larger than 32-bit addressability.  Of course, 64-bit support for these applications is a major win as it's always faster to do things in memory as compared to trying to do this sort of processing in 32-bit while offloading to disk.

In WAS V6.1, we introduced a simple answer to the problem for users who really only needed 32-bit address spaces.  We started to support WAS 32-bit on 64-bit OS'es essentially avoiding the problem (which moves you back to the first bar in each graph).  However, that didn't help users who needed process sizes larger than the 32-bit OS process size limit but less than full 64-bit addressability (who really needs 16.8 million terabytes?!) and made managing deployments that needed both 32-bit and 64-bit applications very complex.

In WAS V7.0 we introduce compressed reference (CR) technology.  CR technology allows WAS 64-bit to allocate large heaps without the memory footprint growth and performance overhead.  Using CR technology instances can allocate heap sizes up to 28GB with similar physical memory consumption as an equivalent 32-bit deployment (btw, I am seeing more and more applications that fall into this category -- only "slightly larger" than the 32-bit OS process limit).  For applications with larger memory requirements, full 64-bit addressing will kick in as needed.   The CR technology allows your applications to use just enough memory and have maximum performance, no matter where along the 32-bit/64-bit address space spectrum your application falls.

So returning to the original problem of 85% performance and almost 50% memory growth, how does 64-bit WAS V7.0 measure up on the original application?  The third bar on the chart is what you get "out of the box" on WAS V7.0 64-bit.  Now you'll see performance within 5% of 32-bit performance with less than 3% growth in heap requirements.  Rather impressive what a Java virtual machines can do with no changes to the application!  Let's see a C/C++ program do the same so easily.

I'm interested in feedback from users who have tried WAS 64-bit (either with WAS V6.1 or 7.0).