Extend the reach of data for IBM Mashup Center

Get started with plug-in development

Learn about extending IBM® Mashup Center's InfoSphere™ MashupHub feed sources in Enterprise Mashups, and gain first-hand knowledge of how to do so using code samples.


Chris C. Gruber, Product Manager, IBM, Software Group

Chris GruberWith more than fifteen years of industry experience, Chris Gruber, Technical Manager for Developer Initiatives, works with IBM Information Management on industry-leading Data Server products. Previously, Chris has worked as a Senior Product Manager for Sybase iAnywhere Solutions. He has worked very closely with engineering and development partners accelerating partners time to the market. He currently works at IBM Information Management as Product Manager in Web 2.0 product lines.

Jim Hsu (jimhsu@us.ibm.com), Software Engineer, IBM, Software Group

Author Photo: Jim HsuJim has been with IBM for more than a decade. He received his Bachelor's and Master's degrees in Electrical Engineering and Computer Science from MIT. He is interested in technologies with immediate wide-spread impact and has worked on Web-based Java software technologies in such areas as: Mashups, Web 2.0, Web services, Eclipse, Semantic Web, and e-Business. He has published numerous technical articles and holds more than a dozen U.S. and international patents. Jim is also a member of jStart, an innovative team within IBM’s Emerging Technologies Group, with the mission of leveraging emerging technologies to solve real-world problems for real customers and clients. If you are interested in applying emerging technologies to solve real business needs, today, contact jStart at: jstart@us.ibm.com, or visit us at http://www.ibm.com/software/jstart.

07 August 2008

Also available in Japanese


IBM Mashup Center is a great means to quickly and easily "mashup" data and services and assemble the information on a Web page. Many sources of enterprise data are made available through the default plug-ins that come with IBM Mashup Center's InfoSphere MashupHub. However, there are cases where you will want to leverage new data sources specific to their organization. InfoSphere MashupHub provides an extensible plug-in model that allows you as well as your partners to extend the reach of data and services.

To get the most out of this article, you should be reasonably familiar with IBM Mashup Center and have some Java and JSP experience. To find out more about IBM Mashup Center, refer to the IBM Mashup Center Web page.

This article will review key aspects of extending the IBM Mashup Center by looking at the HelloWorld (hellodemo) sample plug-in and proceeding to tweak it to implement a basic language translation service. In this article, you will also leverage the translation service offered by Google for lightweight translation of text up to 500 bytes in length. The details on the translation service can be found on the Google AJAX Language API Developer's Guide. Three main parameters will be used to call this service in this article:

  • The text to be translated
  • The source language
  • The language to which to be translated into

The translation service returns a result in a Javascript Object Notation (JSON) format. The InfoSphere MashupHub sample plug-in will turn this into an Atom feed.

What is a plug-in?

InfoSphere MashupHub provides a plug-in interface that defines methods for producing a feed, accessing plug-in metadata as well as linkage connecting the server-side plug-in instance to its client-side Javascript. Greater detail on the specification can be found in the product installation at <installation_path>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\client\doc\userdoc\MashupHubAPIRef.pdf or downloaded online from the IBM MashupHub API Reference.

While, this article does not go into too much depth on the plug-in APIs, Figure 1 is a useful relationship model chart from the above specification file as a reference.

Figure 1. Plug-in API relationship reference
Plug-in API relationship reference

To a large extent, the plug-in model is used to add new types of feed data sources to the list that is presented to users when they create a new feed. A new installation of IBM Mashup Center (see Figure 2) does not contain the choice labeled "Translation." However, you will now be shown how to add such a translation service as a feed data source.

Figure 2. The resulting new feed source dialog
The resulting new feed source dialog

At a high level, plug-ins must handle two tasks:

  • Feed Creation: Refers to the code needed to define the feed.
  • Feed Generation: Refers to the code required to actually produce the data and format upon invocation.

Walkthrough of Hello World example feed creation

First find the hellodemo sample in <installation_path>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\client\doc\pluginsamples. When you look at the HelloWorld example, you will note the following files:

  • HelloViewBean.java
  • HelloEditor.java
  • HelloGenerator.java
  • AtomGenerator.java
  • hello.zip

