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).

EJB 3.0 Performance Improvements in WAS V7.0 (up 23%)

EJB 3.0 was actually available for some time on top of WAS V6.1 in the Feature Pack for EJB 3.0, but now it exists in WAS V7.0 as well.  EJB 3.0 in my mind is all about making the developer's life simpler (annotations, test outside of container, etc.) along with giving us a better model for more performant persistence.  You can see all new features added to EJB 3.0 in WAS V7.0 (including performance features) in Kevin's blog post.  Given this is the second major release of EJB 3.0 for WebSphere, performance of EJB 3.0 on WAS is top notch.  You'll also see that we've recently added an implementation using the standard JPA caching functions to allow caching via WebSphere eXtreme Scale (Formally known as WebSphere Extended Deployment Data Grid) which is a distributed in-memory data grid.

In working on persistence performance in WAS V7.0, we used the Apache DayTrader application with some IBM tweaks.  There are two versions of DayTrader of interest (1.2 which uses EJB 2.1 and 2.0 which uses EJB 3.0).  There are other changes as well to move DayTrader 2.0 to Java EE 5, but most don't have deep performance impacts.  Really, the big change from a performance perspective is the implementation of the persistence layer.

The results of all of the new WAS V7.0 features is a very performant EJB 3.0 implementation that outpaces the EJB 2.1 performance by 23% as shown in the below chart.  This is a rather impressive improvement considering the EJB 2.1 implementation has been grooved by years of leading IBM benchmark results in SPECjAppServer.  It is also worth noting that the below chart is EJB 2.1 to EJB 3.0 heads up (actually both are measured on WAS V7.0).  If you are migrating from WAS V6.1 or earlier the percentage improvement would be far greater.

Again, I'm interested in feedback from users who have tried the new engine.

What's so great about WS-Policy?

It's just over a year now since the WS-Policy Specification http://www.w3.org/TR/ws-policy/ moved to RECOMMENDED, and last week WAS 7.0 went GA with support for this spec.

So, exactly what does WS-Policy give us? Conceptually, it's pretty simple: a standard XML format for expressing requirements or capabilities (policies) of a system. To be more precise, it just provides a framework for expressing policies. This is an excellent model for flexibility and extensibility because you can add policies of any 'flavour' within this framework.

A policy flavour or 'domain' might be a proprietary policy - for example, a policy relating to a logging. Alternatively, you can express policies relating to pre-canned standard domains such as WS-SecurityPolicy. So this opens a whole new opportunity: so long as communicating systems understand WS-Policy and the same policy domains, they can exchange information about requirements and capabilities in a standard format. Here are some example uses of this:

• A client could configure itself based on a server's configuration (even if the client and server use different proprietary formats for representing their configurations internally)
  
  
• In a large, heterogeneous environment, a standard policy configuration for many machines could be held in a central repository
  
  
• A service endpoint could advertise its requirements to all its clients in a non-proprietary way

The WS-Policy framework also provides an operator ("All") for combining policies and an operator ("ExactlyOne") for expressing more than one possible option (a policy choice). It may be useful for a service to advertise a choice of requirements, for example, in order to satisfy differing capabilities of a number of clients. This allows for a loose coupling in terms of configuration - because the configuration of an interaction with a service may be flexible and depend on the client.

Finally, WS-Policy provides an algorithm (called intersection) for combining 2 policies together to find an acceptable policy for all parties. So if a client has requirements but also needs to conform to the requirements of the service, you can take the two policies, perform intersection and out pops a policy acceptable to both the client and service.

More about ws-policy support in WAS 7 to follow...

Web Service Performance Improvements in WAS V7.0 (up to 3x)

Two weeks ago, I said I'd be doing a weeklong series of posts on WAS V7.0 performance.  A week late, but here we go.  I guess I can say I delayed until WAS V7.0 was generally available, which it is now (trial download here)!  WAS V7.0 should be available by other supported download methods as well.

There are many impressive areas of performance improvements in WAS V7.0, but I'll start with the one nearest and dearest to my heart - Web Services.  In the past, I talked about web services performance through the years.  I mentioned a possible follow-up blog post on what Feature Pack for Web Services performance.  I never followed up on that (hrm, a theme in my slow blogging), but now that the same code is available in WAS V7.0, I will.  In fact, we've made even more improvements to web services performance in WAS V7.0 that would truly make the "performance through the years" chart from my previous blog post much more impressive.

WAS V6.1 supports the J2EE 1.4 JAX-RPC web service programming model.  Last year, we added Java EE 5 support for the JAX-WS web service programming model (expanded functionality, standards support, easier programming model, and enhanced management support for services) through the Feature Pack for Web Services.  While WAS V7.0 continues support of both the JAX-RPC and JAX-WS programming models so that existing JAX-RPC web services applications deployed on previous versions of WebSphere will run on V7 unmodified, the development and performance resources were almost exclusively dedicated to the JAX-WS work.  We encourage customers to move to this new programming model to take advantage of the new features as well as the significant performance gains.  Many customers I know of have moved to the Feature Pack for Web Services already, but now that it's natively supported in WAS V7.0, I expect even more customers to make a move from JAX-RPC to JAX-WS.

