Developer best practices

This reference information describes best practices and other considerations for developers.

We can also search for best practice information using keywords.

Subtopics

• Access intent -- isolation levels and update locks
  WebSphere Application Server access intent policies provide a consistent way of defining the isolation level for CMP bean data across the different relational databases in the environment.
• ActiveX client programming, handling error codes
  All exceptions thrown in Java code are encapsulated and thrown again as a COM error through the ISupportErrorInfo interface and the EXCEPINFO structure of IDispatch::Invoke(), the Err object in Visual Basic and VBScript. Because there are no error numbers associated with Java exceptions, whenever a Java exception is thrown, the entire stack trace is stored in the error description text and the error number assigned is 0x6003.
• ActiveX client programming, Java field programming tips
  Using the ActiveX to EJB bridge to access Java fields has the same case sensitivity issue that it has when invoking methods. Field names must use the same case as the Java field syntax.
• ActiveX client programming, Java virtual machine initialization tips
  Initialize the JVM code with the ActiveX to Enterprise Java Beans (EJB) bridge. For an ActiveX client program (Visual Basic, VBScript, or ASP) to access Java classes or objects, the first step that the program must do is to create JVM code within its process.
• ActiveX client programming, threading tips
  The ActiveX to EJB bridge supports both free-threaded and apartment-threaded access and implements the Free Threaded arshaler to work in a hybrid environment such as Active Server Pages (ASP). Each thread created in the ActiveX process is mirrored in the Java environment when the thread communicates through the ActiveX to EJB bridge.
• ActiveX client programming, tips for passing arrays
  Arrays are very similar between Java and Automation containers like Visual Basic and VBScript. This topic provides some important points to consider when passing arrays back and forth between these containers.
• ActiveX client programming best practices
  The best way to access Java components is to use the Java language. IBM recommends that we do as much programming as possible in the Java language and use a small simple interface between your COM Automation container (for example, Visual Basic) and the Java code. This interface avoids any overhead and performance problems that can occur when moving across the interface.
• ActiveX to Java primitive data type conversion values
  All primitive Java data types are automatically converted to native ActiveX Automation types. However, not all Automation data types are converted to Java types (for example, VT_DATE). Variant data types are used for data conversion.
• ActivitySession and transaction container policies in combination
  This topic provides details about the relationship between the deployment descriptor properties that determine how the container manages ActivitySession boundaries.
• Application profiling interoperability
  Using application profiling with 5.x compatibility mode or in a clustered environment with mixed product versions and mixed platforms can affect its behavior in different ways.
• Asynchronous request dispatcher application design considerations
  Asynchronous request dispatcher (ARD) is not a one-size-fits-all solution to servlet programming. We must evaluate the needs of the application and the caveats of using ARD. Switching all includes to start asynchronously is not the solution for every scenario, but when used wisely, ARD can increase response time.
• Client-side programming tips for the Object Request Broker service
  Every Internet InterORB Protocol (IIOP) request and response exchange consists of a client-side ORB and a server-side ORB. It is important any application that uses IIOP is properly programmed to communicate with the client-side Object Request Broker (ORB).
• Common Criteria (EAL4) support
  
• Connection and connection pool statistics
  WAS supports use of PMI APIs to monitor the performance of data access applications.
• DataGraph schema
  
• Default Application
  WAS provides a default configuration that administrators can use to verify that the Application Server is running. When the product is installed, it includes an application server called server1 and an enterprise application called Default Application.
• Dynamic and deployment EJB query services comparison
  Use the dynamic query service to build and execute queries against entity beans constructed dynamically at run time, rather than defining them at deployment time. By using dynamic query you gain the flexibility of queries defined at run time and utilize the power of EJB-Query Language (QL). Apart from supporting all of the capabilities of an EJB-QL query, dynamic query adds functionality not available to standard static query. Two examples are the ability to select multiple data fields directly from the bean itself (static queries currently only allow one) and executing business methods directly in the query.
• EJB 3.x module considerations
  When using EJB 3.x modules, keep in mind the following considerations.
• EJB data mediator service data retrieval
  An EJB mediator request is a compound EJB query. We can obtain a DataGraph using the getGraph call.
• EJB data mediator service data update
  An EJB mediator request is a compound EJB query. We can write an updated DataGraph back to the data source using the applyChanges method.
• EJB data mediator service programming considerations
  When we begin writing the applications to take advantage of the EJB data mediator service (DMS) provided in the product, consider the following items.
