Programming Features

This section will provide a very high-level survey of the entire application programming suite for WebSphere Application Server, identifying any significant caveats and conditions to their use in WebSphere. This should not be taken as a complete reference to the APIs of the application server, nor a detailed specification of best programming practices. It is merely intended to be an introduction – most of the topics introduced here will be discussed in more detail through the rest of this book.

Java 2 Platform, Standard Edition APIs

WebSphere supports most of the Java 2 Platform, Standard Edition (J2SE) 1.3 APIs on all platforms and editions in both, WebSphere version 4 and version 5. We will summarize each of the major elements of the J2SE platform APIs here, including any limitations and caveats that should be understood.

Applets

Applets are a way of augmenting your browser-based client with functions that you can write in Java. A common use of applets in a WebSphere environment is to build rich-client user interfaces, and then make direct calls back to EJBs running in the WebSphere application server. A key advantage to applets is that the code for the applet is held on the server, and then downloaded to the browser on-demand when needed. This avoids having to administer code at every client that you want your application to run on. While this seems like a promising approach to building rich interaction models, it does have a couple of pitfalls.

• Given the differences in support for Java in different browsers and on different platforms, it is hard to build portable applets. You can mitigate this by limiting your clients to a specific browser on a specific platform.

• Generally, the applet will be downloaded every time your application client is invoked – depending on how caching policies are set in the browser. Sophisticated applets can be relatively large and the download time for the applet will affect the overall response time experience for your end users. Applets should be kept relatively simple and small to lessen the response time impact.

• If you will be communicating directly back to the EJBs of your application in the application server, you have to overcome the communication constraints of your network. If your browser clients are located outside your firewall, for example, your firewall may prevent IIOP-based communication between your browser clients and the application server. You can turn on HTTP tunneling to overcome this. With HTTP tunneling, the IIOP traffic will be wrapped in an HTTP stream and will pass through the HTTP ports of your firewall. You should carefully examine the security implications of this configuration to your enterprise – in effect, you are creating a covert channel through your perimeter protection boundary.

• Applets are typically sand-boxed – that is, prevented from accessing vulnerable resources on the browser desktop environment. For example, you generally can not access the file system of the desktop from an applet. Some of these restrictions can be overcome by signing your applets, and then instructing your end users to authorize your applets to access the resources you need.

While WebSphere condones the applet model, it doesn't provide any specific support for it. If you want to build an application that uses applets to improve the interaction model for your end users, you are largely on your own to build the applet, resolve the bindings in your applet, locate it properly, and configure your system to manage them.

AWT and Swing

Swing and AWT offer an alternative to the thin browser-client. You can build thick clients or applets that use Swing or AWT to provide a rich user interaction experience. We've discussed the Applet model above. The variation on that theme is the thick client – a full application client program installed and executed from your end user's desktop computer. WebSphere provides support with a J2EE client container for exactly these types of client programs. You can make use of the full Swing and AWT function set from a J2EE client container.

You cannot, however, drive AWT or Swing-based user interfaces from your applications hosted on the application server, if for no other reason than typically there are no users directly connected to the application servers. Application servers should normally be treated as daemon functions that have no user interface directly associated to them on the platform. The biggest reason for avoiding AWT and Swing is that these packages will spawn additional threads to perform their work. We will go into this in more detail shortly.

Notwithstanding the practical limitations of using AWT and Swing from within WebSphere, J2EE also puts limitations on its use. Not all of the Swing and AWT functions are regulated by Java 2 Security permissions. But of those that are, J2EE only permits the use of the clipboard, Swing events, and showing windows without a warning banner in a J2EE client container. None of these are permitted in an applet, web or EJB container. If your application must use these functions in these containers, or needs any other regulated functions of AWT or Swing, you must request permission to these (see the Enabling Privileged Code section at the end of this chapter).

JavaBeans

JavaBeans are a component type that was originally introduced to support presentation artifacts. Programmers have found utility in JavaBeans for a variety of uses – essentially anything for which you want to abstract out properties of your Java object, and manage the object (the bean) around those properties. WebSphere places no restriction on the use of JavaBeans in applications hosted by WebSphere.

I/O (Input/Output)

The I/O classes provide support for importing and exporting Java objects to various data and file streams. WebSphere and J2EE do not place any specific restrictions on the use of these classes, except to the extent that the physical realization of these streams may be restricted by File permissions as described below.

Files

WebSphere allows you to read or write to the file system from either servlets or EJBs in the application server. However, WebSphere will prevent you from accessing any system files or other protected files that make up the WebSphere runtime.

Language Classes

Java offers a rich set of primitive classes that are, in effect, a part of the language. These include support for scalar types (rendered as objects), class management, package, process, runtime, and system manipulation, and threading. Obviously, these classes were intended to be used by Java programmers. However, there are a few gotchas in this list of capabilities – things that could have a detrimental impact on the application server runtime. These gotchas basically fall into two categories – system-related functions, and process-related functions; most notably thread-related functions. Let's discuss this further.

System-Related Runtime Functions

The J2EE security permissions deny an application hosted in a J2EE application server from performing a number of system-related functions. The rationale behind these restrictions is two-fold. First, these functions are generally not considered germane to business functions and thus their use compromises the separation of concerns that the J2EE component models are intending to provide. However, that argument is somewhat philosophical. Much more importantly, the use of these functions can prevent the application server from doing an effective job of managing your components efficiently. To do its job, the application server must make certain assumptions about who is controlling certain resources, and how. For example, competing for control over the ClassLoader will prevent the application server from maintaining a proper level of isolation between applications in the server.

Applications in the application server may not:

• Create or get the ClassLoader

• Set the ContextClassLoader

• Set or create the SecurityManager

• Register shutdown hooks

• Create socket factories

• Set the I/O streams for stdin, stdout, and stderr

• Modify or stop threads or thread groups

• Get the protection domain for a class

• Read or write file descriptors

• Access or define a class in a package

• Access declared members of a class

