IIIM - Distributed Input Method Service Architecture

	Internet/Intranet Input Method Architecture For Java, Network Computer and all other platforms.
	A White Paper
	Hideki Hiura Sun Microsystems, Inc.
	Revision SDK2 1.0
	Last updated: 2/12/'99

Abstract

This document describes the high level architecture of Internet/Intranet Input Method(IIIM), with its advantages of:

platform neutrality
window system independence
implementation language independence
a multilingual distributed IM infrastructure.

IIIM is designed to interface with the Internet, intranet, Network Computer, and Java.

IIIM defines a set of interfaces, conventions, and protocols. These components:

IIIM Protocol(IIIMP)
IIIM ServerFramework(IIIMSF)
IIIM Client Framework(IIIMCF).

are known as IIIMFramework(IIIMF).

The IIIM Framework enables flexible, scalable and efficient Input Method Services (IMS) that harmonize with existing platform input methods, and extend the IMS beyond the platform boundary.

Overview

The IIIM provides a distributed input method (IM) that integrates a variety of IM engines and interfaces on multiple platforms.

Most mature software platforms, such as UNIX, Windows, Macintosh, and Java, provide a pair of single platform specific IM interfaces:

Input Method Application Programming Interface - IMAPI
Input Method Service Provider Interface - IMSPI

These interfaces are based on platform specific architecture.

IMAPI provides the application programmer with an interface to write IM enabled applications, and IMSPI allows IM engine providers to plug-in their IM service module as a part of system services.

IMAPI and IMSPI heavily reflect the platform architecture of each platform installation, which tends to make programming models differ between platforms. Consequently, IM providers who wish to support multiple platforms must implement different input methods for each of the different interfaces and architectures. As IM software porting is difficult to provide between incompatible platforms, IM providers generally concentrate on development for one platform only. As a result, one platform is enriched with variety of attractive input methods and the rest have only limited input methods available.

Even multiple platforms in a networked environment do not interoperate, because of the platform dependent evolution of IM products. Users on IM pure platforms cannot use input methods on the IM rich platforms even when they are connected in the same room.

The platform specific evolution of IMAPI and IMSPI does not necessarily mean that IMAPI, IMSPI, and input method itself, should always be architected to be platform dependent.

A possible solution to these limitations would be to standardize IMAPI and IMSPI among platforms to encourage platform venders, application writers, and IM service providers to migrate to a new interface. However, this is unlikely as there is such an array of well developed IM on the market already.

A key requirement for distributed IM service is to supply virtually all the input methods available on existing platforms. Ideally the existing IM would be enabled without extensive modifications. Without this it would be unrealistic to expect all the IM service providers to automatically port their IM engines onto new IMSPI.

The IIIM approach does not define new SPIs, but rather federates the different existing IMAPI, IMSPI, and IM engines.

IIIM defines three key concepts;

IIIM Protocol - flexible but efficient protocol, highly optimized for IM support, harnesses the other two concepts.
IIIM Client Framework - interfaces to widely diverse IMSPIs on different platforms.
IIIM Server Framework - interfaces to the diverse IMAPI on the multiple platforms and to IM service providers proprietary IM engine interfaces.

The design goals

Platform Neutralness

An important design goal of IIIM is Platform neutralness. In the context of IIIM, Java is yet another platform which defines another new IMSPI and IMAPI. To leverage existing IMSPIs, IMAPIs and IM engines on differing platforms, it is essential to absorb the differences as the components directly interface to each of the IMSPIs, IMAPIs and IM engines, and their communication infrastructure.

IIIM defines server and client frameworks and conventions, that are adaptable with Java and all platforms which have IMSPI, IMAPI, and IM engines.

Distributed IM infrastructure

IIIM, as a distributed IM infrastructure, defines a new protocol which is highly optimized for IM service. An initial design option for IIIM was to limit the target platform to Java, using Java RMI (remote method invocation) and JNI (Java Native Interface). However, introducing heavy dependency on the Java platform was contrary to our principal of providing an integrated IM solution for all existing platforms.

