x

Configuration of central resources has been moved to the Providers section of the iWay Service Manager Administration Console. All new and updated components obtain central services through these providers. Providers enable the centralization of resource definitions, avoiding the need to configure each component individually, and allow for improvements in managing resources shared across channels. These providers include:

• Database Connection Providers, which control the allocation of connections to databases. Use of this provider reduces the number of open connections at any point, and makes it possible for multiple users within a single process flow to share a connection in order to improve transactionality.
• LDAP Connection Providers, which offer multiple paths to individual directories. This increases the functional use of LDAP within the server and improves performance.
• SSL Providers, which manage SSL connections, avoiding the need to reestablish sessions with a single endpoint. These providers handle all negotiations with the client. By selecting the desired provider for the channel, the degree of security can be managed on a common basis.
• Key Store Management Providers, which centralize key store and trust store control to reduce the need to define this information on a channel-by-channel basis.
• Authentication Providers, which offer user identification and password validation to components such as new HTTP and the new Telnet Management Channel. Authentication can be performed through various resources such as an SQL database, LDAP, a local properties file, or through Java-standard JAAS. An authorized and authenticated user can hold one or more roles, which can be used to control that user within a process flow.

x

Message flows and the server itself can be configured to be secure. A secure server uses signed configurations, preventing changes other than through the use of authorized tools by authorized personnel.

The server can generate and check digital signatures and handles secure S/MIME attachments.

x

A new HTTP service offers HTTP 1.1 compliance along with full support for persistent connections. The protocol is designed to be non-blocking and offers a significant reduction in the use of system services, especially during high load applications.

All HTTP verbs are supported (based on configuration) with any verb able to be passed through the channel for execution within a process flow. This includes GET, POST, DELETE, PUT, OPTIONS, TRACE, and so on.

Secure Sockets Layer (SSL) support is available through the use of a centralized SSL provider.

x

A new AS2 protocol, based on the new HTTP facilities, is available. This feature fully implements the latest AS2 specifications, and additionally allows for deferral of AS2 Message Disposition Notification (MDN) until the message is handled by a process flow.

x

To improve the management of iWay Service Manager instances running as a service or remotely, an optional channel can be configured to handle Telnet clients. Security can be configured including SSL using lists and an authentication provider. Most control commands previously available only through the command shell on a local machine, are now available via the configured remote Telnet session. Operations through the Telnet Management Console are overseen by the server's security facilities.

x

When using multiple instances (nodes) of a single iWay Adapter (for example, SAP or IMS) within a process flow, the iWay Adapters can now be pooled at the target level. This enables a single commit/rollback to be sent to the target at the end of the process flow. As a result, transactionality within the process flow is improved and simplified.

x

Many improvements have been made to the execution of process flows, which result in reduced memory overhead and faster handing. Specific changes have been made to fully support passing of status from a sub-flow to the parent flow. Additionally, a CATCH service enables you to capture error situations for additional handling by the process flow. CATCH is significant when developing AS2-based process flows that defer sending of an MDN. This allows the server to always send the MDN even in the even of a failure during the process flow.

x

iWay Service Manager conforms with standards strongly, including offering full XPATH access to documents and XSLT XML to XML transformations. Traces from third-party components used by applications (through Log4J and Java Logging), even when not directly supported by iSM, can be captured and included in the standard iSM trace logs.

x

iWay Service Manager provides new and extended iWay Functional Language (iFL) facilities. For example, the _urlparse() function now accepts additional parameters to extract a keyword from within the query component. New functions are available to examine the security role token associated with an authenticated principal, enabling routing on a security level to be performed in a process flow.

x

A new stateful and persistent special register is available, which is called a metric. It is used to maintain statistics at the server or channel (protocol) level. Examples include the maximum value of transactions received or the number of errors of a certain type. iWay Functional Language (iFL) is used to set and update metrics in the familiar XDSREGAgent. Metrics can be locked for simultaneous update and reference. The new iFL function _lock() can reference one or more metrics under the appropriate lock to prevent obtaining inconsistent values from multiple metrics.

x

A new setting in the channel (listener) configuration allows the inclusion of white space in the parsed document. Earlier editions of iSM eliminated what appeared to be extraneous white space. XML Parsing is now compliant to current XML standards. This includes full name space support.

x

Preparsers are channel inlet exits that perform initial work on a message. In prior releases, because it was assumed that the task of a preparser is to prepare the message for XML parsing, preparsers were not called on channels configured for flat (non-XML) documents. In response to many requests, preparsers now run on flat input messages. Naturally, the selection of the appropriate preparser for the particular message remains a configuration task.

The most commonly expected use case for running preparsers on flat documents is the use of splitting preparsers that divide a message into sections for processing in a single transaction.

x

The File listener has been upgraded to offer continuous read capabilities. In prior releases, the File listener read files from a specified input directory in batches, waited until the list of files had been exhausted by the configured channels, and then went back to the disk for another batch. In iSM 6.0.1, file access is not directly tied to the exhaustion of the input list. Therefore, a slower channel will not prevent access to files by faster channels.

IA new setting on the File listener enables you to switch the batching behavior that was used in earlier releases, if required. In iSM 6.0.1, the default is configured for continuous read.