This chapter is from the book
This chapter is from the book
This chapter is from the book
Deploying Adapters
Adapter deployment can be a tedious task, depending on the complexity of the integration scenarios and the integration platform. Specific challenges are involved in deploying internationalized adapters and deploying adapters on multiple platforms. Adapters are normally developed on a platform more suitable to development activities. Most adapter development is done in a Windows NT environment. If Java is the programming language, deploying the adapters on different platforms requires extensive testing. Not all platforms may support the same JDK or support all the features of J2EE specifications. This section identifies the critical tasks before and during adapter deployment.
One of the features frequently requested by adapter developers is the support for deploying adapters in different stages. A very real challenge of any integration solution deployment project is the simultaneous deployment of many interrelated components. Consider an integration scenario that involves 10 different applications hosted on different platforms in two different countries. Deploying adapters for all 10 applications at the same time is not an easy task. Quite often, a sequential deployment strategy is used to install the adapters. However, it is not a good idea to have individual adapters working in a production environment until all other adapters necessary are also installed and potentially tested.
It is also important that the integration platform on which adapters are installed is capable of recognizing and managing the adapters in different states. Adapters can exist in different states—including installed, tested, configured, deployed, and so on. Alternately, adapters that are already in the deployed state may need to be stopped for upgrades. Many times, deployment management tools are not sufficiently sophisticated. Hence, project managers need to fully understand the implication of installing adapters in stages, and define a schedule to complete the deployment successfully.
Multiplatform Deployment Guidelines
One of the benefits of programming in Java is the multiplatform support it generates without specific porting of the code base. With adapters (especially JCA resource adapters), the definition of multiplatform support includes J2EE-compliant application servers. Although the J2EE specifications are comprehensive, application vendors have some flexibility in how the implement the specifications. Some vendors also add additional functionality and support for their other products. For example, BEA WebLogic's application server also includes the Tuxedo transaction engine as an option. IBM's WebSphere application server includes MQSeries and gateways to IBM mainframe platform and environments such as CICS.
In the case of JCA support in application servers, vendors have the necessary flexibility to implement connection pooling and other JCA services using proprietary designs. Hence, although the connection-pooling service interfaces are guaranteed across application servers, the actual implementation will be different. Some will have more additional features than others. These differences result in different deployment management and configurations.
Needless to say, the application server will have bugs just like any other software. Thus, it is critical to test JCA-compliant adapters on all application servers it is expected to support. Although it is the same JCA adapter, it may work in the J2EE reference implementation, but may not work with other application servers. J2EE compliance, as defined by SUN, does not require application server vendors to support all specifications of J2EE. This is another reason for adapter developers to check if the J2EE-compliant application server also supports JCA specifications.
The more committed adapter vendors try to get the products tested and certified on different operating systems and hardware configurations. JCA adapter vendors should do the same, and get the resource adapters certified on different application servers whenever possible. To summarize, the testing and deployment guidelines for JCA resource adapters are as follows:
Test the JCA resource adapter with the reference implementation for J2EE 1.3.
Test the JCA resource adapter with all other application servers used in the production environment.
Test the resource adapter with the different operating systems supported by the J2EE application servers in the production environment.
Deploy the resource adapter on one type of application server at a time. This helps to eliminate application server-specific problems more quickly. Application servers may have different configurations, which could result in varying results.
Group the resource adapter deployment by operating system. If you are expected to deploy three resource adapters on a Windows NT environment and two resource adapters on Linux, it is better to complete all the Windows NT or Linux deployment first. Chances are, if one resource adapter encounters a problem with the operating system or a problem with the application server running in the operating system, other adapters will face the same issues.
Deploying Internationalized Adapters
Not all adapters are internationalized or ready to support different languages and locales. But there are two parts to ensure that adapters are ready for international deployment. The first part is internationalization, which involves additional work and discipline from adapter developers. Developers need to ensure the use of appropriate mechanisms such as resource bundles to store literal strings, and so on. The second part is localization, which involves the creation of resource bundles in different languages.
Apart from the visual support for languages other than English, there is the issue of supporting double byte data and different input methods for languages. Several products enhance the native Java capabilities for internationalization by providing data input mechanisms for many different languages. UNICODE is the widely accepted standard for Double Byte Character Support (DBCS), but other specific standards (especially for Japanese and Chinese language support) may be more prevalent in different parts of the world.
Regardless of the level of DBCS support and the different input methods supported by the adapters, it is important to understand that testing and deploying adapters in different languages involves different versions of operating systems and perhaps different versions of business applications as well. Hence, QA of international versions of adapters is not simply restricted to testing the adapter using standard test cases. It involves a completely different test environment, including international versions operating systems (such as Chinese Windows), hardware that is more popular in different parts of the world, different versions of applications, and test data in the language matching the locale.
Project managers who plan to deploy adapters in a global environment using internationalized adapters should take into account the additional efforts required to test and support the adapters on hardware and operating systems that are more popular and relevant to the local environments. Support for Java is not equal on all platforms. Hardware and operating system vendors may be supporting various different versions of JDK, and it is important to understand those differences before the adapter development project starts.