By writing another agent to interface the other side of API, such as a protocol conversion agent, the IMEs on Windows can supply the IM services to an application running on UNIX and Macintosh.

There are also two issues concerning efficiency; foot print and run time performance.

Efficiency

Input method can be a frequently and heavily used application for users who rely on lanugage input to the computer. IM performance implication directly affects the users' efficient use of the computer.

The first client implementation of IIIM was Java. At the time there was a suggestion to use Java's RMI (Remote Method Invocation) rather than inventing a new protocol from the beginning.

Efficiency is the primary reason that IIIM uses its own highly optimized protocol designed for Input Method, rather than easy-to-use generic network framework, such as Java's RMI or OMG's CORBA. The performance of this network based IM has been well measured and its implications have been recognized by several studies on several X Input Method Protocols. It has been one of the most heavily investigated IM protocols by researchers for years. Based on these studies and careful studies of Java RMI performance for distributed IM use, the IIIM design team decided to invent a new highly optimized protocol which can maximize the balance of performance and extensibility.

Scalability

The IIIM architecture supports a diverse level load dispersion of input method load. The IIIM cascade mechanism enables Language Engine layer dispersion. This is important because the Language Engine layer often becomes a bottle neck because its typically heavily CPU and I/O bound. Allowing dispersion on Language Engine layer throughout the network guarantees scalability in most cases.

The IIIM PCE, with a downloadable syntax rule, enables practical client/server load dispersion for languages which typically need multi-level composition/conversion operation, such as Japanese and Korean. The IIIM server can delegate a simple preprocessing operation to each client by downloading a syntax rule to PCE in IIIM Client Framework. This preprocessing task itself is a trivial operation making the load increase on the client ignorable. As a result the number of interactions between the server and the client dramatically decreases, guaranteeing higher scalability. The further load dispersion can be done through the Collaborative Lightweight Engine downloading mechanism. The Language Engine can delegate any part of IM functionalities to the client by downloading its objects as its frontend.

Rather than using costly generic network frameworks, such as Java's RMI or OMG's CORBA, the IIIM infrastructure uses a specially designed and optimized protocol. This ensures scalability among existing multilingual network capable input methods when network bandwidth is a bottleneck.

Extensibility

For the IM service providers, it is essential for an IM framework to provide features to differentiate their products from others. Some examples are:

Look and Feel
Functionality
Cooperation with special applications

The GUI object downloading mechanism enables "look and feel" customization through the remote Language Engine.

The Lightweight Engine downloading mechanism and IIIM protocol extension mechanism enables the engine specific enhancement of IM functionality.

Cooperation with special applications depend on the platform IMSPI capability.

Security

The security model for IIIM technology is built around each platforms security mechanism. For example, IIIMJCF on Java2 fully utilizes Java2's security policy mechanism. The objects downloaded from the IIIM Server fully comply with the Java sandbox security management model.

Agent/Bridge/Cascade Model

One of the goals of IIIM infrastructure is to leverage the existing IM engines that are available on different platforms. IM engine technology, although complex, is a mature technology that has produced many viable intelligent engines on several platforms. It would be unrealistic to expect IM service providers to port their IM engines onto a new IMSPI each time one is defined. Clearly, utilizing the existing IM engines, without requiring extensive modifications, would provide an ideal solution.

The IIIM Bridge is a pseudo IM client module that uses existing platform specific proprietary IMSPIs to leverage existing platform engines. This is done without requiring extensive modifications to the existing engines:

The IIIM bridge uses IIIM Protocol to export IM services (given as a IM client) outside of the platform box.
An IIIM server, acting as an IIIM agent, takes the exported IM services through IIIM cascade adapter. This occurs as if the agent is talking directly to the Language Engines on the platform where the IIIM bridge is running.
The IIIM agent federates multiple bridges and other IIIM servers including the IIIM server acting as yet another IIIM agent. These federated IM servers appear as virtual single server to IIIM client.