An application may queue up a print job. Web applications and application clients can also link to native code libraries, and application clients can also exit the VM. Most of these restrictions can be overcome by requesting permission to do so in the extended deployment descriptors for the application.

Process-Related Thread Functions

You cannot normally spawn threads using the J2SE threads package from your applications hosted in the application server. The reasons for this are fairly simple: threads that you spawn will not carry the implicit context that the application server normally places on a thread, and WebSphere cannot monitor threads that you create if it does not know about them. Consequently, if you use any part of the J2EE programming model from that spawned thread, including making calls on EJBs, the container will not have the information it needs to manage the request properly. In most cases, your thread will fail, or at least create unexpected results.

If your thread should fail, the failure probably won't be detected by WebSphere and so it won't be able to recover it – either to reclaim the resources occupied by that thread or to attempt to restart it to complete the work it was performing.

Since WebSphere is not aware of the thread, it is in turn not aware of the work being performed on the thread, and therefore will not account for the impact that additional thread has on the overall workload being hosted in the server. This will affect its workload balancing decisions – potentially causing the server to over-allocate work to the server and resulting in significant throughput or performance problems with your server.

A major tenet of the WebSphere workload management architecture is the idea that servers in a cluster can serve any request to the applications hosted in that cluster. One request to an application component may be routed to one application server instance, and the next request may be routed to another instance. The application server leverages the J2EE component model to manage component state to ensure that the policies stated for integrity, consistency, throughput, and so on are being met. However, if you have spawned un-managed threads on behalf of your components, any state retained on that thread would not be managed across the cluster. The additional thread may or may not be aware of workload rebalancing decisions, and consequently may not be seeing all that you might want it to see of the subsequent requests made to your application in any given application server instance.

Finally, the threading and dispatching model in the WebSphere Application Server (in J2EE itself) is opaque to your application. The algorithms used for dispatching and threading are refined constantly for improving performance and throughput. The presence of your thread can have a detrimental effect on the dispatching techniques being used by the application server and can undermine any benefit that you might otherwise expect to achieve with WebSphere.

The bottom-line is: you should not be spawning threads within your application.

In prior releases, the WebSphere Application Server on distributed platforms (not including WebSphere for z/OS) did nothing to enforce this constraint. Starting in version 5.0, WebSphere has enabled the Java 2 SecurityManager and applications are not granted access to the Thread APIs.

However, if you absolutely must spawn your own threads – you may have integrated a third-party package that spawns its own threads – there are two things you can do to get around the limitation stated above.

The first involves requesting permission to access the J2SE threads library. The process for doing this is discussed further in the later section Enabling Privileged Code. By making this explicit request you are assuming responsibility for the consequences. That is not a legal statement, but is designed to give you control over that decision, and to help avoid cases where you accidentally get into a negative situation. You must avoid using any aspect of the J2EE programming model with threads spawned using this technique – in particular, you must avoid looking up and calling EJBs or web services through the WebSphere client interfaces, you must avoid using any data source or JCA connections that require connection pooling or transactional integration with the rest of your J2EE application.

The second and preferred approach is to use the Async Beans programming model extension provided in the Enterprise Edition of WebSphere. The work manager of Async Beans give you a programmatically safe way of spawning threads. In effect, work manager veneers the threads package, but does so in a way that the application server has knowledge of any threads spawned with this approach. The application server can manage the propagation of context, and can assist in managing state, recovery, and the workload implications of the additional thread. You can program to the full J2EE client application programming model in the thread spun by the work manager. The work manager service is discussed further in Chapter 11.

Other Language Classes

In addition to the language classes discussed above, Java also provides support for references and reflection. WebSphere does not place any specific restriction on the use of these classes in your applications. However, you should be aware that if you attempt to manipulate the behavior of the garbage collector, you could have an impact on the efficiency of garbage collection in ways that are not immediately obvious. For example, WebSphere has its own controls for managing the garbage-collection cycle during periods of idleness. Thus, you should avoid trying to manipulate the garbage collector in your application through the use of references if at all possible.

Math

The math classes are provided to help your application deal with very large or very precise integer or decimal values. WebSphere places no restrictions on your use of these math classes.

Network

You can create outbound sockets and send messages in the WebSphere Application Server. You should not create an in-bound socket listener in your application code. The reason for this is at least two-fold: first, doing so generally requires creating additional threads for handling any in-bound work coming in on the socket. We've already discussed the issues associated with threading above. Second, the work that gets executed as a result of in-bound messages will not be properly conditioned with the context that the application server needs for it to work properly.

In version 5.0, WebSphere will begin enforcing this constraint through J2SE permissions. A language exception will be raised in your application if you attempt to create an inbound socket.

If you absolutely must create an inbound socket, or if you're using a package supplied by another source that does, you can get around this restriction by requesting additional permissions for your application during deployment.

RMI

An application can use RMI/JRMP or RMI/IIOP to make requests on another server environment, assuming the target server supports the appropriate protocols. A CORBA server, for example, can be called using RMI/IIOP. An application may not, however, construct an RMI server in the WebSphere Application Server. WebSphere does provide a standalone C++ CORBA server conforming to the base CORBA 2.1 specification as part of the Enterprise edition.

As an aside, a CORBA client can invoke an EJB over IIOP – although this can be complicated by the Java mappings of EJB types in IIOP, depending on the source language. This, however, is independent of RMI.

Security

The security classes in the J2SE platform are considered a part of the Java 2 Security manager programming model. As we discuss later in this chapter, and then again in Chapter 13, you are discouraged from programming directly to security classes in your application. More than that, though, the J2EE permissions prevent you from using many of these security interfaces – deferring instead to the container to keep your applications protected.

SQL

The SQL classes form the base-line for the JDBC programming model. WebSphere assumes these will be used in the manner described by the J2EE specification. The J2EE permissions will prevent you from setting the log stream for the JDBC driver.

Text

The text classes supplied by J2SE support common functions for formatting text strings, including support for resolving internationalization conventions. WebSphere places no restrictions on the use of these classes.

Utility Classes