The chart below compares WAS V6.1 JAX-RPC performance to WAS V7.0 JAX-WS performance.  JAX-WS web services significantly outperform JAX-RPC web services for all message payload sizes shown.  For a 3k(input)/3k(output) message size, JAX-WS achieves a 70% higher throughput and for 10k/10k message size JAX-WS achieves over 2x higher performance.  For 10k/3k, 10k/10k, 100k/100k JAX-WS achieves over 3x/2.5x/2.5x higher performance, respectively.

There are many reasons for these performance gains, but the most significant one is the optimized data binding using JAXB in JAX-WS.  JAXB provides JAX-WS the framework to unmarshal XML documents into Java objects or marshal Java objects into XML.  We have done very impressive optimizations in our JAXB implementation to achieve these performance gains, well beyond what most JAXB implementations can do with StAX or SAX.  Getting high performance XML parsing combined with JAXB's full support for XML Schema is an impressive accomplishment.

Some things that matter to you specifically:  This is a primitive benchmark as it only measures web services performance (no business logic).  Therefore, your application using web services will not go 2-3 times faster just by switching to JAX-WS and JAXB, but it should markedly improve.  Specifically the additional latency involved in exposing business logic to web services and XML should go down by 1/2-2/3, which in many scenarios is substantial.  Also, even though you can handle XML yourself in JAX-WS by getting the data as a stream or DOM, it's best if you use JAXB as you'll get the most performance benefit of our optimizations.

I'm interested in feedback from users that have tried the new engine.

Need help with WebSphere scripting..?

In WebSphere 7.0 the main focus from administration perspective is on making things easy to manage in a complex environment. Over next few days I will be sharing my views on various such features like highly scalable management topology, business level application, properties file based configuration etc. I think one of the most important features for administrators in WebSphere 7.0 is the new jython script library.

WebSphere scripting is a detailed subject with lots of capability. I have had administrators often ask me - "I am new to WebSphere .. or I used to use console UI but now we want to automate all of our WebSphere administration. Where do I begin? .. or I know my script command works but how can I confirm that it covers all the scenarios or topologies?". The jython editor in Rational Application Developer goes a long way in boosting productivity of WebSphere script developers. The script library that we ship with WebSphere 7.0 is another good source for administrators trying to automate WebSphere administration tasks. The script library contains a number of good scripts for common administrative functions such as -

• Application management: install, uninstall, update, start, stop
• Server/Cluster management: create, delete, update, start, stop server or cluster. Need a quick example to set a server JVM property or trace specification? You will find it in there.
• Resource Manipulation: create/manipulate resources for JDBC, J2C, JMS and so on
• Security configuration: manipulate authorization for users and groups
  

You can call these scripts from your script code or just copy them and modify any way you want. I encourage you to take a look at these scripts to see how they check preconditions before executing commands or perform exception handling etc. Automation is a big factor in WebSphere administration and we are striving hard to make it easier for our administrators.

- Ajay

To run WebSphere v7, first you have to install ...

Basically "Install" is one of those things people want to be able to ignore - they want it just work and be done with it. So, a major part of v7 install work was to keep everything working the same way and as well as v6.1 installs. We must have succeeded since most users may not notice any obvious difference, although under the covers there are several improvements. There are minor GUI changes to make the various installers (WebSphere, HTTP Server, plugins, client, Proxy Server, FeaturePacks, etc) more similar to each other in appearance and behavior.

Linux/AIX/HPUX/Solaris non-root installs are fully supported, which sounds fairly straight forward but had huge internal impacts. As well, installation performance has been increased such that the significantly enhanced v7 servers still install in the same time as the previous v6.1 servers. Keeping install performance (time) the same while laying down several hundred more megabytes was a challenge, but the team worked to find many places where a few seconds here-and-there could be shaved, and the net result is almost identical time for v7 versus v6.1 installs.

So, the "Install" should have "no surprises" - the real changes are WebSphere v7 itself. As soon as you can get it, give it a spin ...

Have it your way

One of the trends I've been seeing a lot of lately in the industry is a movement towards something I would call "build to order". Given that this is something that we see in a number of industries (restaraunt meal preparation, automobile options, custom motorcycles, etc.), it seems no surprise to me that the computing industry wouldn't also be affected by this. We all want to have it our way, not what is provided for the mass of humanity. In a highly competitive industry, having custom solutions can provide differentiation which may be crucial in a value chain. On the other hand, it can also hinder your ability to adapt if it means creating a new custom solution for every customer.