Another goal of IIIM infrastructure is to allow the client to be as thin as possible. With IIIM server as an agent for widely distributed IM federation, IIIM client can be free from complex resource management.

Multilingual/Multiscript Support.

IIIM uses UTF16 with the source identifier to identify the language as a primitive of text. Among several Unicode/ISO/IEC 10646 representations, UTF16 takes smallest footprint to support a full Unicode repertoire. UCS2 was not considered because it only covers a subset of Unicode repertoire. Alternatively, while UCS4 covers full Unicode repertoire and makes character handling easier, has a large footprint which does not comply with IIIM's maximum scalability requirement. Legacy Encodings are another option that was considered for each locale with a legacy extension mechanism, such as ISO2022 or Compound Text. This approach can be useful for maintaining backward compatibility with systems that assume codesets are octet-oriented and upwardly compatible with ASCII.

To avoid the negative heritage of all these models, the entire IIIM Framework was built from scratch. IIIMText for IIIM uses source identifier as a part of protocol primitive and primitive data structure of IIIM Framework. This elevates UTF16 based text from multiscript support to multilingual support.

Component Overview

IIIM Framework

The entire distributed IM framework (IIIM Framework (IIIMF)), consists of IIIM Server Framework (IIIMSF), IIIM Client Framework (IIIMCF), and IIIM Protocol (IIIMP). The framework itself and the protocol are designed to be independent of the operating system that the client or server is running on. IIIMF offers IM services across the platform boundary via platform independent distributed IM protocol (IIIMP). This adaptation to platform specific capability is designed to be externalized and to be pluggable.

IIIM Server Framework - Platform Neutral IIIM Server

IIIM Server Framework(IIIMSF) consists of:

core IM management framework,
pluggable protocol drivers
pluggable server rendering modules
pluggable Language Engine interfaces
several Language Engine skeletons.

The reference implementation in C++ defines the platform independent layer and platform dependent support libraries as distinct and separate. This makes the framework portable between different platforms. The IIIMSF uses UTF16 from the top of the protocol driver to the bottom of language interfaces. It also provides its own characterset converters for Language Engines plugged into the Language Engine interface (which may use other encodings internally).

The following diagram illustrates how each pluggable module interoperates inside IIIMSF.

Due to the lack of the lookup-choice protocol in the X11R6 XIM protocol specification, some extensions are required to support the IIIMP bridge for X11R6 XIM protocol. A way around this limitation is X11R5 XIMP protocol, which defines the lookup choice protocol and a standard extension, that would be less problematic than X11R6 XIM protocol. However, our approach at Solaris was to merge the IIIMP bridge and IIIMP Agent as they already support major Language Engines on UNIX and we can get almost the same coverage with more stability.

The IIIMP driver, under the Language Engine Interface, enables the functions as the IIIMP agent (with the multi-lingual, multi-language engine capability it already has).

IIIM Client Framework

The IIIM Client Framework (IIIMCF) consists of:

IIIM Protocol driver
IIIM Event/Object Manager
Light Weight Engine
Primary Composition Engine
Client Rendering modules.

The IIIM Client Framework enables client-server collaborative, distributed IM, which works either with or without a network and is dynamically scalable.

IIIM Java Client Framework

The IIIM Java Client Framework (IIIMCF) is a Java2 adaptation to IIIMCF, implementing full IIIM Client Framework as 100% pure Java Input Method. The Java2 based platform can take advantage of full IIIM framework capability.

IIIM X Client Framework

The IIIM X Client Framework (IIIMXCF) is an X Window System adoption to IIIMCF. IIIMXCF is implemented as an extension to Xlib, supporting IIIM Protocol as an alternative IM Protocol to XIM Protocol.

IIIM Protocol