The utility classes cover a number of interesting programming functions, including various forms of collections (hash table, sets, lists, maps, iterators, etc.), a variety of date, time, and calendar functions, and other odds and ends such as a pseudo-random generator. J2SE also introduces a set of extended utility functions for manipulating JAR and ZIP streams. The only restriction that J2EE imposes is on the Properties class.

Properties

Application clients, applets, servlets, and EJBs can only read property values. You must request permission to set property values from any of the WebSphere runtime environments.

Java 2 Standard Edition Extensions

In addition to the packages included in the base J2SE, WebSphere packages and ships standard extensions. Let's discuss these extensions in turn.

JCE

The Java Cryptographic Extension (JCE) provides support for encrypting and decrypting data. WebSphere supports the JCE interface and supplies a provider and cipher suites. WebSphere does not, itself, support third-party providers. If you must introduce your own provider to the JCE interfaces for use within your application, you must do so in a way that does not introduce your provider into a WebSphere runtime classpath. If you do use your own provider, it is your responsibility to ensure that the provider conforms to the proper export regulations. See http://home.doc.gov/ and http://www.bxa.doc.gov/ for more information on export regulations for cryptographic functions.

JSSE

The Java Secure Sockets Extension (JSSE) provides support for creating secure sockets for SSL version 1 or 2, or TLS v1.0. WebSphere supplies a JSSE provider. As with the network packages of J2SE, you can create an outbound socket with JSSE, but you should not create an inbound socket. Again, you can override this constraint by requesting permissions for inbound sockets.

PKCS

The Public Key Cryptography Standards (PKCS) packages provided by WebSphere are not actually a part of the official J2SE standard extensions. However, they provide a set of useful functions for managing public keys for the standards defined by RSA. They include support for:

• PKCS #1: RSA Encryption

• PKCS #5: password-based Encryption; enables encryption of an octet string with a key derived from a password

• PKCS #7: defines a general syntax for Data, SignedData, and EnvelopedData that may have cryptography applied to it

• PKCS #8: establishes a standard syntax for private key information

• PKCS #9: provides standard object types for various security-related attributes, such as a challenge password, counter signature, e-mail address, message digest, and so on

• PKCS #10: defines a standard syntax for issuing certification requests – such as getting a X.509 certificate signed by a Certificate Authority

• PKCS #12: describes a transfer syntax for personal identity information

• PKCS #11 is covered within the JSSE extensions. Generally, you will only want to use these interfaces if you are programming a public key infrastructure. Otherwise, the majority of reasons for using these functions are already handled for you in the implementation of the WebSphere Application Server and its related administration tools. For more information, go to http://www.rsasecurity.com/.

Java 2 Platform, Enterprise Edition

The WebSphere Application Server version 5.0 conforms to the J2EE 1.3 specification, and as such supports the entire suite of the J2EE-defined APIs across all editions and platforms. With the exceptions noted below, all of the J2EE programming features are available on all platforms supported by WebSphere Application Server – Windows, Solaris, Linux, AIX, HP/UX, iSeries, and z/OS. The following summarizes the J2EE packages and how WebSphere supports them.

Servlet 2.3

The servlet specification defines the component model for servlet-based presentation logic, along with HTTP session state, context, and device information. A servlet is used to generate dynamic content – presentation content that is derived dynamically by executing the logic contained in the servlet implementation. With version 5.0, WebSphere introduces additional support for servlets:

• Filters
  Allow you to externalize processing of request and response messages to the servlet as defined by the Servlet 2.3 specification.

• Lifecycle Listeners
  Can be introduced to receive events that indicate different phases in the application's execution lifecycle as defined by the Servlet 2.3 specification. These include the following new listeners:

  ServletContextListener

  ServletContextAttributeListener

  HttpSessionListener

  HttpSessionAttributeListener

  HttpSessionActivationListener

  and corresponding event classes to go with these.

• Internationalization Enhancements
  Allow you to control how internationalization context will be handled for your servlet. In particular, the Servlet 2.3 specification introduces a new method on the ServletRequest interface, setCharacterEncoding(), that can be used to control the character set the web container will use for reading the request's parameters and to post data. In addition, WebSphere further extends the internationalization support for servlets by introducing a pair of new deployment descriptors – request-encoding and response-encoding. These are described further later in this chapter.

• New Error and Security Attributes
  New error and security attributes are introduced as defined by the Servlet 2.3 specification. These include:

  javax.servlet.error.exception_type

  javax.servlet.error.request_uri

  javax.servlet.request.cipher_suite

  javax.servlet.request.key_size

• HttpUtils Deprecation
  The HttpUtils class has been deprecated (the class will still exist but you will get deprecation warnings from the compiler), and has been replaced with the getRequestURL() method on the HttpServletRequest class, and the getParameterMap() method on the ServletRequest class.

• New Context, Response, and HttpSession methods
  Introduction of the following methods as per the Servlet 2.3 specification:

  ServletContext.getServletContextName

  ServletContext.getResourcePaths

  ServletResponse.resetBuffer

  HttpSession.getServletContext

In addition to the standard interfaces defined by J2EE for servlets, IBM also supports a set of extensions that can be useful for some web application scenarios.

Important

As always, you have to be aware that if you take advantage of these extensions, you will end up with an application that may not be portable to other vendor's application servers.

The WebSphere extensions include:

• com.ibm.websphere.servlet.cache
  Introduces classes that help you enable your servlet to be used with the WebSphere Dynacache facility.

• com.ibm.websphere.servlet.error
  This is a specialization of ServletException that can be used to produce a more detailed description of the error being reported by the servlet.

• com.ibm.websphere.servlet.event
  Enables you to listen for various events pertaining to servlets and web applications.

• com.ibm.websphere.servlet.filter
  Defines a mechanism by which you can set up servlet chains to aggregate partial responses from different servlets.

• com.ibm.websphere.servlet.request
  Extends the standard ServletStream to allow stream manipulation, and introduces a servlet request proxy.

• com.ibm.websphere.servlet.response
  The corollary to com.ibm.websphere.servlet.request, and also includes support for generating and storing predefined responses.