• EJB mediator query syntax
  When we begin writing the applications to take advantage of the EJB data mediator service (DMS) provided in the product, consider the following items.
• EJB query language limitations and restrictions
  When using the EJB query language on the product, deviations can be seen in comparison to standard EJB query language. The limitations and restrictions we must be aware of are listed in the following section.
• EJB specification and WebSphere query language comparison
  WAS extends the Enterprise JavaBeans (EJB) query language with elements of its own.
• Enable support for a user-defined value set
  We can enable support for the value set using the administrative console. You do this as part of the procedure to add a user-defined value set to the UDDI registry.
• Enterprise bean development best practices
  Use the following guidelines when designing and developing enterprise beans.

• (iSeries) (ZOS) (Dist) Example: Applet client code requirements
  The code used by an applet to talk to an enterprise bean is the same as that used by a stand-alone Java program or a servlet, except for one additional property called java.naming.applet. This property informs the InitialContext and the Object Request Broker (ORB) that this client is an applet rather than a stand-alone Java application or servlet.
• Example: Applet client tag requirements
  Standard applets require the HTML <APPLET> tag to identify the applet to the browser. The <APPLET> tag invokes the JVM of the browser. It can also be replaced by <OBJECT> and <EMBED> tags.
• Federal Information Processing Standard support
  Federal Information Processing Standards (FIPS) are standards and guidelines issued by the United States National Institute of Standards and Technology (NIST) for federal government computer systems. FIPS can be enabled for WAS.
• How to process IBM MQ message headers
  IBM MQ messages can optionally include additional headers, or alternative headers, to the MQRFH2 header, which contains JMS properties. WAS application programs can use the com.ibm.mq.headers classes to access headers in messages from IBM MQ and to construct headers in messages to IBM MQ.
• Initial context support
  All naming operations begin with obtaining an initial context. We can view the initial context as a starting point in the namespace. Use the initial context to perform naming operations, such as looking up and binding objects in the namespace.
• Internationalization service errors
  Certain conditions might cause the internationalization service not to start, to issue java.lang.IllegalStateException exceptions while an application is running, or to exercise default behaviors.
• JDBC application cursor holdability support
  The cursor holdability feature can reduce the overhead of JDBC interaction with your relational database, thereby helping to increase application performance.

• JDBC application development tips
  By using best practices to help maximize the efficiency of JDBC queries, we can potentially increase application performance.
• JMS formats
  To write code that can access the different JMS message types, we need to know how each message type is mapped to SDO, and how to retrieve the message format string from the message.
• JMS Formats - bytes
  Your program can retrieve the payload of a JMS bytes message by mapping the body of the message to an SDO data graph representing the message.
• JMS Formats - object
  Your program can retrieve the payload of a JMS object message by mapping the body of the message to an SDO data graph representing the message.
• JMS formats - Stream
  Your program can retrieve the payload of a JMS stream message by mapping the body of the message to an SDO data graph representing the message.
• JMS Formats - text
  Your program can retrieve the payload of a JMS text message by mapping the body of the message to an SDO data graph representing the message.
• JNDI interoperability considerations
  We must take extra steps to enable your programs to interoperate with non-product JNDI clients and to bind resources from MQSeries to a namespace.
• JNDI support in WAS
  The product includes a name server to provide shared access to Java components, and an implementation of the javax.naming JNDI package which supports user access to the name server through the JNDI naming interface.
• Load user-defined value set data
  Use the UDDIUserDefinedValueSet utility to load value set data into the UDDI registry, assign existing value set data to another tModel entity, and unload existing value set data. You load value set data as a step in the procedure to add a user-defined value set to the UDDI registry.
• Local transaction containment
  IBM WAS supports local transaction containment (LTC), which we can configure using local transaction extended deployment descriptors. LTC support provides certain advantages to application programmers. Use the scenarios provided, and the list of points to consider, to help we decide the best way to configure transaction support for local transactions.
• Lookup names support in deployment descriptors and thin clients
  Server application objects, such as enterprise bean (EJB) homes, are bound relative to the server root context for the server in which the application is installed. Other objects, such as resources, can also be bound to a specific server root. The names used to look up these objects must be qualified so as to select the correct server root. This topic discusses what relative and qualified names are, when they can be used, and how we can construct them.
• Mapping additional MQRFH2 header fields in service integration
  In the IBM MQ message header (MQRFH2), there are additional fields specific to the service integration bus and that allow for functions that are not used in IBM MQ. When IBM MQ transports a message from one service integration bus to another service integration bus, these fields convey information that can be used by service integration applications but is not required by IBM MQ.