WebSphere Application Server (WAS) has been on a path for some time now to enable custom solutions. Starting way back with WAS 6.0 (2004), astute system administrators may have noticed that we have started packaging the WebSphere runtime in OSGi bundles located in the "plugins" directory. What OSGi does is allow for some separation of concerns and decoupled code selection, as well dynamic hook points for integration. This, in turn, allows WAS to be configured in a variety of ways that were difficult or impossible in the past.

Take, for example, the use of open source. When used in an application, it can help the application developer achieve their goals in a rapid way by utilizing the efforts of the open source community rather than reinventing similar function. The same could also be said for the server. If you are wondering about how much open source gets used in creating WAS, try taking a look at the /lafiles/notices file. Having all this open source in the server can be both good and bad. If an application developer wants to take advantage of it, it's there. However, if it's not the version of the open source the developer wants to use, it can be bad. This is where OSGi's separation of concern can come into play. OSGi modules allow for restricted views of the code in the OSGi bundle. Use of OSGi bundles allows servers to take advantage of open source without actually exposing it to applications. The server's use of open source will not interfere with application's that bundle and use open source. WAS version 7 has refactored much of its runtime to hide open source intended to be used by the runtime. This is coupled with new managed shared libraries, isolated shared library classloaders, and the repackaging of open source into the /optionalLibraries directory to make it much easier to deploy and configure applications. Applications can either bundle the open source they want, or manage multiple shared lib versions of it used by applications in WAS version 7.

Another area where OSGi has helped is in server footprint. OSGi allows for dynamic code use and enables the possibility of load on first use. What this means is that you now have the option of configuring the server to use only as much of the runtime as is necessary. OSGi alone can't do this, so a fair amount of work has gone into getting the WAS version 7 runtime enabled for dynamic provisioning, some of which can be automated, and some of which must be manually configured. One of the most frequent questions I get around this is how much will it reduce the server footprint. As with all performance related questions, it will depend on the scenario. I will say that we've only touched the tip the iceberg for possibilities here and I think we've got a good head start on the competition. For more details, stay tuned to hear from Andrew Spyker as he posts updates on WAS performance.

WebSphere Application Server V7.0 Messaging

WebSphere Application Server V7.0 contains a number of enhancements to the service integration technology (SIBus) that make it easier to set up and manage, improve performance and provide greater flexibility for messaging applications.

To help you discover the new features contained in V7.0 we'll be blogging them at WebSphere and Messaging over the coming weeks.

Here's a taster of some of the new features of WAS V7.0 that we'll cover:

• Consumability improvements
  • New console wizards to make configuration easier
  • Improved facilities for monitoring and control
• Improved integration with WebSphere MQ
  • Using WMQ directly from WAS via the new JCA 1.5 Resource Adapter
  • Using WMQ via the SIBus - increased platform coverage and additional facilities
• Clustering improvements
  • Better workload balancing
  • New options for message routing and visibility
  • Response routing within a cluster
  • Additional options for MDB activations
• Security changes
• Connectivity from client environments and from servers outside the cell
• Performance improvements

All of the new features of WAS V7.0 are described in the InfoCenter but if you'd like to hear about them from a different perspective and have the opportinuty to discuss them, then please pay a visit to the WebSphere and Messaging blog.

Graham

WebSphere and Java Persistence

With the recent announcement of WebSphere v7, we are now on our second release of providing a Java Persistence API (JPA) solution for our WebSphere customers. We first delivered JPA as part of the WebSphere v6.1 Feature Pack for EJB 3.0. Built on top of the Apache OpenJPA project, not only is the WebSphere JPA solution CTS compliant, but it also contains several WebSphere value-add extensions.

In WebSphere v7, the WebSphere JPA solution provides the following features beyond the base JPA specification (those marked with an asterisk were provided in the Feature Pack for EJB 3.0 as well):

• Performance Improvements
• DB2 pureQuery (Static SQL) integration
• ObjectGrid Cache plugin
• SQL Statement Batching *
• DB2 Select Statement Optimizations *
• Consumability Improvements
• Access Intent support
• XML Column Mapping *
• DB2Diagnosable exception processing *
• Enhanced tracing using AspectJ *
• Database generated version IDs *
• Command scripting (.bat/.sh) *
• Globalization
• NLS Message Files *

More information on these features can be found in the InfoCenter. Due to the numerous requests we receive concerning the WebSphere JPA solution, we have also decided to create a blog devoted to WebSphere and Java Persistence. Please visit and share your comments as we continue to populate this avenue for sharing information.

New Dynacache Features in WebSphere 7 - Part 1

Are you looking for WebSphere Application Server V7.0 new features? If so, look here. If you are looking for new features relating to Dynacache, continue reading.

I am excited about the new Dynacache heap management feature in WAS 7. The primary motivation for introducing this feature is for serviceability. Many times customers trip up on themselves by caching too much stuff. I have lost count of the number of critical situations where I have been hauled from the bed, by some customer critical situation where the server was down due to an OOM error. It is extremely important to size the cache well. Unfortunately this is not an easy thing to do and pre-production stress testing in some cases does not simulate real world traffic which leads to an underutilized cache and thus false confidence in the capacity utilization of the cache.

