In this section: |
Every effort has been made to ensure that migrating to iSM 6.0.1 is a seamless process. However, there are some changes that must be made, which are impossible to avoid and this section highlights many of them.
Many iSM components now strictly conform to newer public standards, and this can result in unexpected behavior throughout the system. Unless an application has been coded to specifically take advantage of, or workaround earlier standards adherence, most applications will function the same as in earlier iSM releases.
Tools are available from iWay Software to assist in migrations from earlier server releases (for example, 5.5, 5.6) and can be requested from iWay Product management. The tools help to identify areas of concern in existing applications and in upgrading iFL expressions to the stricter standards of 6.0.1. These tools will continue to be upgraded; contact Information Builders Customer Support for the current latest tool set.
Several areas of concern to applications that are being transferred to the 6.0.1 series of servers are discussed in FAQs that can be accessed from the What's New information in the iWay Service Manager Administration Console.
A new Compatibility section is available in the General Settings section of the iWay Service Manager Administration Console. The settings offered here can assist in ensuring that iSM 6.0.1 remains compatible with earlier releases.
Prior servers performed special processing for EDA-formatted XML documents. This special processing is rarely used, and complicates some other areas of the server processing path. By default, iSM 6.0.1 no longer performs this special processing. To reinstate the special EDA processing, set the Compatibility property to true.
iWay Service Manager parses XML documents in compliance with XML 1.0, as specified by the XML RFC. Earlier releases supported a mode of XML parsing that accounted for attempts to "pretty print" documents, and condensed white space. Some services, such as XML digital signature normalization require that parsing be strictly compliant with "mixed mode" specifications. To accommodate this, each channel can be set to preserve or condense mode in iSM 6.0.1. Condense mode reproduces the intent of the parsing systems that were used in earlier releases. Preserve mode, in compliance with the XML RFC, is now set by default. To accommodate "mixed mode" specifications, new methods have also been added to the XML document APIs. Existing API methods have been mapped such that prior behavior can be expected in most instances.
A new Compatibility extension (iwxcompat) is provided with iSM 6.0.1. This extension contains older components (for example, XDHotScreenAgent and XDJythonAgent) that are no longer distributed as an integral part of the server. The Compatibility extension (iwxcompat) must be installed in the etc/manager/extensions directory.
The introduction of providers in iSM 6.0.1 adds many conveniences and improvements to server handling of documents. In earlier releases, services such as key stores were configured directly in the components that used these objects. However, as more server objects begin to take advantage of providers, runtime configuration must change to:
In most cases the earlier objects remain in place, unchanged, so that unless you need to take advantage of provider services the configuration of the server will not change.
Previous releases of iSM supported the XPATH() function, which implemented a subset of the formal XPATH specification (modified to better fit with the iWay requirements). Generally this followed the RFC (http://www.w3.org/TR/1999/REC-xpath-19991116, subsection 2.5, Abbreviated Syntax). As of iSM 6.0, the XPATH() function implements the complete XPATH namespaces in compliance with XML 1.0 as specified in the XML RFC. Strict adherence to the XPATH specification may introduce some incompatibilities in function use. This is especially true in XPATH() expressions that included namespaces. To help avoid the need to make changes in existing application logic, the new function _IWXPATH() is introduced to implement the original iWay XPATH() implementation. Please note that the _IWXPATH() function is available in iSM 5.6 as well, where it is identical to the XPATH() implementation.
An additional function, _xpath1(), is available but is never mapped through the compatibility settings. This function is the new XPATH 1.0 standard functionality. iWay recommends that users review applications for use of XPATH functions, and ensure that XPATH is properly used, rather than relying upon the compatibility settings. Users should pay particular attention to the use of documents with no namespace specification and documents that use a default namespace specification.
In previous releases, the transaction log was configured using the iWay Service Manager Administration Console. This log was a serial flat binary file, which could eventually fill a hard disk. In iSM 5.5, the Activity Facility was introduced that offered the option to select from several types of log writes, including writing to a relational data base. In iSM 6.0.1, the main console log is no longer supported. An Activity Facility driver is available to emulate the previously supported log file structure.
User-defined iWay Functional Language (iFL) functions should continue to function as in prior releases. However, these functions must be upgraded to the iSM 6.0.1 specification. For more information, see the iWay Service Manager Programmer's Guide.
It is the responsibility of the developers of the user-defined iFL functions to thoroughly test their functionality when migrating to iSM 6.0.1. The changes to the functions are generally mechanical.
| iWay Software |