Programming Model Durability and Portability

One of the key benefits of using the WebSphere Application Server is the assurance that the programming interfaces supported by WebSphere are durable. A great deal of effort has gone into version 5 of WebSphere to ensure that applications written to the J2EE 1.2 specification to run on WebSphere version 4 will continue to run on WebSphere version 5 in spite of version 5 being now certified to the J2EE 1.3 specification.

The J2EE 1.3 certification test suite includes some 15,000 test cases covering just about every aspect of the J2EE 1.3 specification. In addition, IBM has ported Sun's PetStore reference application to WebSphere in accordance to the portability guidelines for the PetStore application, and participates in various interoperation events such as the J2EE Sun's Java developer conference. All of this is to ensure portability of J2EE applications and interoperation between conforming J2EE application servers.

Likewise, applications written to the J2EE 1.3 specification to run on one of the distributed platforms such as Windows, Solaris, Linux, AIX, HP/UX, or iSeries will run on WebSphere for z/OS as well. Some of the WebSphere Application Server Extension APIs are also available on z/OS, as indicated in the previous section.

To help assure programming durability, WebSphere attempts to be very clear about what APIs are considered strategic, and which are considered tactical or will only be available on certain platforms or for limited releases. We've tried to reinforce that distinction in this book as well by highlighting where we expect a certain interface or programming feature to be deprecated in the future, or limited in some other fashion. In this way, you can decide whether the value of the feature outweighs the risk of having to change your application if the feature is provided in a different form in the future.

Enabling Privileged Code

The J2SE interfaces are subsumed by J2EE – a J2EE conforming application server must also support the J2SE specification. Unfortunately, using certain aspects of J2SE in an application server can impact on the server's ability to provide a robust execution environment for that application. We've discussed some of the implications of generating GUI interactions with AWT or Swing and spawning threads in the Java 2 Platform, Standard Edition APIs section, for example. The J2EE specification recognizes this. However, instead of sub-setting the J2SE specification, it simply allows an application server to constrain what an application can do through the use of what it refers to as the J2EE permission set. These are Java 2 SecurityManager permissions to define what an application running in a J2EE environment must be allowed to do. The J2EE permission set for each of the execution environments defined by J2EE is listed in the following table.

Application Clients	Applet Clients	Web Components	EJB components
java.awt.AWTPermission: accessClipboard	java.net.SocketPermission: codebase(connect)	java.lang.RuntimePermission: loadLibrary	java.lang. RuntimePermission: queuePrintJob
java.awt.AWTPermission: accessEventQueue	java.util.PropertyPermission: limited(read)	java.lang.RuntimePermission: queuePrintJob	java.net. SocketPermission: *(connect)
java.awt.AWTPermission: showWindowWithoutWarningBanner		java.net. SocketPermission:*(connect)	java.util. PropertyPermission: *(read)
java.lang.RuntimePermission: exitVM		java.io. FilePermission:*(read,write)
java.lang.RuntimePermission: loadLibrary		java.util. PropertyPermission:*(read)
java.lang.RuntimePermission: queuePrintJob
java.net.SocketPermission:*(connect)
java.net.SocketPermission: localhost:1024-(accept,listen)
java.io. FilePermission:*(read,write)
java.util. PropertyPermission:*(read)

Any J2SE class that requires a permission that is not listed in this table cannot be performed. This can prevent you from doing many things that you might otherwise be tempted to perform in the application server. However, in some cases, the need to use a particular disallowed J2SE function is not a matter of temptation, but rather a matter of imperative. One example that we've encountered on several occasions is where an application picks up a third-party library to use and that library spawns its own threads. As spawning threads can undermine the integrity of the application server and is therefore discouraged, disallowing it completely can be overly restrictive. In some cases, a customer will be willing to risk the loss of integrity for the sake of gaining the benefit that comes with such packages.