• Mapping destinations to and from IBM MQ queues, topics, and destinations
  Service integration messages and IBM MQ messages both contain header fields and properties. Some of these header fields and properties contain destinations or destination properties that provide information about send-to and reply-to destinations, and about destinations in the bus forward and reverse routing paths. Because service integration and IBM MQ have different definitions for destinations, mappings are used to process the destinations and destination properties when messages are converted between service integration format and IBM MQ format.
• Mapping MQMD Report fields to JMS provider-specific properties
  JMS applications can use report messages as a form of managed request/response processing, to give remote feedback to producers on the outcome of their send operations and the fate of their messages. A JMS application can request different types of report message by setting JMS_IBM_Report_Xxxx message properties and options.
• Mapping of SDO data graphs for web services messages
  The structure of web services messages is described by the Service Data Objects (SDO) Version 1 data graphs for web services messages.
• Mapping the JMS delivery option and message reliability to and from the IBM MQ persistence value
  When converting messages between IBM MQ format and service integration format, service integration processes the message header fields and properties relating to message delivery mode, reliability, and persistence.
• Mapping the message body to and from IBM MQ format
  The IBM MQ message header (MQRFH2) and descriptor (MQMD) can contain information about the format of the IBM MQ message body. Service integration uses information contained in the MQRFH2 and MQMD when converting a message from IBM MQ format, and puts information into the QRFH2 and MQMD when converting a message to IBM MQ format.
• Mapping the message header fields and properties to and from IBM MQ format
  When service integration converts a message to IBM MQ format, it sets fields in the MQMD and the MQRFH2 based on the service integration message header fields and properties; these include JMS message header fields and properties applicable to the message. When service integration converts a message from IBM MQ format, it sets the service integration message header fields and properties from the MQMD and the MQRFH2 in the IBM MQ message.
• Mapping XML schema definitions to the SDO type system
  Each XML schema type is mapped to an SDO type. Use this mapping to help you develop code to navigate the data graphs of the messages that your program mediates.

• Password case sensitivity using a local operating system registry
  Knowing when a password is interpreted as case sensitive or not can directly affect how we use a local operating system registry. WAS exploits the mixed case password option for the Resource Access Control Facility (RACF ) and allows us to use case sensitive passwords.

• Password sensitivity using a local operating system registry
  Allowing for a larger number of password combinations benefits WebSphere Application Security. Passwords restricted to 8 characters have limits on how secure they can be. Hacking attempts often are successful with 8 character passwords. WAS expands the possible combinations beyond the 8 character password by providing the ability to additionally use a password phrase from 9 to 100 characters long. The password phrase gives you an exponentially larger number of combinations for securing any given user ID to an application.
• Publish a checked categorization tModel entity
  You publish a checked categorization tModel entity as the first step in the procedure to add a user-defined value set to the UDDI registry.
• Runtime considerations for SIP application developers
  We should consider certain product runtime behaviors when we are writing SIP applications.
• Scheduler configuration or topology
  The scheduler uses a database to persist information concerning which tasks to run and when. Errors might occur when changing the application server topology or when changing the application or server configuration. When we change the configuration or topology, carefully consider how this action affects the scheduler.
• Security considerations for web services
  When we configure Web Services Security, we should make every effort to verify that the result is not vulnerable to a wide range of attack mechanisms. There are possible security concerns that arise when we are securing web services.
• SIP industry standards compliance
  The product implementation of SIP complies with industry standards for both a SIP container and SIP applications.
• SIP proprietary header fields
  Create a SIP servlet request that includes proprietary header fields. SIP proprietary header fields enable certain SIP settings to be implemented on a per message basis. SIP settings set at the SIP container level apply to all SIP messages handled by that SIP container.
• SIP SipServletRequest and SipServletResponse classes
  The SipServletRequest and SipServletResponse classes are similar to the HttpServletRequest and HttpServletResponse classes.
• SIP SipSession and SipApplicationSession classes
  Possibly the most complex portions of the SIP Servlet 1.0 specification are the SipSession and SipApplicationSession classes.
• Terminology from the WS-Notification standards
  The terminology defined in this topic is defined by the WS-Notification specifications and is common to any vendor implementation of these specifications.
• The createQueue or createTopic method and the default messaging provider
  Use the Session.createQueue(String) method or Session.createTopic(String) method instead of using JNDI lookup to create a JMS Queue or JMS Topic with the default messaging provider.