Any given InfoSphere MashupHub plug-in has two major operations: one for the creation of a feed, the other for generating a feed. The AtomGenerator.java and HelloGenerator.java implement the generation feed, whereas the other files (save package.xml, which is metadata for the entire plug-in) implement the creation of the feed.

The hello.zip file requires a specific directory structure and is deployed by copying hello.zip to <installation_path>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\WEB-INF\plugins and restarting the Web application server. The directory structure must be used for all third-party plug-ins for InfoSphere MashupHub. The hello.zip file contains the following files:

  • package.xml
  • hello.jsp
  • Compiled .class files from the Java source files above
  • Icon files

Start with an examination of the package.xml file and then proceed to the implementation of the plug-in code.

The package.xml file

Figure 3. Hello sample package.xml file
Hello sample package.xml file

Here are the key elements of the package.xml file:

  • Name: Used in the list of options after users select New Feed.
  • Author: The name of the plug-in author.
  • Version: The version number for this plug-in, so you can tell the latest version of your plug-in.
  • Category: Specifies under which sub-list this plug-in shall appear. Currently valid categories are departmental and enterprise.
  • Editor: Identifies the class to be loaded for the plug-in editor interface.
  • Generator: Identifies the class to be loaded for the plug-in generator interface.
  • Description: For a summary of this plug-in.
  • The icon paths identify where to load the icons for the plug-in.

Figure 4 is an example package.xml file for a translation service:

Figure 4. The package.xml file for translation plug-in
The package.xml file for translation plug-in

The HelloEditor class

HelloEditor extends BaseEditorPlugin, a base class that requires you to implement renderEditor. This is an important hook into the framework that lets you define the user interface for any input parameters used to create and customize an instance of your feed.

In this case, there is one input parameter, a simple text string you will put into the feed. But in order to prompt the user, you will set up a ViewBean, add it to a form, and then a frame, which you pass back to the framework for display in the user interface. You're building up a simple dialog for the user, so you also set a few standard labels and titles.

One thing to note is you're setting up a callback function named "saveParam" in the form. This callback lets you handle user input after the user clicks Submit. However, this topic will be revisited later in this article.

Figure 5. The renderEditor method definition within the Hello plug-in
The renderEditor method definition within the Hello plug-in

The HelloViewBean class

You can see the code in HelloViewBean.java in Figure 6.

Figure 6. The HelloViewBean method defined in the Hello plug-in
The HelloViewBean method defined in the Hello plug-in

The ViewBean is responsible for providing the path to the JSP file (in this case, hello.jsp) that the framework uses to render the actual input fields. ViewBeans can also pass additional data used by the JSP (such as a dynamic list of available choices), although in this simple example there isn't a need to pass any more data. The suffix can be used in multi-screen Wizard-like interfaces, to provide a unique ID for each screen. Unfortunately, this isn't too illuminating in the case of this HelloWorld example because there is only one screen.

For the purpose of this article, only the two pieces of code are given consideration. The first is the getJSPath method and secondly the suffix attribute to reflect the new names (if this was a more complex wizard). The JSPPath identifies which JSP file to use for the editor. The JSP file is the file that provides the HTML user interface when you create your plug-in. For example, Figure 7 shows the end result of the JSP file for the Hello World file plug-in.

Figure 7. The Hello plug-in editor
The Hello plug-in editor

For your translation routine, you only make two changes to this file. You simply change the suffix and the JSP file name to reflect the JSP file that would be called for translation.

Figure 8. The ViewBean class definition in the Translate plug-in
The ViewBean class definition in the Translate plug-in

The hellodemo.jsp file

While you can certainly make this JSP file much more sophisticated than the file presented in Figure 9, there are a few key things to showcase. This user interface is pretty basic with a label and two form controls: a check box and text box. The HTML IDs (hellotext and prompt) used in the controls are passed back to the saveParams method to be discussed. The check box is used to indicate whether to prompt the user for the hellotext string each time the feed is run.

Figure 9. The Hello.jsp class definition in the Hello plug-in
The Hello.jsp class definition in the Hello plug-in

Because you are using three parameters in the translation services, you are going to set up a text box for text to be translated and two select lists so that the user can select the source and target languages. You will only be interested in prompting for the text to be translated for further usage of a created feed. With this in mind, there is the following JSP file for the translation service. Note the form inputs are named “transtext”, “languagein” and “languageout”; these will be referred to later when you process the form.