This is not an easy problem to solve. There is no sizeof operator in Java which will tell us the size of an object in the JVM heap. Therefore we have to use all sorts of smarts, trickery and some help from the application developer to determine the total amount of memory on the JVM heap taken up by the cache. All earlier techniques to determine cache size rely on serializing the cached objects and metadata because that is the only way to accurately determine the size of the objects. In WebSphere 7 we have taken a much light weight approach which does not rely on serialization to determine cache heap size.

Most application servers allow cache size to be controlled by no.of entries. We are taking cache size management to the next level in WebSphere Application Server 7.

What exactly does Dynacache provide ?
WAS Dynacache component will provide an ability to constrain the cache in terms of the JVM heap. In addition to specifying the cache size in MB, Dynacache will also allow customers to set a high water mark and a low water mark for the cache heap consumed. Once cache heap memory reaches the high water mark, dynacache will either discard or evict the least recently used items to disk, till the cache is brought down to the low water mark. This functionality of limiting the cache in terms of the JVM heap will be available if the objects put into the cache that implement the com.ibm.websphere.cache.Sizeable interface. When servlet caching is enabled, all the cached JSP and servlet responses will be Sizeable. This interface will have one method which will return the size of the Object in bytes put into the cache. Dynacache will use the Sizeable interface to estimate the heap size of the cache. This feature will be OFF by default. A customer will have to explicitly enable and set cache limits and watermarks.

How to enable this feature ?

On the Dynacache service panel, WebSphere exposes the Dynamic Cache object cache service and Dynamic Cache servlet cache service. The Dynamic object cache service is always started at server start up. The Dynamic servlet cache service is started when the servlet caching is enabled in WebContainer panel. There is now a checkbox for Memory Cache Size which will control the memory cache size with high/low threshold. In addition to specifying the size the customer can also specify a range for the heap by setting threshold limits. The Servlet and Object Cache instance under the Resources -> Cache Instances have also include the Memory Cache Size control feature.

WebSphere Application Server Version 7.0 Performance Highlights

We recently announced WebSphere Application Server V7.0. Over the next week, I will be sharing some of the performance highlights of our teams' work improving existing usage scenarios as well as performance grooving of new V7.0 features. Here are some of the areas I plan to discuss.  Let me know if you'd like to see other areas and I'll work to include them as well.

• General Java EE
• Web Services including JAX-WS and WS-* standards support
• Persistence including EJB3 and JPA
• Startup Time and Memory Footprint
• Security including Java SE, Admininstration, Java EE, and new features
• Java SE Performance
• Hardware exploitation (64-bit, Multicore, Virtualization)
• Support for SIP based communication in our convergence sevlet container

Documentation Approach about Web Services for WebSphere

As part of the approach for delivering Web Services as part of WebSphere Application Server, the web services team is experimenting with multiple approaches for providing information to our end users. In addition to updating the Information Center about new features about web services, we are looking at alternative approaches to getting information into our hands of our end users. One approach is using developerWorks articles. For the Feature Pack for Web Services that we delivered on top of WebSphere Application Server v6.1, we worked with the developerWorks editors and put together a list of articles, which discuss the technology. As part of that work, we listed comparisons between JAX-RPC and JAX-WS (part1, part2, part3, part4, and part5) as well as the JAX-WS technology itself (via dispatch clients and JAX-WS annotations). For interoperability between the Feature Pack for Web Services and other vendors, we offer the following articles for interoperability with Microsoft (part1 and part2) and Apache Axis2. Other miscellaneous articles include a discussion of WS-I’s Supply Chain Sample Application built on the Feature Pack and troubleshooting web services applications in the Feature Pack and we have more in the pipeline.

Lastly, another approach is the usage of Redbooks. Members of our development organization participated with other IBM folks to help produce a Feature Pack for Web Services Redbook. These are all meant to be ways to compliment our existing Information Center and provide specific useful scenarios in a more end-to-end fashion to help our developers get on board.

I hope you like the approach and would be interested in hearing your feedback.

In case you thought the SCA rock stopped rolling...

I'm very pleased to announce to this community that we have made active the first beta of the newly re-based Feature Pack for Service Component Architecture for WAS V7.0! My team has been killing themselves, slaving away using new agile processes, keeping on top of the latest WAS builds to bring you this technology on the new WAS! To sweeten the pot for some of you out there, and you know who you are, we are even offering the feature pack beta in a popular VMWARE distribution which is configured to run a SUSE Linux guest with the SCA Feature Pack and WAS V7.0 betas pre-canned and ready for you to play with. Our development and beta teams are excited to engage all of you SOA application developers out there-- welcome!

Beta details here. Of course, our code is based on the Tuscany open source project which I've blogged about before.

I want to thank all of my development and beta team members for all of their hard work.

The TPC is working on a SOA Benchmark proposal submitted by IBM

