It is assumed that you have read the introduction to Internationalization with EntireX and are familiar with the various internationalization approaches.
This document provides information on all changes to internationalization behavior in previous versions of EntireX and gives hints for migration.
See also: Broker Attribute File
This version of EntireX does not support the ECS conversion approach to internationalization (see Internationalization Changes and Migration Hints.) Instead, ICU conversion must be used. Migration from ECS conversion to ICU conversion is required. This section will assist you in migrating from ECS conversion to ICU conversion by helping you to find relevant ICU converters to use as replacements for an ECS conversion codepage.
Two changes were made to internationalization in the broker kernel
ECS conversion is no longer available. ICU conversion must be used instead.
ECS-style locale strings sent by EntireX components in the format "ECS <ecs-number>", where <ecs-number> is the decimal number of an ECS codepage, are mapped inside the broker to icu converter names. See column Used as Default ECS/ICU Mapping in the Table of ICU to ECS Compatibility to determine which ECS number is mapped to which ICU converter name.
No changes were made to EntireX components regarding internationalization behavior.
The basic features of ECS and ICU conversion codepages are identical. However,
ICU provides more functionality than ECS with fallback, substitution sequences and reverse fallback definitions. See ucm format fallback, substitution sequences and reverse fallback definitions were not supported by ECS.
ECS character conversion leading to the substitution character of the ECS encoding file may lead to a printable character by ICU because of these additional code points and fallback definitions.
ECS and ICU conversion are not 100% compatible. See column Compatibility in the Table of ICU to ECS Compatibility.
There are several possible ICU converters that can replace an ECS conversion codepage. See the Table of ICU to ECS Compatibility.
ECS-style locale strings sent by EntireX components in the format "ECS <ecs-number>", where <ecs-number> is the decimal number of an ECS codepage, are mapped inside the broker to ICU converter names. However, we recommend adapting the locale string style ECS <ecs-number> sent by your EntireX components to the broker, to a style supported by ICU and the broker. See Locale String Mapping and Preparing EntireX Components for Internationalization under z/OS | UNIX | Windows.
With version 7.2.x of EntireX the mechanism for internationalization changed compared with version 7.1.x and earlier. It is no longer possible to define multiple internationalization approaches per service as was possible in version 7.1.x and earlier.
The changes that were made to internationalization in the broker kernel
prevent definition of configurations in the broker attribute file which make no sense (see 2B, 3A in the table below)
clearly give administrators the mechanisms to control the internationalization approach, because multiple definitions in the broker attribute file are no longer allowed (see 4A and 4B in the table below)
To understand the changes read the following excerpt from EntireX 7.1.x documentation:
The following table shows the broker's handling of translation and conversion for version 7.1.x and earlier:
| Attribute File Specifications | Application Use of Locale | |||
|---|---|---|---|---|
| Translation | Conversion | Neither sender nor receiver has locale string | Sender or receiver or both have locale string | |
| A | B | |||
| 1 | not specified | not specified | Data sent unchanged, message conversion is to be done by application. | Data sent unchanged, message conversion is to be done by application. |
| 2 | =Methodname | not specified | Translation is used with given Methodname. | This configuration does not make sense, data is sent unchanged. |
| 3 | not specified | =Methodname | This configuration does not make sense, data is sent unchanged. | Conversion is used with given Methodname. |
| 4 | =Methodname1 | =Methodname2 | Translation is used with given Methodname1. | Conversion is used with given Methodname2. |
The configuration as shown in row 1 in the table above is used for binary payload. No conversion or translation should take place.
The broker in this version behaves the same as in earlier versions. Nothing has changed for cases 1A and 1B. The payload is never translated or converted.
The configuration as shown in row 2 in the table above is applicable to the internationalization approaches Translation or Translation User Exit.
The behavior of the broker for this version of EntireX in case 2B is to use the defined internationalization approach. Hence, this version of the broker does not send non-translated data (different from version 7.1.x and earlier brokers). The payload is always translated. The situation in version 7.1.x and earlier brokers under configuration 2B which made no sense and caused error situations has been removed with this version and can no longer occur.
A possible locale string sent by an EntireX component is ignored by the broker of this version of EntireX and no longer has an influence whether the payload is translated or not.
The configuration as shown in row 3 in the table above is applicable to ICU Conversion and SAGTRPC User Exit as the internationalization approach.
The behavior of the broker for this version of EntireX in case 3A is also to use the defined internationalization approach and not to send unconverted data (as did version 7.1.x and earlier brokers). The payload is always converted. The situation in version 7.1.x and earlier brokers under configuration 3A which made no sense and caused error situations has been removed and can no longer occur.
Missing locale strings not sent by an EntireX component are mapped by the broker's locale string default mechanism and no longer have an influence whether the payload is converted or not.
The configuration as shown in row 4 in the table above does not clearly define the internationalization approach to use. The alternating use of translation and conversion depending on the presence of locale strings (as did version 7.1.x and earlier brokers) is no longer supported.
The behavior of the broker for this version of EntireX in case 4A is to use conversion (that is, the same as 4B, assuming conversion is the more exact approach) instead of reverting to translation (as did version 7.1.x and earlier brokers). The payload is always converted with the internationalization approach defined for conversion, and hence any translation approach is ignored. A warning is printed in the broker trace log. Thus it can no longer be unclear which internationalization approach is used by the broker.
Missing locale strings not sent by an EntireX component are mapped by the broker's locale string default mechanism and no longer have any influence whether the payload is converted or translated.
| Attribute File Specifications | Internationalization approach used | |
|---|---|---|
| Translation | Conversion | |
| not specified | not specified | Data sent unchanged, message conversion is to be done by application. |
| =Methodname | not specified | Translation is used with given Methodname. |
| not specified | =Methodname | Conversion is used with given Methodname. |
| =Methodname1 | =Methodname2 | Conversion is used with given Methodname2. |
The table above and the notes below show the broker's handling of translation and conversion for this version:
The chosen internationalization approach is fully described by the broker's attribute definition for the service or topic.
The internationalization approach used is fully under the control of the broker administrator.
The internationalization approach is fixed per service or topic and no longer alters depending on whether an application sends a locale string or not.
Binary payload is supported.
Conversion overrides Translation.
Because the broker's algorithm for choosing the internationalization approach no longer depends on the presence of locale strings, it is possible to send locale strings to the broker kernel in advance by default, even if the internationalization approach is unknown.
Providing suitable locale strings by default is
possible in Java environments under all platforms. As long as EntireX Java components use the default encoding of the underlying Java virtual machine (and communicate with a broker of version 7.2.x and above) nothing has to be considered. This version of EntireX sends the encoding of the JVM as the locale string in advance if communicating with a broker of version 7.2.x and above (see also Note, below).
possible in Windows environments. As long as the EntireX component uses the default Windows ANSI codepage (and communicates with a broker of version 7.2.x and above) nothing has to be considered. This version of EntireX sends the default Windows ANSI codepage as the locale string in advance if communicating with a broker of version 7.2.x and above (see also Note, below).
not possible from any other platform and environment such as UNIX, z/OS, i5/OS etc. No locale strings are sent in advance by default from these platforms even if communicating with a broker of version 7.2.x and above. Preparation and configuration of locale strings depends on the EntireX component used and has to be done manually, see Preparing EntireX Components for Internationalization under z/OS | UNIX | Windows. In situations where all mainframe platforms use the same EBCDIC codepage, the broker's locale string default mechanism makes it easy to assign the correct codepage to all mainframe components - configuration can be done in broker only, without having to touch the EntireX Components.
not possible if communicating with a broker of version 7.1.x and earlier for compatibility reasons. No locale strings are sent in advance by default when communicating with a broker of version 7.1.x and earlier. There are no other possibilities to provide locale strings manually, see Preparing EntireX Components for Internationalization under z/OS | UNIX | Windows.
Because locale strings are unnecessary for Translation and Translation User Exit, this version of the broker simply ignores them if the internationalization approach is Translation or Translation User Exit.
In many situations (Java and Windows environments) a suitable locale string is already present and no effort is needed to configure or provide locale strings in EntireX components.
If the default locale string is not suitable, most EntireX components provide a mechanism to override the default locale string if the default does not match.
In z/OS, UNIX, i5/OS etc. environments, manual configuration or preparation of EntireX components or broker is needed because no locale strings are sent by default.
EntireX components no longer have to know the internationalization approach. It is easier to change the internationalization approach in the broker and more under the administrator's control.
Note:
Providing locale strings by
default additionally depends on using Broker API Version 8. In practice this
additional restriction has to be considered for native ACI programming (C,
Broker ActiveX Control) only for the following reasons:
The object-oriented design of the EntireX Java ACI has no API version. The API version used to communicate with the broker is negotiated internally by the Java ACI and broker kernel and not visible to users.
Most other EntireX components (RPC components) negotiate the API version used in a pre-dialog before the real communication starts.
All negotiation processes force the newest API version possible to be used. Thus if communicating with a broker of version 7.3.x, API version 9 is chosen, which is the broker's highest API version.