See Listing 1. The translate.jsp class definition in the Translate plug-in, in a sidefile.

Figure 10 illustrates what the editor looks like for the translation service.

Figure 10. The Translate plug-in editor
The Translate plug-in editor

You need to save the parameters for this feed so you can use them later in your generator. After the user clicks Submit, your saveParam callback method lets you read the user input and save it away. Now revisit HelloEditor class. Figure 11 shows the saveParam callback from the hello sample that saves away a simple string.

Figure 11. The saveParam method definition within Hello plug-in
The saveParam method definition within Hello plug-in

The input comes in through the RequestData object (it is named “hellotext” from the hello.jsp form). A parameter object is created, with the default value set to the user input. The Java doc included in the product describes the parameter object’s methods. This object is added to the entry object, which saves the information away. You also generate a unique URL for the feed and publish this feed and URL into IBM InfoSphere Mashup.

Look at the TranslateEditor class that is based on the HelloEditor class. There should not be any surprises, as the renderEditor merely changes “Hello” references to the translation text for the user interface. The saveParam method is more complex, as you add parameters. You add three parameters named “transtext”, “languagein”, and “languageout” that correspond directly to the JSP file inputs and are ordered respectively. The parameters are all treated as non-optional strings. As you can see in Listing 2, only the transtext parameter is designed to prompt if a value is not provided. The default values for each of the parameters are all based on user inputs from the translate JSP file. The individual settings for display name and help text are identified in Table 1 for each of the parameters:

Table 1. Parameters for Translate plug-in
Parameter name Display name Help text
Transtext Text to Translate Enter text to Translate
Langaugein Language In Select language
Languageout Language Out Select language to translate

See Listing 2. The SaveParam method definition within Translate plug-in, in a sidefile.

Of course, you need to add the three parameters to the entry generate a unique URL for the feed source and publish the feed source within InfoSphere MashupHub. To help you with what this will look like and where the text is found on the page, a snapshot of the resulting screen is provided in Figure 12, which prompts for parameter for the Translation plug-in.

Figure 12. The Translate plug-in prompts
The Translate plug-in prompts

This completes the code that is necessary to produce the user interface for creating the feed. You now need the code that generates the actual feed.

Walkthrough of Hello World example feed generation

This section discusses the final two Java files from the Hello sample: AtomGenerator.java and HelloGenerator.java. These files generate an Atom feed based on the users input.

HelloGenerator class

The HelloGenerator class extends the BaseGeneratorPlugin and instantiates a new FeedContent object with the generateFeed method.

Figure 13. The HelloGenerator class definition within Hello plug-in
The HelloGenerator class definition within Hello plug-in

AtomGenerator class