IIIM Protocol (IIIMP) is a protocol designed from scratch to support platform independent distributed IM infrastructure. IIIMP is a key component of IIIM Framework. IIIMP is an extensible, platform independent, Window system independent, and language independent IM protocol. It is specially designed for distributed IM service on a heterogeneous and highly divers network environment. This protocol is also designed to be extremely efficient for use on low bandwidth Internet and low bandwidth areas of Intranet (i.e. PPP connection over modem).

IIIM Server Framework Component

Resource Manager/Session Manager

The Resource Manager/Session Manager is a core part of IIIM Server. It manages:

a session which is associated with each input context
resources associated with each input context and IM

Protocol Driver Manager

The Protocol Driver Manager provides a framework to plug-in an IM protocol driver. This provides a transparent mechanism for an Input Method Engine to access IM protocols. IIIM framework's default configuration supports (but is not limited to) the following three major IM protocol drivers:

IIIM protocol driver for server
X11R5 XIM protocol driver
X11R6 XIM protocol driver

Visual Feedback Rendering Objects

During the input composition operation, some languages do and others do not, require visual user feedback for intermediate composed string. IIIM Framework provides two options:

client rendering
server rendering

The X Window System provides other processes to render images on other windows. Traditionally, an IM server renders an intermediate visual feedback directly or indirectly onto the n client window. This is called server rendering.

Other platforms, which do not allow this type of remote window rendering, generally use an IM server which asks the client to render intermediate visual feedback indirectly. IIIM Framework supports the following three methods for rendering:

X rendering object
Java rendering object
Client rendering object

Per locale VM separator

Platform neutral converters

IIIM engine receptor SPI

Cascade adapter

Direct Cascade adapter

XSunIM Adapter

XSunIM

Platform specific libraries

IIIM Client Framework Component

IIIM Client Framework enables an IIIM client to access the input methods resident on the IIIM server host. This is done via IIIM protocol (IIIMP). IIIM Client Framework is:

independent of the operating system on which the client or the server is running
can be implemented on any platform, in any programing language, with any window system

There have been several studies done on the implementation of IIIM Client Framework in a variety of programing languages on different platforms:

In Java on Java2 and JavaOS platform
In C on X Window System
In elisp on Emacs
In C++ on IIIM Server Cascade adapter

The platform and programming language support network connection allow the implementation of the core part of IIIM client framework.

Platform IMSPI Adapter

The Platform IMSPI Adapter layer interfaces with the platform specific IMSPI, distinguishing it from rest of the IIIM Client components. This layer absorbs the differences of IMSPI models among platforms, and provides a consistent view to the rest of the IIIM Client components.

Dynamic Lightweight Engine Switching/Stacking with IIIM Event/Object Manager

IIIMCF defines the IIIM Event/Object Manager to control event flow. All incoming and outgoing events from IIIMCF components are managed by IIIM Event/Object Manager. IIIM Event/Object Manager supports dynamic configuration including Dynamic lightweight engine switching/stacking through dynamically loadable manager rules. This mechanism allows IM modules to be configured as a stack of:

Light-Weight Engine modules
IIIMP Protocol Modules

This allows some simple composition to be done locally, and some expensive operations to be done remotely. For example, we can configure the Korean hangle composition performed locally and hangle-hanja conversion performed remotely via IIIMP.

Primary Composition Engine and Downloadable Syntax Rules

Primary Composition Engine (PCE) is a special built-in state-machine based Language Engine which handles the simple input composition operation. By default, the IIIM Event/Object Manager rule and all incoming events from the Platform IMSPI adapter is dispatched to PCE first.

PCE supports dynamic configuration of its event binding through a dynamically loadable syntax rule, com.sun.iiim.pce1.s1. The expression power of this rule can cover languages from simple European key composition to Korean hangul and Japanese Romaji-kana conversion. This includes pre-edit feedback and status feedback.

Downloadable LightWeight Engine