• Topic names and use of wildcard characters in topic expressions
  Wildcard characters can be used in topic expressions to retrieve topics provided by the default messaging provider and service integration technologies.
• Transcoding a byte array into a message payload
  A mediation can transcode a byte array into a message payload without changing the meaning of the message.
• Transcoding a message payload into a byte array
  We can transcode the message payload into a byte array.
• Transcoding between message formats
  A mediation can convert a message from one format to another without changing the semantic meaning of the message. This operation is referred to as transcoding a message.

• Transport header properties best practices
  We can set the REQUEST_TRANSPORT_PROPERTIES property and RESPONSE_TRANSPORT_PROPERTIES property on a JAX-RPC client Stub, a Call instance, or a Java API for XML-Based Web services (JAX-WS) BindingProvider's RequestContext instance to enable a web services client to send or retrieve transport headers.
• Trust association interceptor support for Subject creation
  The trust association interceptor (TAI) com.ibm.wsspi.security.tai.TrustAssociationInterceptor interface supports several features that are different from the existing com.ibm.websphere.security.TrustAssociationInterceptor interface.
• UDDI registry terminology
  Some terms specific to the UDDI registry are explained. Also, the relationship between the versions of the UDDI registry, the Organization for the Advancement of Structured Information (OASIS) specification, and the WAS level are shown.
• Usage model for using ActivitySessions with HTTP sessions
  This topic describes how a Web application that runs in the WebSphere Web container can participate in an ActivitySession context.
• User-defined value set support in the UDDI registry
  We can define multiple value sets and add custom value sets to the UDDI Version 3 registry. In UDDI v2, this feature was called custom taxonomy support.
• Validation and error handling for user-defined value sets
  The UDDI registry user console performs validation while a save tModel entity request is built, that is, before the publish occurs.
• Web services messages overview
  To work with the data graph form of web services messages, we need to know the structure of the data graph, and how to develop code that can navigate the data graph.
• Web services migration best practices
  Use these web services migration best practices when migrating web services applications.
• Web services migration scenarios: JAX-RPC to JAX-WS and JAXB
  This topic explains scenarios for migrating your Java API for XML-based RPC (JAX-RPC) web services to JAX-WS and Java Architecture for XML Binding (JAXB) Web services.
• Web Services Security configuration considerations
  To secure web services for WAS, specify several different configurations. Although there is not a specific sequence in which specify these different configurations, some configurations reference other configurations.
• Web Services Security configuration considerations when using the WSS API
  To secure Web Services Security for WAS, we can specify several different configurations using the Web Services Security APIs (WSS API). The Web Services Security specification provides a flexible way to secure web services messages using XML digital signature, XML encryption, and attaching security tokens. We can enable Web Services Security by either configuring a policy set or using the Web Services Security APIs (WSS API). The implementation for WSS API has default values for which message parts are to be signed or encrypted. The default values for the WSS APIs help end users to enable Web Services Security quickly.
• WAS-specific WS-Notification terminology
  This terminology is implementation-specific, beyond the terminology defined in the WS-Notification standards, and applies to the WS-Notification implementation in WAS.
• IBM MQ functions not supported by service integration
  There are various functions available in an IBM MQ network that are not available on a service integration bus.
• IBM MQ server: Restrictions with mixed level cells and clusters
  If we are using an IBM MQ server with cells or clusters that include more than one version of WAS, we might need to be aware of the application server versions when we deploy applications that communicate with IBM MQ queues.
• WS-Notification terminology
  There is terminology that we must be aware of when working with WS-Notification. Most of this terminology is defined by the WS-Notification standards, and a few terms are defined to describe this implementation of WS-Notification for WAS.
• WS-ReliableMessaging: supported specifications and standards
  WAS provides support for two levels of the WS-ReliableMessaging specification. This gives compatibility with vendors that provide WS-ReliableMessaging support at the February 2005 level, as well as meeting the requirements of the current OASIS specification. This implementation of WS-ReliableMessaging also composes with many other web services standards.
• WS-ReliableMessaging - requirements for interaction with other implementations
  The information and configuration needed for another vendor's reliable messaging source to send messages to a WAS reliable messaging destination, or for a WAS reliable messaging source to send messages to another vendor's reliable messaging destination.
• WS-ReliableMessaging roles and goals
  Computing roles that members of our organization might perform, and how we can use WS-ReliableMessaging to help meet the goals of each role.
• WS-ReliableMessaging - terminology
  
• XML schema definition for JMS stream messages
  This is the XML schema definition for transcoding JMS stream messages to message types.