Given the comments I made previously on SOA benchmarking, I'm happy to report that the Transaction Processing Performance Council (TPC) has agreed to evaluate an SOA benchmark proposal submitted by IBM. You can see in the recent "Meet the TPC" working session, the TPC discussed the TPC SOA workgroup on page 8. The summary is rather high level - "Tasked to evaluate SOA benchmark proposal from IBM". I believe if this proposal is accepted with modifications by other TPC participants, customers of SOA solutions and the industry can truly benefit from the TPC's standards-based benchmarking experience and levels of customer trust. I personally will be working to make this workgroup a success, with the intent of making SOA performance as understood as hardware, database, and J2EE performance. If there are companies out there with SOA solutions, I would personally encourage them to join the TPC and participate in this or other benchmarks and workgroups. I hope to, in the future, blog about the success of this workgroup and benchmark.

eWeek: "IBM WebSphere at 10"

Darryl Taft from eWeek: IBM WebSphere at 10

Excerpt:

"IBM Senior Vice President and Software Group General Manager Steve Mills met with three of his top lieutenants in his office back in 1997 to discuss the "Webification" of IBM's enterprise tools. Out of that discussion the IBM WebSphere Application Server was born."

I had just joined IBM in 1997 and was working on DB2 for OS/390. While I was trying to figure out what this "mainframe" thing was why anyone would want to manage it from OS/2, smart folks in Raleigh were creating the future. Well done, gents.

The Poor (Broke) Man's Java Profiler

When I talk to customers about big performance issues they are experiencing in their applications I usually mention "The Poor Man's Profiler". Actually, when I use this phrase, I am talking about Java core dumps. Java comes with a cool feature where you can send a break signal to the Java process and get a core dumped to the working directory of the application. In that core, if you search for "Full thread dump", you will see what is happening in all the threads of the application. If you do that a few times during load, you can very poorly approximate a Java profiler. If you have an application that won't scale or a Java process that is taking minutes to complete an operation, its amazing how often you can find the issue with Java cores.

Here is how you do it.

1. Get the application running under load (or if its a single threaded long running operation, just let the operation get started).