• com.ibm.websphere.servlet.session
  Introduces support for managing HTTP session state across clusters.

The servlet model defines deployment descriptors that can be used to describe policies for how the servlet should be managed by the web container. These include policies for how the servlet should be protected, initialized, and loaded, how to resolve references to other resources, and attributes about the servlet.

The following table lists all of the deployment descriptors supported for servlets in WebSphere. All of the J2EE deployment descriptors conform to the definition provided in the Servlet 2.3 J2EE specification available at http://java.sun.com/products/servlet/download.html. In addition, WebSphere supports other extended deployment descriptors. These are marked in bold-italic and will be discussed further below:

additional-class-path	env-entry-type	large-icon	res-ref-name	taglib
auth-constraint	env-entry-value	load-on-startup	res-type	taglib-location
auth-method	error-code	location	role-link	taglib-uri
context-param	error-page	login-config	role-name	transport-guarantee
default-error-page	exception-type	mime-mapping	security-constraint	url-pattern
description	extemsopm	mime-type	security-role	user-data-constraint
directory-browsing-enabled	file-serving-enabled	param-name	security-role-ref	web-app
display-name	form-error-page	param-value	serve-servlets-by-classname-enabled	web-resource-collection
distributable	form-login-config	realm-name	servlet	web-resource-name
ejb-link	form-login-page	reloading-enabled	servlet-class	welcome-file-list
ejb-ref	http-method	request-encoding	servlet-mapping	welcome-file
ejb-ref-name	home	response-encoding	servlet-name
ejb-ref-type	icon	remote	servlet-config
env-entry	init-param	resource-ref	servlet-timeout
env-entry-name	jsp-file	res-auth	small-icon

All of these deployment descriptors can be specified in the WebSphere Application Assembly Tool – a GUI-based tool for assembling WARs, EJB Modules and their related JARs into a J2EE Enterprise Application or in WSAD.

additional-class-path

If, in your web application, you want to refer to other JARs, classes or other resources that are not included in your J2EE Application (EAR), you can use this element to define the classpath to those resources.

default-error-page

You can specify the default error page in this element, to use in case no other error page is specified in the application.

directory-browsing-enabled

This element can be set to true if you want the web application to be able to browse the local directory system. You should set this to false if you want the file system to be protected from anyone who may use this application to maliciously interrogate the file system.

file-serving-enabled

If you want to be able to serve static content from this application, you can set this element to true – which it is by default.

reloading-enabled

Set this element to true if you want to allow the application to be re-loaded. It is false by default.

request-encoding

J2EE has clarified the encoding rules for servlet request and response messages. The clarification does not agree with the encoding rules that had been used in WebSphere previously. This element can be used to establish which set of encoding rules WebSphere will use for the web application.

response-encoding

Same as request-encoding.

serve-servlets-by-classname-enabled

Normally, servlets are only addressable by their URI name. This element can be set to true if you want to be able to address a servlet by its classname.

JSP 1.2

The JavaServer Pages (JSP) specification defines a powerful mechanism for creating dynamic content. A JSP page is essentially a template of the web page that you want generated, but with in line code or JSP tags that make it easy to condition portions of the page.

The JSP specification describes the use of the Java language for scripting the conditional elements of the JSP. WebSphere uses the extension mechanisms in the JSP specification for introducing support for other scripting languages in the JSP – in particular, JavaScript.

The JSP 1.2 specification introduces:

• XML support for JSP pages
  Allows you to encode your JSP page in fully conformant XML.

• Tag-lib Validation
  Allows you to validate a tag in the context of an entire page and provides better validation messages.

• New Tag Support for Iteration
  Iteration can be performed in custom tags without having to introduce a Body tag. This makes it easier to introduce simple iterators, and improves JSP performance for these cases.

• Tag Library Support for Application Lifecycle Events
  Tag libraries can introduce event listener classes corresponding to the Listeners introduced by Servlet 2.3.

The JSP engine in the web container compiles JSP pages when they are first invoked. The compiled classes form a servlet and so the rest of the JSP processing conforms to the servlet execution model. Since compiling the JSP on the first invocation can be somewhat time consuming and can affect the response time for that JSP page, you can instruct WebSphere to pre-compile the JSP by setting the pre-compile JSP pages flag on the Web Module in the assembly tool for your enterprise application.

EJB 2.0

The EJB specification defines the component model for business logic. The EJB specification introduces three types of enterprise beans: session beans, entity beans, and message-driven beans. Session beans can be both stateless and stateful, and generally represent business functions in your business model. Entity beans are generally stateful and persistent, and their persistence is either managed by the bean implementation or by the container. Entity beans should be used to model entities in your business model – such as Account or Customer objects. Message-driven beans don't necessarily represent elements in your business model, but can be used to listen for and respond to asynchronous messages that your application may be interested in.

The EJB 2.0 specification introduces several important innovations to the EJB component model, including:

• Introduction of local interfaces for EJBs. This allows you to define EJBs that benefit from component management without exposing them to the design implications of those components being potentially distributed – that is, EJB to EJB communication through local interfaces will be dramatically more efficient. Moreover, the local interface support allows you to distinguish between shared EJB behavior – methods that you want to be made available to any client – versus private, or localized, EJB behavior – methods that you only want made available to other components hosted in the local execution space.

• Integration with the Java Message Service (JMS) with the introduction of message-driven beans

• Support for container-managed relationships allowing you to model relationships in your business and manipulate and navigate these through application logic. These relationship definitions can also be leveraged in portable queries – you don't have to encode queries with specific knowledge of how these relationships are encoded in the data system in which the EJB state is held.

• A common and portable query language for specifying static queries over collections of enterprise beans. EJB Query Language (EJB QL) uses a SQL-like syntax with extensions for the object-oriented nature of EJBs, and can be mapped to any relational-database-specific query syntax.

• Custom home methods allow you to introduce the equivalent of static methods to the enterprise bean implementation model.

• The run-as security identity element allows you to specify the particular security role that you want the enterprise bean to run with.