The AtomGenerator class does the heavy lifting to generate the actual feed. Well, not so much in the sample provided, as you can see below. The Abdera library is used below, as it provides an implementation of the IETF Atom Syndication Format and Atom Publishing Protocol standards (RFC's 4287 and 5023). The documentation for Abdera can be found on the Apache Wiki or you can find the JavaDoc on the Apache Web site. The code below sets up some basic strings for user, title, subtitle, URLs, and hellotext. At runtime, you may receive parameters to the feed, in this case you capture the hellotext parameter to include in the results of Hello World feed. You proceed to instantiate an Abdera class, which makes it easy to set the ID, title, subtitle, and generator for the feed. You then use the abdera.getFactory.newEntry to add an entry to the feed that establishes the title, ID, and updated author and summary field for the entry. The title is where the sample establishes your parameter data. You can now add the entry and return the feed.

Figure 14. The generateAtomDocument method within Hello plug-in
The generateAtomDocument method within Hello plug-in

The TranslateGenerator class is a trivial implementation, as all of the code is the same as the HelloGenerator code, as shown in Figure 15.

Figure 15. The TranslateGenerator definition within Translate plug-in
The TranslateGenerator definition within Translate plug-in

Now look how you modify AtomGenerator for the translation service. The source service produces JSON and you need to produce XML from this. You leverage the JSON4J support included with InfoSphere MashupHub. The documentation on JSON4J.jar can be found in the IBM Information Center. It may also be useful to review what is in the libraries within MashupHub when building your own plug-in. You can add jars to the library folder in <installation_path>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\WEB-INF\lib, if your code has dependencies. Now walk through the in Listing 3. You may find it easier to open your favorite editor and view the AtomGenerator file, as the source is included as the download along with this document.

See Listing 3. The generateAtomDocument method definition within Translate plug-in, in a sidefile.

Now start with the generateAtomDocument method, which is very similar to that of the hellodemo example, in that there are several strings instantiated for the user, title, subtitle, URLs, and the strings for the parameters: transtext, languagein, and languageout. The parameters are then captured into these strings. The translation service expects the format for the source language and language to which to be translated to be concatenated with the “|” character, which you proceed to do. You assign the string resultingtext to the result of the getTranslation method on line 106. This method uses the languagepair and the transtext string to produce the result (which is hopefully a successful translation). The feed is then generated where the result is placed into the title of the first and only entry of the feed.

In code below, the getTranslation method takes string to aforementioned parameters. Use these parameters to encode a URL. Connect to ajax.googleapis.com using this URL through an HTTP using the GET method. The google service requires that the referrer header be set for this service, which is accomplished on line 50. At the time of writing this article, this service only supports GET methods. Place the results of the GET method into the StringBuffer strBuff.

See Listing 4. The getTranslation method definition within Translate plug-in, in a sidefile.

The JSON4J methods employed to parse the JSON result in text. The expected result is in JSON format, as represented in Listing 5 (from requesting an Italian form of “Hello, World”). You will notice that the result is actually nested, which requires the parse method to be executed twice. You then return the text within the responseData object to the generateAtomDocument method, which fulfills the feed.

Listing 5. Example response from Google translation service
{"responseData": {
    "translatedText":"Ciao mondo"
 "responseDetails": null, "responseStatus": 200}

At this point, you are ready to build and deploy the files into InfoSphere MashupHub and IBM Mashup Center.

Build and deploy

To build the samples, you need a Java 5 JDK on your machine and you need to setup the class path to include InfoSphere MashupHub libraries. If you installed IBM Mashup Center in a different location than the default, you may need to modify the first line to reflect its location. Listing 6 is a script to help you build the hellodemo sample plug-in.

See Listing 6. Build commands for Hello plug-in, in a sidefile.

Listing 7 should build the translation service plug-in that you just created.

See Listing 7. Build commands for Translate plug-in, in a sidefile.

Now that you have these plug-in built, you will want deploy it. Create the ZIP file following the directory structure you see below for hellodemo.

Figure 16. View of the ZIP file for Hello plug-in
View of the ZIP file for Hello plug-in

Similarly, you can do the same for the Translate plug-in:

Figure 17. View of the ZIP file for Translate plug-in
View of the ZIPP file for Translate plug-in

To deploy the plug-in into IBM Mashup Center, simply copy translate_deploy.zip (or hello_deploy.zip) to <installation_path>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\WEB-INF\plugins, and restart the Web application server. You also need to restart IBM Mashup Center’s application server to see these changes.

This is the preferred method. Alternatively, you can copy the file to the specific locations. Batch scripts are included in Appendix A, if you want to use the batch method.


You have just walked through the sample code, and from this code you have made a very useful translation service. This was done relatively quickly with primarily the code included with IBM Mashup Center. These feeds and services can now be used to build Mashups that do some lightweight translation. You are encouraged to review the demo found in the Downloads section, for using the translation service. You now have the basic tools to extend the reach of IBM Mashup Center to customize to your needs.

Appendix A: Alternative deployment method

To deploy the hellodemo plug-in, the script found in Listing 8 would be used.

See Listing 8. Deploy commands for Hello plug-in, in a sidefile.

To deploy the translation plug-in, the script found in Listing 9 would be used.

See Listing 9. Deploy commands for Translate plug-in, in a sidefile.


Sample codetranslate.zip16KB
Deployment file for the hello world samplehello_deploy.zip11KB
Deployment file for the translation sample translate_deploy.zip12KB
Demo for using the translation servicextending.wmv5.7MB



Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management
ArticleTitle=Extend the reach of data for IBM Mashup Center