Light Weight Engine (LWE) is a Input Method Engine that runs on the IIIM client framework. The architecture of LWE is determined by the platform on which IIIMCF is implemented. LWE for IIIMJCF must be 100% pure Java and comply with all Java Applet restrictions. On the client side, LWE is completely resident at run time, and can be loaded from the IIIM server on demand. LWE provides collaborative IM support with the IIIM server; however, LWE can be developed as a purely stand-alone engine.

Downloadable GUI Objects

The IM user interface can be categorized into the following four regions:

Pre-edit region

Status region

Lookup choice region

Auxiliary region

IIIMCF provides default GUI modules for all four regions; however, any of GUI modules can be dynamically downloaded from IIIM Server. The GUI, in particular, is an area where the IM providers can effectively show their originality. GUI object downloading may often be triggered by the Language Engine Module when a Language Engine is selected.

Disconnected Mode

IIIMCF is capable of providing Input Method support in

fully server based operation mode
server/client collaborative mode
disconnected mode.
These are controlled by the IIIM Event/Object Manager's managing rule.
IIIMCF uses:

a syntax rule driven Primary Composition Engine (PCE)
Light Weight Engine (LWE)
This provides a capability to switch and stack between PCE, LWE and the server side Language Engines that are dynamically specified in the IIIM Event/Object Manager rule. The disconnected mode is the pseudo name of specific configuration rule sets in the manager's rules. These only use PCE and/or non-collaborative LWEs, which do not require any IIIM server. Disconnected mode can be defined as a sub-mode of the fully server based operation mode or server/client collaborative mode, which is only activated when network is down. IIIM Event/Object Manager rule provides the flexible mechanism to adopt with a variety of IM needs and conditions.

Key Binding Synchronization

The Primary Key Binding Rule is determined by PCE, LWE and the language engines loaded onto the remote IIIM Server. By default, the IIIM Framework uses the com.sun.iiim.pce1.s1 syntax rule for PCE. The language engines and PCE loaded onto the remote IIIM Server can synchronize on key binding by downloading the Language Engine Specific Key Binding Rule to IIIMCF. The language engines loaded onto remote IIIM Server can also synchronize with LWE by downloading their own collaborative LWEs onto IIIMCF.

JavaOS1.x Lightweight Engine Compatibility Box

Earlier versions of IIIMJCF in JavaOS1.x provided a simple Lightweight Engine interface which is incompatible with IIIMJCF for Java2. The compatibility box enables LWEs, written for IIIMJCF in JavaOS1.x, to run inside IIIMJCF for Java2.

IIIMF Component list

IM user interface feedback	Pre-edit Status Lookup Auxiliary
IIIM Java Client Framework	JDK1.2 IM SPI adapter JavaOS1.x private IM SPI adapter IIIM Event/Object Manager IIIM Event/Object Manager rule Primary composition engine Composition/binding rules IIIM protocol driver Lightweight engine
IIIM X Client Framework	IIIM protocol driver Syntax rule driven Local IM
IIIM Server Framework	IIIM protocol driver for server X11R5 XIM protocol driver X11R6 XIM protocol driver Resource manager/session manager Protocol driver manager X rendering object Java rendering object Per locale VM separator Platform neutral converters IIIM engine receptor SPI Cascade adapter Direct Cascade adapter XSunIM Adapter XSunIM Platform specific libraries
IIIM Bridge on Win32	IIIM protocol driver

Protocol Specification

Future Direction

Jini based discovery and lookup

Jini discovery and lookup service can be considered as an additional mechanism for the lookup and downloading of IIIM objects, especially for IIIMJCF. Once IIIMCJF itself becomes Jini enabled (depending on whether or not the JDK IM framework engine SPI supports Jini based IM discovery and lookup) it is technically possible to load IIIMCJF itself dynamically loaded onto a Java2 platform.

Voice input

IIIM Protocol works as a lightweight container protocol framework for IM. The Collaborative Voice Input Device Support with other input methods including Networks Voice Recognition Server as well as Local Lightweight Voice Recognition Engine can be seamlessly incorporated technically.