2. Send a BREAK signal to the Java process. In Unix/Linux, you can do this with kill -3 ProccessId. In Windows, you can do this by using a program called SendSignal (Note I don't endorse this tool, but happen to find it useful).
   
   
   You'll see the process start to consume exactly one CPU in the system (on a uniprocessor box, 100% CPU, on a 4-way box, 25% CPU, for example). During this time the JVM is doing its job collecting up all the information for the core. At the end it will dump the core to the working directory of the application. Once it is done (could take some time) the CPU will go back to normal.


3. Let the process continue for a little while, so the application gets back into its normal state.


4. Then repeat the previous steps starting with the BREAK signal three or more times (the more the better).


5. Look at the information in the thread dump section (search for "Full thread dump") of the Java core and make sure it looks similar in all three (or more) core dumps. If so, you should have enough certainty to trust what you see in the core dumps.

In a future post, I'll talk about what to look for in the Full Thread Dump, but to get you started, if you see the same method repeatably on the top of the stack of multiple threads, that is what you want to go after first.

In the last two months, I used this approach successfully to find problems in an application server application (bad third party libraries) and a migration script (bad algorithm for handling large amount of data). Both showed rather clearly what needed to be fixed in the program. Also, since this comes with Java, you need no tools to use the "poor man's profiler".

If you have questions or if you find this tip useful, please post a comment on this topic.

Tuscany Graduated

A quick shout out to my colleagues and all the folks who have worked so hard to develop an open community which supports Service Component Architecture. The Tuscany project at Apache has recently been promoted from an incubator project to a fully endorsed ASF top level project. This promotion recognizes the community for fostering an open and diverse membership, demonstrating capability to deliver stable, working implementations of the technology and also garnering the votes and confidence of the Apache Board. Congratulations on your success! Super job.

Evans Data Study: RAD scores the highest user satisfaction

It was with great pleasure that I read the Evans Data Study that was released this week; the study was a survey of over 1200 IDE users, and the bottom line was that RAD had the highest user satisfaction scores among the IDEs rated (including Oracle JDeveloper, Microsoft Visual Studio, MyEclipse and NetBeans). A survey is a survey; I have no doubt that you could find users of all of the above IDEs who are passionate supporters of their product of choice – but this survey revealed that compared to the other IDEs (and I’m quoting here) “RAD is just head and shoulders above them when it comes to user satisfaction.”

Cool; that’s what we’ve been trying to deliver, and it’s gratifying to see that our users are pleased with what we deliver.

What was most heartening to me, though, was what the survey didn’t measure; namely RAD 7.5. I think RAD 7.0 (which is the latest GA version of RAD that’s available) is a pretty darn good product, and the survey seems to agree with me – but I am even more pumped about what we have coming down the road, in the form of RAD 7.5. As I’ve discussed in this blog, we’ve had RAD 7.5 available in open beta since late last year – that code was refreshed at the beginning of May, and we’re still working on it. The fact that we were able to deliver public beta code so early in the schedule is a testament to the state and the quality of the release; we’re still adding features and function, we’re still fixing defects and improving the quality even more, and we’ve also got the benefit of lots of additional user feedback, with enough time (for a change) to do something about it. Put it all together, and I’m convinced that RAD 7.5 will be the best RAD we’ve ever delivered.

Back to the survey; results were provided giving an overall satisfaction of the different IDEs, and the various capabilities within the IDEs were also rated (how does your debugger rate, how do your web design tools rate, etc). Although we were first place in the overall rating, the RAD results in the individual areas were mixed; we did great in some places (application modeling tools, tech support, profiler, web design tools), and less well in other aspects. There was not a lot of variability in the rating for editors, all the products scored well - but in that category, RAD was in last place, for example.

That actually doesn’t surprise me, as the editors were one of the areas I was most concerned about as well – and for that reason, the editors, and the editing experience were one of the areas we’ve spent the most time and energy on, in RAD 7.5. I was presenting at the IBM Impact conference in April, and showed off some of the new features in RAD 7.5 – let me share a couple of highlights with you:

• The various deployment descriptor editors in RAD 7.0 were attempting to abstract away the details of the actual changes being made to the underlying files – but we’ve heard from numerous customers that it’s more important to assist the developers… but still “leave them in touch” with the underlying files being updated. We have a great new editor framework (the source of several patents) that we’re using across RAD 7.5, that means developers who make a change in the editor, will have no problem know what (and where) they have changed in the actual file – but at the same time, we still provide lots of help and validation in editing the actual contents. These new editors are getting great feedback from our beta customers.
  
  
• We’ve had a big focus on refactoring operations and quick fixes, both of which surface via editors of all shapes and sizes. Eclipse has a great history when it comes to providing refactoring operations, and RAD 7.5 really takes and extends that model; we participate in many existing eclipse refactoring operations now (for example, a rename will do the right thing across the many J2EE artifacts, as well the just the Java code), and we have added several of our own, J2EE specific refactoring operations. These refactoring operations allow us to provide significant help to developers who are updating their code, while leaving the editors to do just that – provide a good, focused, editing experience. Again, the feedback from beta users to date has been very positive on the changes we’ve made.
  
  
• JavaScript is increasingly important in a web 2.0 world, and so we’re introducing significant new support for JavaScript in RAD 7.5 – we have a comprehensive new JavaScript editor, which we’ve integrated into all the right places; you’ll now get support like code assist, syntax validation, and colour highlighting whether you are editing a standalone .js file, or a JavaScript snippet embedded in the middle of an HTML file, while you’re using the RAD page design tools.
  

These are just a few examples of the changes, improvements, and new features we’ve been developing for quite a while in RAD 7.5 – and the Evans survey has simply validated many of the decisions we’ve made; if we can be number one in user satisfaction with all our old editors, I’m super confident that we’ll be able to make developers even happier, and even more productive, with RAD 7.5.

Next up for me is the RSDC conference, in Orlando – we’ll be presenting and demoing RAD 7.5 there, so come by and say hi if you’ll be there.

Tim

GWC hosting an "Ask the Expert" day next Wednesday

The Global WebSphere Community (a.k.a. http://websphere.org) is hosting their annual "Ask the Experts" day with IBM Development and SOA experts on May 28th. You need to register as a GWC member to participate, but registering is free and fast and painless.

The session starts at 10:00 am Eastern and ends at 10:00 pm Eastern, and is basically an opportunity for GWC to both ask questions and submit ideas about WebSphere products, directly to the product teams. Do you have a nagging issue or a great idea? This is your chance to share both with IBM.

Join in!

Jobs and lyrics...emotional design

I'm no psychologist, but I play one on the interwebs. Anyway, let's take a blogger favorite subject, Steve Jobs...or preferably, El Jobso. Of the many things he's famous for, it's memorizing his speeches, down to the last seemingly spontaneous slip-up & joke. That "scrolls like butter" comment? Scripted. Yeah. Believe it.

But you gotta admit, it works. Whom else scripts their words so well? Musicians for one. And from his public speeches, we know El Jobso admires musicians. Musicians memorize their lyrics to get us to feel a certain way...just as El Jobso does when he demos the next new delicious piece of gadgetry. It's probably the highest art to get someone to feel as you do when you need them to. It's like a great concert when an entire stadium all feels the same emotion on cue. It's pretty cool, isn't it? So, where is all this going and how does it relate to WebSphere? We're getting there.

Compared to Apple, Microsoft's products are less emotive...but they're damn effective. They're good enough not to get in the way (most of the time...bluescreen...doh) and ubiquitous. Compared to Apple Music, they're Muzak. The white noise of music. Hold music. You know, that stuff in the background that helps you pass the time, but isn't so amazing that it forces you stop, to listen, to *feel*. That would be distracting. But it does remove some of the monotony.

Anyway, there's obviously a place (and I would say a need) for both approaches. I love beautiful objects as much as the next person, but after awhile, the beauty fades into the background, and utility had better be underneath, supporting the facade. Given a choice, people I speak to usually value utility over form, but only slightly, and only then after the glow of newness has worn off. You don't want your tool to be so difficult to use or so ugly that your profession becomes *work*. Bleh.

Frankly speaking, the WebSphere products I've worked on and with emphasize utility a bit too strongly over form. That is, they haven't been strong (but we're working on it) on design focus. We first set out to make efficient, scalable systems that run the back offices of your world reliably. Our model is mainframe reliability. You know, the every credit card transaction, every ATM withdrawal kinda stuff. But not the prettiest GUIs. Some Google software fits into this category...gmail/search/adwords, none too pretty, but all effective.

I suppose all software designers strive for that ultimate goal: perfect form, perfect function, perfectly intuitive, consistency top to bottom, inside and out. Based on the behavior of something you already know how to do, the next feature functions with the same general behavior. Looks, proportion, cut, color, fit, finish, function...all there. Applied well, your product develops a personality of a good, reliable, effective beautiful tool. A killer app. Much like a great sports car (maybe that's why we have so many comparisons between software and cars? but that's a topic for a different post...).

Anyway, those are my ramblings. Until next time, let us know your thoughts in the comments.

On Consumability...

Hi all, go easy on me given this is my first time posting here. Anyway, re: the title...you might not think of software as food, so indulge me for a minute. We can agree that anything more palatable is more consumable, no? Assuming that, then consumability of any product is a good thing -- they're "tastier" so to speak.

But Aaron, I hear you say...how do you make software more consumable?

Good question. Here's one handy definition: Time to Value. That means, from the time you identify that you'll use software to solve your problem, measure how long the interval is until you actually *deliver* a working software-based solution. Toss in a metric for average time to deliver maintenance and viola! Time to Value. Simple. Believable. Hard as s**t. But ultimately, we believe, doable.

IBM's idea, and this is portable across all software, everywhere, irrespective of origin/company etc. is this:

How effectively can clients identify the right IT solutions to solve a business problem, find the right IBM products and technologies to use, get the solution up and running, and maintain that solution? Our goal is to enable our clients to easily and effectively use our products to solve their business problems. Making this a positive experience leads to delighted clients, which in turn leads to strong references, repeat business, and revenue growth.

We're curious about your thoughts and as the months wear on, our progress (or lack thereof) in areas that you most need consumability.

Web 2.0 Collaboration, Sharing and Social Networking on WebSphere at Impact 2008

In my session at the Inner Circle at Impact 2008, I'll talk about the Collaboration, Sharing, Social Networking, and Portal capabilities provided by Lotus Quickr, Lotus Connections and WebSphere Portal that are all powered by WebSphere Application Server. I'll give an overview of these WebSphere applications and how they enable Web 2.0 collaboration and social networking to increase organizational productivity and will give an overview of their architecture, concluding with a set of demos.

Join me at Impact 2008 to discuss SOA Performance

I will be speaking on SOA performance at Impact 2008, the Smart SOA Conference, in Las Vegas in April. Please join me there at my session on Wednesday. The abstract for my session (1446A):

This session will discuss SOA performance as it relates to the IBM WebSphere® portfolio. The portfolio view will begin with runtime aspects including basic Web services (including the new Web Services Feature Pack). The runtime aspect focus will continue and build to choreographing and integrating these services across IBM WebSphere Process Server, WebSphere Enterprise Service Bus, WebSphere Message Broker, and the WebSphere DataPower® SOA appliance. The portfolio view will then focus on the SOA lifecycle, business activity monitoring and situation detection, and governance covering WebSphere Business Monitor and the WebSphere Service Registry and Repository. In addition, historical views on SOA performance will describe how performance has improved over the past two years. Finally, the session will discuss best performance practices when implementing SOA solutions.

I was also lucky enough to be included in a set of videos "On the Road to Impact" along with Kyle Brown on Event Processing and Ruth Willenborg on Virtualization. Go ahead and watch the videos and feel free to comment.

IBM WebSphere Application Server Total Leadership in SPECjAppServer2004

As noted in the IBM press release, we recently published a SPECjAppServer 2004 result that puts IBM on top of BEA, Oracle, and Sun for the absolutely largest SPECjAppServer 2004 throughput ever achieved. This result comes after we dominated the same competitive crowd on per cpu core performance as I blogged about previously. Both of these results matter. The per cpu core leadership shows application server performance in the most competitive light. The total configuration shows application server scalability in the most competitive light. IBM WebSphere dramatically wins both.

Some numbers from this total leadership publish:

• The result of 14004 JOPS represents roughly 75,000 transactions per second against the DB2 database. Simply impressive.
  
• The closest competitor in total throughput was Oracle at 10519. The IBM result tops that Oracle result by 33%. The IBM result tops the highest Sun result (8439) by 66%. The IBM result tops the highest BEA result (8253) by 70%.
  

Congrats to John Stecher and team. You can read more about the total configuration publish (and John's team) on InfoQ.

SPEC is a non-profit organization that establishes, maintains and endorses standardized benchmarks to measure the performance of the newest generation of high-performance computers. Its membership comprises leading computer hardware and software vendors, universities, and research organizations worldwide. For complete details on benchmark results and the Standard Performance Evaluation Corporation, please see www.spec.org. Competitive claims reflect results published on www.spec.org as of February 18, 2008 when comparing SPECjAppServer2004 JOPS on all published results as well as derived metrics calculated by SPECjAppServer2004 JOPS / Number of Application Server Processor Cores.

The facts of RAD

MyEclipse has issued a press release that mentions RAD, and may cause some confusion, so I'd like to take this chance to set the facts straight.

First of all, the transition from WSAD to RAD was purely a naming one. WSAD was delivered prior to IBM's acquisition of Rational, and RAD 6.0 was simply the next version of "WSAD" released under the Rational brand. RAD is entitled as a free upgrade to all active WSAD customers; there is no new cost - describing the transition from WSAD to RAD as complex or costly is either uninformed, or intentionally misleading.

The plumbing that formed the core of both WSAD and RAD was donated by IBM to the eclipse WTP project, to provide a defacto standard interface that others could extend - meaning that any tool extensions will work correctly and naturally with RAD. MyEclipse uses this base, so the basic project structure is the same - but the vast majority of the components that form RAD are not part of WTP; they are only available in the IBM offerings. Those value add components and functional areas are where we're spending most of our time and energy on, and that's where the real benefit of RAD comes from.

RAD 7.0, which has been available for over a year, includes comprehensive support for J2EE & Web Application developers, with support for pure spec compliant applications, as well as integration for all the WebSphere extensions - for example we don't just support JSF, we also ship and have outstanding support for the IBM JWL widget library; the latest version of JWL (which is only available with RAD) makes it fall-off-a-log easy to create an Ajax application, with no handwritten javascript at all (see http://webspherecommunity.blogspot.com/2007/06/simple-ajax.html for more details).

That said, simply providing spec level support is not really a differentiator today; that's why we donated the code we did to WTP. The RAD value proposition is it's ability to improve the productivity of developers across the entire development life cycle. Some examples:

• Some other products provide simplistic support of UML, that requires iterative generation of java code, followed by import actions to keep the diagrams and code in sync. This round trip engineering approach was available back in Rational Rose, and is a long way from state of the art now. RAD provides much more than that - for example, we provide UML visualization, which allows you to view, edit, and update Java code using UML views. There's no separate model to get out of sync; you're editing the live code, but in UML.
• All modern IDEs include support for database interaction and definition, but RAD has the benefit of working with the DB2 developers to provide exceptional support (for all major databases); RAD includes graphical views of your data topology, a SQL scrapbook, impact analysis tools, the ability to write user-defined functions (UDFs) & stored procedures, and phenomenal support for embedded SQLJ.
• RAD has in-depth support for application profiling, analysis & testing; you can execute, monitor, and trace the flow and performance of your application, right out of the box.
  

Of course, we also have the benefit of working hand in hand with our IBM colleagues, to provide the very tightest integration with WebSphere. It's not hard to deploy an application to WebSphere Application Server, but only RAD includes copies of three versions of WAS, to simplify your unit testing on a "real" WebSphere server, at no additional cost. Because we actually embed the WAS server, we support both remote application deployment and local application deployment, which gives you better deployment performance because there's no copying of files necessary. RAD also includes complete support for WebSphere Portal Server, including creation wizards, views, and editors that enable you to develop, test, debug, and deploy portal and portlet applications.

When it comes to production application deployment, RAD includes an advanced Jython editor, designed to simplify the task of developing and testing WebSphere automation scripts. We also offer unique integration with the WebSphere admin console, allowing you to capture key actions in the admin console and turn them into the equivalent Jython script commands. Finally, there's an embedded Jython debugger, that will let you single step through the admin script, examine variable values, etc.

IBM remains strongly committed to RAD; the next version of RAD (7.5) has been available as an open beta since late last year; you can find more details here: http://webspherecommunity.blogspot.com/2007/11/rational-application-developer.html. As you'll see if you try this code, RAD 7.5 provides many compelling features that focus on developer efficiency such as JEE refactoring and quickfix operations, while offering enhanced integration with products from all IBM brands, but especially Rational, WebSphere, and DB2. As I said in my blog entry, I'm really pleased with the progress the team has made on RAD 7.5; even though this is just a beta, the code is great quality, the performance is good, and all early reports are extremely positive - come check it out!

Tim Francis,
WebSphere Tools & RAD Chief Architect