• The addition of the Common Secure Interoperation V2 (CSIv2) protocol to RMI/IIOP to help ensure secure interoperation between J2EE vendors and with other CORBA vendors.

These additions make EJBs implemented and deployed for container-managed persistence much more effective.

JDBC 2.0 Extension

As its name suggests, the JDBC 2.0 Extension is an extension of the JDBC 2.0 core APIs included in J2SE. The core APIs are included in the java.sql package, and the standard extensions are included in the javax.sql package. The extension introduces support for:

• JNDI-based data source names
  You can specify the data source that you want to use by JNDI name, thus freeing us from having to hard-code the data source name in our application code.

• Connection pooling
  Connections are obtained and managed from a connection pool. A specific set of connections to the data source can be created and shared among many instances of objects that will use these, thus avoiding the overhead of creating and destroying a connection on each use.

• Distributed transactions
  XA-based global transactions can be created and used to commit coordinate updates to multiple different data systems in the same transaction.

• Rowsets
  Rowsets represent a set of rows in the database, and essentially cache the contents of those row-tuples. Rowsets use an optimistic concurrency model – extracting the rows from the database and caching them in the rowset, without retaining a lock on the data in the database. On the one hand, this allows concurrent access to the data in the underlying database and in that way improves system throughput. On the other hand, it requires that you handle updates very carefully to ensure you don't invalidate changes that may have been made while you were operating from your local rowset cache. Of course, you will be exposed to these concerns only if you're using Bean-Managed Persistence (BMP). With Container-Managed Persistence (CMP) you will not use the JDBC interfaces directly, and the container will manage these concerns for you.

WebSphere provides support for a variety of databases, including:

• DB2/UDB Connect, Workgroup, Enterprise Edition, and Enterprise-Extended Edition v7.2

• DB2/UDB for iSeries v5r1 (WebSphere for iSeries only)

• DB2/UDB for z/OS and s/390 v6.1 and v7.1

• Informix Dynamic Server v7.2 and v9.3

• Oracle Enterprise Edition 8i and 9i

• Microsoft SQLServer v7.0 and v2000

• Sybase Adaptive Server v12

In addition, WebSphere ships with Cloudscape 5.0.3 that can be used for samples and prototyping purposes – it cannot be used in production. WebSphere also ships and works with the Data Direct (previously known as Merant) Connect JDBC Type 4 drivers. This, of course, is just the current support. Any updates to this list are posted at the IBM web site for WebSphere at http://www-3.ibm.com/software/webservers/appserv/doc/latest/prereq.html. Generally, WebSphere works with the JDBC drivers supplied by the corresponding database vendors. JDBC drivers are categorized by how they're constructed.

• Type 1 drivers
  Type 1 drivers are implemented to bridge to ODBC – ODBC binaries must be installed on the platform to use a Type 1 driver.

• Type 2 drivers
  Type 2 drivers use JNI to call into native APIs for the database. While these don't require you to install the ODBC binaries, they may require other native binaries.

• Type 3 drivers
  Type 3 drivers are implemented entirely in Java, but operate to a canonical middleware protocol leaving the middleware responsible for mapping its protocol to the database-specific protocols of the databases it supports. WebSphere does not provide such a protocol, although prior versions of WebSphere shipped Data Direct (Merant) SequeLink supporting such a protocol. This has been dropped from WebSphere version 5, and replaced with Data Direct Connect JDBC Type 4 drivers.

• Type 4 drivers
  Type 4 drivers are also implemented entirely in Java to work directly with the specific DBMS protocols supported by the corresponding database.

The differences between these types should be immaterial to your application's implementation – the semantics of the JDBC interfaces remain entirely consistent across all types of JDBC drivers. However, the differences in these drivers may affect the installation procedures and prerequisites for your application. These differences are handled through the WebSphere administration facilities.

JTA 1.0

The Java Transaction API (JTA) provides interfaces that allow you to begin and commit global transactions. If you begin a transaction, initiate a set of updates, and then commit the transaction, the updates that you initiated will be committed as an atomic unit of work – that is, either all the updates will be applied, or none of them will be applied. This will dramatically reduce the complexity of your application. See Professional EJB (Wrox Press, ISBN 1-86100-508-3) for more information on global transactions and EJBs.

The transaction manager that implements JTA is built into WebSphere and supports local and global, single-phase, and two-phase commit transactions, depending on the resources used during the transaction. The WebSphere transaction manager will automatically federate other transaction manager instances in the transaction if the method you invoke cascades across other server instances or platforms. For example, if you invoke a method on an EJB on an instance of WebSphere running on a Solaris machine and that method, in turn, invokes another method on an EJB running on a z/OS machine, the resources that you touch on the Solaris machine will be commit-coordinated with the resources you touch on the z/OS machine. All the updates you initiate will be committed, or none of them will, depending on whether any errors were encountered in the transaction.

Further, the WebSphere transaction manager has built-in optimizations for recognizing when only one resource is involved in the transaction, and for when a single-phase commit resource is included in a transaction that involves other two-phase commit resources (only one single-phase commit resource can be combined in a mixed transaction like this).

The WebSphere transaction manager conforms to the CORBA Object Transaction Service (OTS) protocol and therefore is fully interoperable with other vendor application servers also conforming to this specification as required by J2EE 1.3. In accordance with the specification, session-beans can use either container-managed or bean-managed transaction demarcation. Entity beans, however, must use container-managed transaction demarcation.

Limitations

The javax.transaction.TransactionManager interface cannot be used by application components hosted in the WebSphere Application Server.

Enlisting and delisting a javax.transaction.XAResource is supported for Java 2 Connectors only on the z/OS platform.

Unlike prior versions of WebSphere, the user transaction service can only be obtained from java:comp/UserTransaction – it can no longer be got from jta/usertransaction. The user transaction service cannot be obtained from the J2EE client container. You must demarcate the transaction with either CMT, or with BMT in the EJB container on the application server.

JMS 1.0.3