WebSphere offers a way to overcome the restrictions that would otherwise be imposed by the J2SE permission set. You can request an additional set of permissions in your application through an extended deployment descriptor defined by WebSphere. When deploying and loading your application, WebSphere will consider this request for additional permissions in the context of the application server's constraints and, if possible, grant those to your application, making a record of this with the Java 2 SecurityManager in the application server in which that application will be hosted. The mechanism for identifying a privileged application in this manner is very similar to the approach taken for Java 2 Connector resource adapters that generally have a very similar need stemming from the nature of connecting to different legacy systems.

You should note, however, that the extended deployment descriptors defined by WebSphere for requesting these permissions are unique to WebSphere – if your application creates this sort of dependency, it may not be portable to other application servers. Further, WebSphere is not obligated to grant these permissions in all cases – there may be situations where WebSphere is not able to grant these requests in a particular application server instance.

Most importantly, if you create a privileged application (requesting permissions beyond the standard J2EE permission set) you should recognize that you are exposing the WebSphere execution environment to integrity risks that will, by extension, undermine the assurances that can be claimed for your application and any other application that is located in the same application server instance. You are subject to application execution failures that the application server might otherwise be able to protect you from. So, you should request these additional permissions only if you really are familiar with their effect, and are willing to accept the integrity risk that doing so imposes. In any case, we highly recommend that you isolate any applications that request privileged status – hosting those applications in their own independent application server instance apart from any other application.

The Topology and the Programming Model

Overarching the entire J2EE programming model, web services, and all the extensions supported by WebSphere, is the basic idea that boundaries between components and resources are location-transparent. Wherever you make references to another component or resource in your application, you do so through symbolic references and abstractions that separate you from the physical location of the things you use. Doing so enables the flexibility to place your various application components in the information system where you need them based on capacity, location, and the capabilities of your system, and without being constrained by the actual encoding of your applications. If it becomes necessary over time to place two application components on different machines to address growing demand in your application, you should be able to do so without having to re-implement either component to recognize its new location.

The same principle is exploited by WebSphere to enable the same component to be hosted on multiple application server instances at the same time to achieve a higher level of availability or distribution of workload over multiple processors or machines.

These ideas are key to enabling scalability, high availability, and manageability in your production systems. You can either sustain this or undermine it depending on how you code your application. For example, in your programs you should not encode an assumption that states that other distributed components or resources that you use will be co-located in the same address space. Also, you should not assume that all method requests in different transactions will be routed back to the same component instance, and you should not assume that non-persistent state would be held in memory across transactions or other unit-of-work boundaries.

Contrary to most people's intuition, these principles can actually improve the efficiency of the overall system. While it may seem like having to save state to a persistent store at the end of every transaction is inefficient, WebSphere is able to reduce the impact of this I/O through its caching mechanisms, and in some cases can compensate for any remaining inefficiency by being able to manage the component and its execution lifecycle in the presence of its knowledge about other workload in progress in the system. By retaining these principles, for example, WebSphere is able to distribute workload to where the greatest capacity exists in the system, and thus can improve the response time and throughput for the entire system.

Wherever you need to violate these principles, you should state so explicitly in the deployment descriptors that are provided for this so that WebSphere knows to manage your components within these constraints. However, you should be aware that wherever you impose these constraints, you are limiting the degree to which WebSphere is able to gain optimum efficiency in the execution environment for your application.

The Security Programming Model

WebSphere is designed specifically to protect your application components. The runtime will authenticate end users and enforce authorization policies to prevent unwanted access to your components. You can control how this is done through deployment descriptor declarations associated with your component, and through external policies defined outside your application. WebSphere and J2EE both discourage you from encoding security policies into your application.

Again, this principle is based on the idea that encoding such policies in your application will limit flexibility – if you hard-code a security policy in your application then the security administrators will not be able to change that policy without changing your application. In fact, they may not even be able to see the policy (if your application is compiled and installed as a binary) or be able to evaluate its affect on the overall integrity of the system.

Of course, we also recognize that key capabilities are missing from the J2EE security model that will force you to encode some amount of security function. This is discussed further in Chapter 13.