Berücksichtigen Sie die Probleme, die bei der Entwicklung benutzerdefinierter Erweiterungen in der Programmiersprache C in Zusammenhang mit der Zeichenfolgebearbeitung stehen.
Wenn Sie benutzerdefinierte Erweiterungen in Java™ entwickeln, können Sie die Java-Standardmethoden für die Zeichenfolgebearbeitung verwenden.
Damit ein Broker Nachrichten in allen Sprachen gleichzeitig behandeln kann, erfolgt die Textverarbeitung im Broker in UCS-2-Unicode. UCS-2-Unicode-Zeichenfolgen werden auch zwischen den benutzerdefinierten Erweiterungs-APIs von Java und der Programmiersprache C verwendet, um Zeichendaten zu übergeben und zurückzugeben. In XML-Konfigurationsnachrichten werden Attribute unabhängig vom Datentyp in Form von Zeichenfolgen empfangen. Wenn es sich bei dem tatsächlichen Datentyp eines Attributs nicht um eine Zeichenfolge handelt, muss die Funktion cniSetAttribute die notwendige Überprüfung und Konvertierung ausführen, bevor der Attributwert gespeichert wird. Das gleiche gilt, wenn ein Attributwert über die Funktion cniGetAttribute2 abgerufen wird; auch in diesem Fall muss erst eine Konvertierung in eine UCS-2-Unicode-Zeichenfolge erfolgen, bevor das Ergebnis zurückgegeben wird.
CciChar definiert ein 16-Bit-Zeichen in UCS-2-Unicode-Darstellung. Bei CciChar* handelt es sich um eine Folge von Zeichen, die durch ein CciChar mit dem Wert 0 beendet wird. Standardmäßig wird ein CciChar durch den Typ wchar_t dargestellt. Auf einigen Plattformen gibt es allerdings keine komfortable Möglichkeit, UCS-2-Konstanten im Quellcode darzustellen, in der Regel aufgrund einer 4-Byte-wchar_t- oder EBCDIC-Darstellung. Unter Solaris wird eine Quellcodekonstante wie beispielsweise L"ABC" auf 12 Bytes erweitert.
Aus diesem Grund stehen in WebSphere Nachrichtenbroker die Dienstprogrammfunktionen cciMbsToUcs und cciUcsToMbs zur Verfügung. Diese Funktionen stellen bei Bedarf die Portierbarkeit Ihrer benutzerdefinierten Knoten sicher.