The Java Message Service (JMS) provides support for exchanging messages between message providers and consumers. The JMS specification defines two different models for exchanging messages.

The first is referred to as point-to-point messaging, where the provider and consumer are explicitly aware of each other and communicate messages directly between themselves – possibly over a messaging network that uses a series of intermediaries to propagate the message over the network.

The other type of messaging defined by JMS is a 'publish and subscribe' model. This is where providers publish classified messages to anyone that may be interested in that classification of message – without any specific knowledge of who that might be. Consumers then register a subscription to a class of messages. The pub/sub model normally involves an intermediate message broker responsible for managing the distribution of published messages to various subscribers. In the pub/sub model, the same message may be re-distributed to any number of consumers that have registered a subscription to that message.

JMS is the only specification for which J2EE requires conforming application servers to supply a fully implemented provider. To that end, the WebSphere Application Server product ships with an embedded JMS implementation supporting persistent, point-to-point, and a high-volume publish and subscribe engine. Like other provider frameworks, such as JDBC and J2EE Connectors, this implementation can be replaced with other providers. In particular, IBM offers the WebSphere MQ product that supports the JMS interface and can be plugged into the WebSphere Application Server.

Note

The integral JMS provider in WebSphere Application Server is largely based on the WebSphere MQ messaging engine. It provides support for the complete JMS programming model, including persistence. However, it does not provide clustering support for its message broker, nor for interoperation with non-WebSphere messaging applications. The WebSphere MQ provider, on the other hand, does enable clustering support, and interoperation with MQ-based applications outside of WebSphere.

WebSphere supports connection pooling of JMS connections, and integration of JMS messaging operations in a global transaction. You can coordinate the commitment of a message to or from the message connection along with other updates to your database. For example, if you want to update an Account object, and publish a notification about that update in the same transaction, then you can be assured that the notification is not sent unless the update to the account is actually performed.

J2EE Connector Architecture 1.0

The Connector specification defines a mechanism by which you can create connections to third-party data systems such as CICS, IMS, SAP, Peoplesoft, and so on – thus enabling integration between J2EE and non-J2EE-based applications and components. Since different data systems pose different constraints on how they can be connected, the connector architecture accommodates different connectors with different qualities of service. The architecture puts the burden on the connector to establish its relationship to the application server runtime and containers. The connector is given access to runtime security and transaction context through a connector service provider interface (SPI) from which it can federate in the backend data system in a sensible manner as pertains to that data system.

Applications interact with the connector through either the Common Client Interface (CCI), or through a higher-level abstraction introduced by individual application development tools. Any abstraction introduced by a development tool should be implemented to map down on to the CCI – the abstraction is intended to simplify the programming model for applications as a matter of convenience, not to invalidate the basic programming model offered by the connector specification.

The WebSphere Studio Application Developer Integration Edition provides tooling to create a stateless session bean based adapter for connectors. Applications are written using the stateless session-bean programming model – hiding the nuances and complexities of the CCI.

WebSphere provides support for connection pooling, integrating both single-phase and two-phase enabled connectors and for authenticating a principal in the connection request.

JAAS 1.0

The Java Authentication and Authorization Service (JAAS) provides interfaces for creating and manipulating principal credentials. WebSphere does not place any specific restrictions on your use of the JAAS interfaces in version 5.0. Many of the additional classes provided by WebSphere in this space are specific implementations of the abstract classes and interfaces introduced by the standard extensions. In particular, IBM introduces a number of specific credential types. You will only be able to use those specific credential specializations that correspond with the particular authentication mechanisms that you have configured. In general, we do not recommend that you program specific knowledge of the derived credential types into your application – limit yourself to the abstract interfaces of the credential types.

JAXP 1.1

The Java API for XML Processing (JAXP) specification defines the interfaces for XML parsing and operating on XML documents. The XML parser support defined by JAXP includes provisions for both Document Object Model (DOM) and Simple API for XML (SAX) styles of parsing. In addition, the specification supports XML namespaces, and XML Stylesheet Language Transformations (XSLT). This API is supported in WebSphere with the Apache Xerces and Xalan packages shipped with WebSphere.

Since these packages have undergone a fairly rapid evolution you may prefer to use your own version of these services in your application. WebSphere can accommodate this – the class-loading facilities in WebSphere allow you to introduce your own version of these types of services in your own application package. Even if the class names collide with those supplied by WebSphere, WebSphere will bind your application to the version that you supply for yourself in your application and will prevent it from interfering with WebSphere's own use of the version that it supplies.

JavaMail 1.2

The JavaMail specification defines interfaces for getting and sending e-mail. WebSphere simply ships the Java reference implementation for JavaMail with providers for Simple Message Transfer Protocol (SMTP) for sending mail, and Post Office Protocol (POP3) or Internet Message Access Protocol (IMAP) for receiving mail. You must connect these to your favorite mail service if you want to use these in your application. The WebSphere administration facilities allow you to configure the default mail provider to reference your mail system – the mail provider is a configurable resource.

JAF 1.0

The Java Activation Framework (JAF) implements a fa ade pattern for mapping MIME types to specific commands and components that can operate on those types. The JAF is used by the JavaMail service for handling MIME attachments. See http://java.sun.com/products/javabeans/glasgow/jaf.html for more information about JAF.

Web Services

As we discussed earlier in this chapter, web services technology has grown rapidly as an important mechanism for interconnecting distributed services over the Internet, and more recently, over the intranet. In recognition of the strategic value of web services to the industry, several organizations have begun to standardize various web service definitions – including, among other things, the Java interfaces for invoking a web service. JSR 101 defines the Java APIs for XML RPC (JAX-RPC) and sets the standard for how Java applications should invoke a web service. This standard is embraced by JSR 109, which defines the Implementation of Enterprise web services in a J2EE environment. JSR 110 defines Java APIs for WSDL interfaces for creating, reading, and manipulating WSDL documents. JSR 93 defines a Java API for XML Registries (JAX-R) that can be used to access UDDI.

