eNode UI Markup Language can be used to describe progressively richer applications by assimilating elemental web services to form composite applications. This example shows how to seamlessly integrate the previously developed email and fax clients into a translator client.

The general approach used here is similar to that used by the other object composition examples, such as the Date Picker and the Calendar. The obvious difference is that those compositions mostly assemble user interface components, but this one assembles objects that access web services. This underscores the utility of eNode Object Realizer — It is not just for user interfaces.

Make sure you have JRE 1.3.1 or later, and Java Web Start 1.0.1 or later already installed, before you launch Translator. Also see Security Advisories.

Note that the integration of the three services is seamless — The email and fax clients have their own menu bars when they are run as stand-alone applications, but not when they are integrated into the translator application. In this case, they appear to the user as indivisible parts of the translator application, even though each of the three services are provided by a different service provider. Also, the Show Browser Interface menu item in the Help menu demonstrates how you can transparently access HTML-based content and existing web sites by launching the browser from within your application.

However, it is not just the user interface that is seamless — Even data flows seamlessly from the translator to the email and fax services. All of this is accomplished by reusing the original email and fax clients without changing a single line of Java™ code in classes used by those clients!

More interestingly, the glue that binds the various services and their user interface together is 100% pure XML data. Because such markup data can also be generated at run time based on user profiles and credentials, eNode Object Realizer allows you to dynamically alter the mix of services, or change the service provider or user interface for a service to meet users’ needs.

Finally, because all the user-visible text and icons are described in XML resource descriptions, they can be easily localized simply by changing the markup data. You can even drop language choices or reinstate them at run time using dynamically generated markup.

Just like the email and fax clients, the translator client realizes its user interface from markup describing its main view hierarchy in eNode UI Markup Language. Also, just like the email and fax clients, the translator has the same general structure comprised of a controller and mediator to minimize the number of object interconnections. To recapitulate, each of the three client components has the same general structure as shown in the following figure:

The integration of the translation, email and fax services is achieved using a layered approach. In order to avoid making changes to Translator, EMailer, FaxSender, and their associated mediator classes, we define two new mediator objects — one that associates Translator with EMailer, and the other that associates Translator with FaxSender. The idea is that by altering the markup, we can independently add or remove EMailer or FaxSender to or from the mix.

While the emailer and fax clients each support a single action, the translator client is richer. For example, buttons in the original languages tool bar fire a different action than buttons in the translated languages tool bar. Instead of creating separate action listener classes for these actions, we use the actionPerformed() method in the Translator class to translate the text, but define a separate method called enableChoices() in the same class to handle enabling and disabling of language choices. We then use the trampoline mechanism to hook up each action source to the proper action method.

To handle the email and fax actions, we need two separate action objects so that they can be added or removed at run time using dynamically generated markup, if desired. But instead of defining yet another pair of classes, we decided to combine these actions with mediators for the integration layer described above.

This gives rise to two classes, namely, com.enode.xalt.services.EMailAction and com.enode.xalt.services.FaxAction, both of which are capable of functioning either as a controller or as a mediator depending on the situation.

The markup for the translator client starts with a reserve element that contains an object element describing the controller class Translator, followed by standard edit actions, EMailAction, FaxAction, and the main menu bar for the fax client. The reserve element is followed by a frame element that constitutes the root of the view hierarchy for the translator.

The translator object is configured with two bean properties. The mediator property describes the object that manages presentation components in the view, and the operation property describes various attributes of messages that the controller sends to the service endpoint. The values for these message attributes are obtained from the WSDL Document for the Translation Service.

The objects representing EMailAction and FaxAction are each configured with two bean properties. The translator property links back to the translator object. The eMailer property and the faxSender property link to the respective user interface descriptions for the two services.

The rest is purely user interface markup, which is pretty straightforward, as shown below.

The controller com.enode.xalt.services.Translator is a JavaBean™ class that extends javax.swing.AbstractAction. Its actionPerformed() method activates the translation web service. Its enableChoices() method enables or disables language choices depending on user selection and whether there is any text in the top text area.

The controller class also has setter and getter methods for the two bean properties, namely mediator and operation, as indicated in the markup above.

Finally, we decided to consolidate the translator client application by putting its main() method directly in the controller class. You may choose to define a separate class for the client application, if you wish. The full listing for the controller class is shown below:

The mediator com.enode.xalt.services.TranslationMediator is a simple JavaBean class with setter and getter methods for its properties, which consist of the user interface components for the client. It also has methods that can extract data from the user interface components.

Unlike the mediator classes for the email and fax clients, the mediator class for the translation client is more fully developed. An important function of a mediator is to observe components for any changes in their state and update other components appropriately. The TranslationMediator class implements javax.swing.event.DocumentListener to illustrate this concept. Whenever the top text area is empty, the mediator will cause all buttons in the translated languages tool bar to be disabled, but enable relevant choices when the text area is not empty.

The code for the mediator class is shown below:

Finally, com.enode.xalt.services.Translation is a JavaBean class that extends com.enode.Message, where most of the mundane message properties are set.

The code for the message class is self-explanatory. Its full listing is shown below:

com.enode.xalt.services.EMailAction is a JavaBean class that extends javax.swing.AbstractAction. It performs the role of both a controller and a mediator as discussed earlier.

The code for the EMailAction class is shown below:

com.enode.xalt.services.FaxAction is a JavaBean class that extends javax.swing.AbstractAction. It performs the role of both a controller and a mediator as discussed earlier.

The code for the FaxAction class is shown below: