Web Services Caching using DynaCache

Recently, we've been working with customers on using DynaCache to cache web services responses on the server side (to improve throughput and load on a server for common requests). Our DynaCache expert published a blog entry documenting the details about how it works and example code for cache-id generation based on the request information while caching responses for SOAP 1.2.

Hope you find the blog entry is useful, and please provide us any feedback.

RAD 7.5.5 and Web Services support

Happy New Year!

Just before the holidays, RAD 7.5.5 was introduced which includes some additions for web services.  Details can be found here.  These additions enhance some of the capabilities that we've added to WebSphere or are actively working on.   Just a few high-level points include...

• Support for JAX-RS runtimes.

There's now a preference that you can define a JAX-RS library to include the necessary runtime artifacts to pull in for JAX-RS support.  Therefore, the classes can be defined ones within this library, and a JAX-RS facet can then be utilized in order to pull in reference to those classes. 

Once this library has been defined, it's possible to define a JAX-RS facet pulling that in as part of the project.

 Additional configuration can then be done to specify some of the project-specific JAX-RS information.

This helps users not have to worry about including the libraries themselves (and can allow it to be separately managed).

• Support for SAML

There's now a SAML Facet to ensure deployment to SAML-enabled WebSphere Application Servers  (see Facet diagram above),  support for SAML modifications in PolicySets and Bindings, as well as a SAML Sample that ships as part of RAD 7.5.5

• Support for Policy Set and Binding Editors 
  

There is now XML editors for editing the Policy Sets and Bindings within RAD 7.5.5 for a number of different binding types.  An example is shown below for configuration of WS-Security for SAML.

I hope this helps bootstrap some folks to use some of the existing capabilities.

Web Services and Authorization

I've gotten involved in some discussions with customers asking questions about web services and authorization. In an attempt to clear up some of the ambiguities, I decided to start with going back to the basics and stating to customers what is the intended capabilities of the technology so that they can see for themselves a bit of what is the magic. The initial problem that some customers have is understanding how authorization works for Java EE-based web services.

Some of the facts are:

• There is a security model for both Web Resources and EJB resources. Both support role based authorization to control access to resources
• Web Resources are URIs and the methods on Web Resources are GET, PUT, POST, and DELETE
• EJBs are objects/services and the methods/operations on EJB resources are more RPC-level methods
• You can secure/authorize both types of resources appropriately...

Now, that said, let's add in "SOAP-based Web Services". To a great extent, this starts to blend the 2 models... (in the usage of HTTP as your transport)...

• JAX-RPC and JAX-WS represent programming models for SOAP-based Web Services.
• JAX-RPC defined a mapping model, as well as an unmanaged "client" programming model. There is no standard "deployment" model for exposing Web Services in JAX-RPC.
• JSR 109 adds to that a "management" model, where you can now define "declaratively" Web Services to be exposed. In addition, you can now manage service references (clients) to those resources.
• WebSphere uses JSR 109 metadata (i.e. service name or service reference name) in order to attach qualities of service to those resources
• JAX-WS get's a *little* better in this space (since annotations can be used to denote service references - and clients) - which is why we are able to use a notion like "policy sets" to attach resources to the "attachment-points" defined by annotated classes...

Lastly, this brings us to the matter at hand - authorization....

• There is one small fly in the ointment mapping SOAP-based HTTP-centric Web Services, and that is all services are issued over a POST.
• For services hosted as EJBs, "users" can be identified and secured using standard HTTP-transport mechanisms (or Message-level mechanisms), and the authorization of methods can be handled via the normal authorization checks for method/operation level security in EJBs.
• For services hosted as POJOs in a Web Container, since it's all a POST, *all* you can do is validate (if anything at all) that the user is a valid user (with the standard J2EE level mechanisms for security).
• You *could* invent your own authorization logic to check (at the application-level) what role the caller is in, etc... (under the various operations) - but, that's essentially doing the same as what is built-for-you with using EJBs.
• Lastly, there is nothing preventing you from doing this by delegating the request to an EJB container. The additional cost of the container breach is roughly what you are paying for (performance-wise).

Hopefully, this will help clear up whatever confusion users have with how authorization and web services works.

Asserting an Identity from JAX-RPC Web Services to WebSphere

I've received similar questions from multiple customers all about asserting identity on Web Services requests within JAX-RPC. Therefore, let me talk a bit about how this can be done with the support in WebSphere today.

The JAX-RPC web services security implementation has two phases of processing a security token embedded in the WS-Security header.

1. Verify the validity of the security token.
   This is handled by the Token Consumer and/or JAAS Login Module configured in the deployment descriptor and binding.
2. Verify the identity of the security token exist in the configured user registry and then create the WebSphere credentials.
   This is enabled via the Caller and it is optional.

In some business use cases, you may want to assert the identity based on trust and do not necessary want to add the identity to the configured user registry. Here is how you can do this (since 6.1.0.19).

Phase 1

The user must provide a custom implementation of a Token Consumer. Here is a developerWorks article with step by step instructions.

Phase 2

The user must override the default JAAS Login Configuration.

The default JAAS Login Configuration used by the Caller to create WebSphere Principal and Credential is “system.DEFAULT”. This JAAS Login Configuration is used by many other parts of the system. It is best to create a new JAAS Login Configuration with the same content of “system.DEFAULT” and ensure your custom JAAS Login Module is the first in the list, and then specify the Caller to use the new JAAS Login Configuration. The property to specify a different JAAS Login Configuration for the Caller (see figure below):

Name: com.ibm.wsspi.wssecurity.Caller.assertionLoginConfig

Value: name of the JAAS Login Configuration

Please follow the WebSphere Attribute Assertion framework in your custom JAAS Login Module implementations to assert the identity. The information is available here and here.

I hope you find this information useful.

Web Services Performance Tidbits

My team was recently working with a customer on their web services application and we wanted to document a few things we learned during the engagement.

Network bottlenecks

In our IBM labs, when we performance test web services, we set up a set of multi-threaded clients pounding a separate server system until the CPU utilization on the server system becomes saturated (that way - we can see where the time is spent processing). Working with the customer, they could only stress their system to a small portion of the CPU processing limit.

In the end, we discovered that the network was only a 100MB network and totally inadequate to handle the type of loads used in the test - whereas, in our IBM labs, we run on 1GB Ethernet. Using the size of the messages, we computed what the maximum achievable throughput would be on a 100MB network and these matched almost exactly to what was being reported for the customer. This showed us that the network was the bottleneck in the environment and the Application Servers are not being stressed at all - only the network connection.

One way to get around the network bottleneck in an interoperable way would be to use GZIP compression to compress the data (since the network is the bottleneck). See here and here for more information about enabling GZIP compression for Web Services.

Transaction Isolation Level

Another interesting point that we learned was that different Application Server vendors use different transaction isolation levels on the JDBC connection to the database. WebSphere, by default, uses Repeatable Read as a default isolation level which initially made our performance slower. This default was made to protect customers data. Another vendor used a default of Read Committed isolation level which offers higher throughput but more risk. The choice of which isolation level to use is up to the customer but in a comparison, this setting should be consistent to get apples-to-apples measurements.

Tuning

WebSphere does provide many parameters that can be tuned to increase performance. Some of the important ones for web services are JVM heap size and Web container thread pools. A white paper was recently published by our performance team that shows the impact of adjusting some of these. See WAS Perf Tuning for more info


We hope this information helps others as they try to build performant web service applications.