None of these specifications are currently part of the J2EE specification and so entirely represent extensions to the standard J2EE programming model. None of the interfaces associated with the web services support in WebSphere are considered portable to other J2EE-conforming application servers at this time.

W3C, of course, is in the process of defining standard specifications for SOAP and WSDL, and continues to make progress in the area of context specification and propagation. In addition, recent work between IBM and Microsoft has concluded a strategic direction and de facto standard specification for web services security. In addition, IBM, Microsoft, and several other vendors have formed the WS-I organization (see http://www.ws-i.org) to formulate the baseline for multi-vendor interoperation of web services.

WebSphere version 5.0 remains up to date with the latest and emerging standards. The web services programming model and features for WebSphere are introduced here, and will be discussed in much more detail in Chapter 8.

Invocation Programming Interfaces

WebSphere version 5.0 maintains backwards compatibility to the Apache SOAP 2.2 proxy interface and the WebSphere Studio Application Developer stub interfaces introduced in WebSphere and WSAD version 4. If you wrote applications for version 4 that use these interfaces, you can continue to host these applications in version 5. However, you should realize that these interfaces will be deprecated in a future release and so you should begin to convert these applications over to using the new JAX-RPC interfaces.

JAX-RPC defines a mapping of XML types to Java types and WSDL portTypes to Java interfaces, and in doing so, enables a type-based interface to the web services that you want to invoke in your application. Interfaces conforming to the JAX-RPC specification provide the appearance of local-remote transparency and are used much like EJB remote interfaces. The interface representing a WSDL portType is called a Service Endpoint interface. Of course, as a general rule you should assume that web services are loosely coupled and you should therefore program to them accordingly.

The general model is that you will locate the WSDL of the web service that you want to use. You will import WSDL into your development environment and use it to generate a JAX-RPC Service Endpoint Interface and underlying implementation artifacts representing that web service to your application. You can then simply code directly to this interface to invoke the operations that you want to use. The JAX-RPC implementation is then responsible for converting your Java types into XML, marshaling the result into a web services message and invoking that on the binding and port defined in the WSDL for the target web service.

WebSphere Studio Application Developer adds built-in support for JAX-RPC invoking the web service to a standard SOAP over HTTP binding and port. WebSphere extends that support to invoking web services requests over a variety of binding and encoding mechanisms. The WebSphere binding extensions can be used without changing your application by configuring the JAX-RPC service to return a different implementation of the Service Endpoint Interface to your application.

Web Services Invocation Framework

The multi-protocol support enabled by WebSphere is provided by the web services Invocation Framework (WSIF) integrated into WebSphere. WSIF enables communication of web services over a variety of protocol stacks, including the traditional SOAP over HTTP, SOAP over JMS (over WebSphere MQ, for example), and a direct call on a local Java object or EJB that implements the web service.

Protocol selection is managed by the WebSphere runtime. The result is that you can program your application to a type-based interface based on the WSDL definition of the web service, but allow the runtime to resolve the binding to the Web Service based on the quality-of-service requirements of your topology – reinforcing the relationship and separation of concerns enabled by the J2EE Application Developer, Assembler, and Deployer roles.

WSIF also introduces a lower level dynamic invocation interface (DII) exposing the primitives of the invocation process. The DII only deals with XML types and so does not concern itself with the mapping of Java type representations. The same web services Invocation Framework, integrated into WebSphere, has been made available as an Apache open source project – as part of the XML-Axis project (http://xml.apache.org/axis/index.html).

Web Services Security

WebSphere version 5 implements the latest de facto Web Service specification on security – specifically to enable principal authentication, context propagation, and message integrity and protection based on document signing and encryption. The message integrity and protection portion of the web services security specification draws heavily from the SOAP-SEC technology previewed in WebSphere version 4 and so moving to the WS security specification is relatively easy if you did exploit SOAP-SEC in version 4.

In addition, support for propagating principal identity, user name tokens, and X.509 certificates is included in WebSphere version 5. Support for propagating Kerberos credentials should be coming shortly. None of these require any specific programming for applications hosted in the WebSphere Application Server. Anything that you do to establish or manipulate credentials using the JAAS (remembering that these activities should be limited to only those cases where the runtime does not perform credential management in the way that you need for your application) will automatically be applied to the credentials that flow over the web services protocol.

Web services hosted in WebSphere are implemented and deployed in a J2EE enterprise application – generally implemented or wrapped in a stateless session bean. As such, you can apply authorization protection to your web service using the standard J2EE Roles-based authorization mechanisms provided to any J2EE application.

Web Services Gateway

WebSphere version 5 introduces a Web Service gateway. This gateway can be used to represent an aggregation of web services, and as an intermediary for web services message processing in the network. For example, you may have a set of web services that you define in your intranet. If you want to expose only a subset of these to the Internet you can deploy Web Service proxies expose them on the port and bindings for the gateway to the Internet. Thus, all Internet-borne Web Service requests will be directed to the gateway. The web services proxies hosted in the gateway can then re-direct those requests to the real web service implementations in your intranet.

If you want to add other intermediary functions like tracing Internet web services requests, or doing special field checks, you can introduce a filter and extend the Web Service proxies in the gateway.

An additional benefit of the gateway is in enabling you to federate different Web Service middlewares under a single deployment-administration model. For example, you may have a mix of WebSphere and, say, Microsoft IIS-based web services in your data center, but you want to administer a common and consistent authorization and security protection model on all of your web services. You can introduce Web Service proxies in the WebSphere web services gateway that represent your IIS-based web services. Since WebSphere web services proxies are deployed like any other Web Service implementation hosted by WebSphere, you can apply the same procedures for establishing and maintaining security policies as you would for any other WebSphere-hosted Web Service. The result is a common and consistent model for managing your web services across your enterprise – even those that may be hosted in other application execution environments.

Universal Description, Discovery, and Integration Registry (UDDI)

UDDI directories play a key role in the overall web-services lifecycle as a repository of web-services definitions. Web services providers will typically publish the WSDL for their web service in a UDDI directory. Web service consumers then will search the UDDIs for a web service that meets their needs, and then build a web-service client to exploit that service.

IBM, Microsoft, HP, SAP, and others now host public UDDI business registries for exchanging web services definitions in the public domain. You can access the IBM UDDI business registry at https://www-3.ibm.com/services/uddi/protect/registry.html. Anyone can access these UDDI directories to find web services. Subscribers can publish their web services in these registries.

Generally, it's not a good idea to be unit testing your web service by publishing your WSDL in these public registries for reasons that you can well imagine. Also, there are cases where you will want your own UDDI for use within your enterprise, or in a private network of close business partners. WebSphere version 5 provides a private UDDI registry that you can use for these purposes. The WebSphere UDDI Directory is a scalable UDDI implementation that you can deploy in a WebSphere network like a J2EE application. You can set up several directory instances – each representing a different registry need.

The WebSphere UDDI Directory supports the standard UDDI v2 specification. In addition, the UDDI can be accessed via JMS messages, or an EJB Session Bean interface.

Additional Functions of WebSphere

The core WebSphere Application Server provides additional functions that are not part of the J2EE specification, and that haven't been discussed above as extensions to J2EE. These additional functions are discussed here briefly.

Struts and the Struts Tag Libraries

WebSphere integrates and supports the Struts programming framework as described by the Apache Jakarta project, which you can check out at http://jakarta.apache.org. Struts is a framework that implements the Model-View-Controller design pattern for presentation logic. This framework creates an interworking between servlets (controller), JSP pages (view), and JavaBeans that can then be adapted to EJBs for model elements.

In addition, Struts introduces a standard taglib for various presentation elements and view types, as well as common logic, HTML, and bean constructs such as iteration, links, and parameters.

WebSphere Application Server Extension APIs

Beyond the core extensions shipped in the base WebSphere Application Server, WebSphere also offers a broad set of additional runtime features for enabling a number of enterprise integration scenarios as described in the Integrated Enterprise Computing model discussed earlier in this chapter. These features include:

• Activity Sessions
  Define a unit of work scope that generally aggregates multiple transactions. An activity session may be used to enclose the use of multiple independent resources – enabling a best-effort level of atomicity over resources that otherwise cannot be commit-coordinated that would be hard to create on your own. In many ways an activity session is similar to an HTTP session, except that it is targeted for use by EJBs.

• Application Profiles
  Enable you to define different access intent policies for different clients. This allows the EJB container to manage the same EJB differently for different usage scenarios. For example, one client can get the benefits of container management that is tailored to the set of relationships that client will use, while another client can get equal benefits for the set of relationships it will use, even if the relationships it uses are completely different from the first client.

• Asynchronous Beans and Scheduler
  Provides you with a safe mechanism for spawning parallel work (multiple threads); think of it as asynchronous message processing at a local level. WebSphere ensures the work threads are properly conditioned with context, and monitors the workload on these threads – recovering them if they fail, and accounting for the workload they create. This feature is extended with a Scheduler function that allows you to schedule asynchronous work for execution at some well defined point in time in the future.

• Business Rules Beans
  Continues the tradition introduced by WebSphere Enterprise edition version 4.0. Business Rules Beans can be used to separate the business rules and policies of your enterprise; the relatively dynamic elements of your business logic form the relatively stable and constant aspects of your business functions.

• Choreography
  Builds on the microflow engine introduced in WebSphere Enterprise edition version 4.1 for generalized workflow processing support. This could well be the most important feature of WebSphere Enterprise edition in version 5.0.

• Container Managed Messaging
  Enables a higher level of abstraction for messaging; letting you hide many of the tedious aspects of constructing and interpreting asynchronous messages. This allows your programmers to remain focused on the details of their domain expertise.

• Dynamic EJB Query
  Brings the benefits of object-oriented query and portability associated with the J2EE 1.3 EJB Query Language for use directly by your Java programmers; the equivalent of dynamic SQL for EJBs.

• Internationalization Extensions
  Gives bean developers direct programmatic control over the distributed internationalization context introduced in WebSphere Enterprise edition version 4.0.

• JTA Synchronization Notification
  For those cases where you want to be notified when a JTA user transaction is going through the synchronization phase just before the two-phase commit protocol. The synchronization phase, of course, is the signal to recoverable resources (such as the EJB essential state; data beans) to flush their state out to their respective resource managers.

• Last Agent Optimization
  Enables the intermixing of one single-phase resource with one or more two-phase resource commit-coordination in a single global transaction. If you don't know what this means read about it in Chapter 9.

• Staff Services
  Introduces a concrete implementation of the staff support plug-in of the Choreography service to leverage your LDAP-based directory for organizational information in your enterprise.

• Startup Beans
  Provide you a hook in the application startup process from which you can perform various initialization functions for your application – such as, creating asynchronous beans, performing business notifications, and so on.

• C++ ORB
  Enhances the CORBA, C++ ORB offered in WebSphere Enterprise edition version 4.0 with additional runtime capabilities such as RAS services for logging, portable interceptors, and so on.

These additional features will be discussed in more detail in Chapters 9, 10, and 11.

System Management APIs

Once you've finished building your application you will want to begin to use it. You do that by installing and configuring it to run on a particular WebSphere Application Server instance installed somewhere in your network. The process of installing and configuring your application on a server instance as well as configuring and starting the WebSphere Application Server instance itself is managed through the WebSphere System Management facility. This facility is described further in Chapters 6 and 14.

The WebSphere System Management can be administered through GUI and command-line interfaces provided by WebSphere. The GUI is itself actually a J2EE Web Application that executes in a WebSphere Application Server. The command-line interface can be used with JACL scripting languages. Support for other scripting languages such as Jython and JavaScript will likely be added in the future.

However, there will be cases where you might want to introduce your own application to automate certain WebSphere System Management functions. WebSphere enables you to do so through a JMX interface. The JMX interface is provided through the TMX4J package and is hosted in both individual application server instances, and the Cell manager. You can access the JMX interfaces remotely through either the RMI/IIOP or web services connectors supplied with WebSphere.