 | Level: Introductory Jimmy Thrasher (jjthrash@us.ibm.com), Software Engineer, IBM
Alan Booth (aebooth@us.ibm.com), Software Engineer, IBM
Kathryn Britton (brittonk@us.ibm.com), Senior Technical Staff Member, IBM
01 Jan 2002 Enhance your reach on the World Wide Web with IBM WebSphere Portal Server and IBM WebSphere Transcoding Publisher. WebSphere Portal Server lets companies build custom portal Web sites to deliver personalized Web pages to their employees, business partners, and customers. WebSphere Transcoding Publisher dynamically adapts Web content to match the needs of users and their devices, be they laptops, phones, PDAs, or pagers. This article describes a simple programming technique for exploiting the power of WebSphere Transcoding Publisher from a WebSphere Portal Server.
The problem
With WebSphere Portal Server (WPS), producing an enterprise portal has moved from being one monumental task to a set of small manageable tasks. Now content can be produced by small reusable units called portlets. WPS ships with many sample portlets, but it's usually necessary to create your own new portlets to make it fully useful. New portlets can be added easily whenever you want to extend the reach of your portal. So now that you have your portal running, you want to extend it to serve users with wireless devices and other media. That seems to make the task monumental again, requiring you to make each portlet provide its content in several markup languages, because different devices expect different markup. The problem gets even more daunting if you want to tailor the output for the peculiarities of specific devices.
What if you don't want to create multiple versions of each portlet's markups? What if you don't even know Wireless Markup Language (WML), the markup language expected by many Internet-capable phones? If you have to maintain multiple markups for each portlet you develop, doesn't that violate the DRY (Don't Repeat Yourself) principle? Doesn't IBM, big company that it is, have a product that will do this for you? Of course they do. It's called WebSphere Transcoding Publisher (WTP). But isn't WTP a proxy server, or something like that? Doesn't it operate on the entire document on its way back to the client? What if some of your portlets produce just the right WML already, and you only want to use transcoding for some of them? WTP can't handle a patchwork document that is partly HTML and partly WML, can it? Well . . . no. At first it's puzzling how to use the two products together. But if one were to find a way to make individual portlets send their output to WTP, WTP could do its magic and return the version of the portlet output you need for the device that's making the request. Then WPS can put that portlet's output together with the output of other portlets, making a document ready for use. And that's what this article's about.
A bit about WTP
WTP is a versatile content transformation tool. It enables you to:
- Convert markup languages from one to another (transforming HTML to WML, HDML, CHTML, VoiceXML, and others)
- Apply XSL stylesheets to XML data to render it in new markup languages
- Invoke other transformation services, such as machine language translation
- Cut pages down to size so that they fit gracefully on small, medium, and large screens.
Solution overview
This article describes an approach you can use with WPS to take full advantage of the capabilities of WTP.
You can create new portlets that use transcoding to produce output in
multiple different output markup languages, and all you have
to know is HTML. This approach can be used with the versions of both products that are in the field today (WPS 1.2, WTP 3.5, and WTP 4.0).
In our solution, the portlet itself sends its contents to WTP as the body of an HTTP POST request. WTP understands that this is content to be transcoded and returned in an
HTTP response. The full range of WTP content transformation capabilities can be applied to the content, including the markup language conversion, subsetting, and machine language translation capabilities described later in this article.
Figure 1 below shows the interaction between WTP and WPS.
Figure 1. WTP/WPS interaction
The numbers in Figure 1 represent actions, as explained below.
- Each request leaves the device and hits a WTP proxy server.
- The request flows from WTP to the WPS.
- WPS calls one of your portlets.
- Assume you've used the pattern described in this article. Your portlet
can generate HTML output exactly the way you want for your big browser users.
Your portlet also knows which markup language it needs to return.
If a markup language other than HTML is needed, your portlet generates
a special HTTP POST that it sends as a request to the WTP proxy server. This HTTP POST request contains the HTML version of the portlet output.
Don't worry about the details at this point; we provide a portlet class that does this work. You can just subclass it for your portlet.
- The WTP proxy server has a special plugin (a WBI, or Web intermediary, Generator) that intercepts the POST sent in step 4 and turns it into an HTTP response.
This approach turns WTP into a pseudo-Web service.
- The message, now an HTTP response, travels through WTP and gets transcoded to match the portlet's desired output.
Let's assume the portlet needed WML output. The HTML to WML conversion transcoder is invoked. The WML version is then sent back to the portlet. It's also possible that WTP has appropriate instructions, either annotation or a clipper program, for
picking out an appropriate subset of the original portal output -- just enough to fit the phone.
If so, WTP will clip the portlet content down to size.
- The portlet has now generated a WML version of its output by simply writing HTML and
relying on transcoding to do the rest.
- WPS assembles the new portlet page and sends it to WTP on the way back to the client.
- At this point, WTP performs any operations that need to occur for the
complete document or image retrieved from the portal. For example, if it detects
that the requesting device has memory limitations,
the WTP proxy breaks a large document into fragments and sends the first fragment to the requesting device.
If the device expects wireless bitmap images, WTP transcodes GIFs and JPEGs into the required format.
Deck fragmentation can make your life a lot easier; you don't have to worry about
your aggregated documents being too big for the limited memory of your users' phones. Without deck fragmentation, you'll probably get service calls from irate users annoyed by phone
malfunctions and battery events when they try to use the portal.
You can extend your portlets in four easy steps:
- Add a custom plugin to WTP.
- Modify your portlets to use transcoding. This is an easy, 2-line change.
- Make the portlet superclass files available to your portlet.
- Configure your portlet so it knows how to reach WTP.
These steps are explained in detail in the next section. The custom plugin and portlet superclass are both attached to this article, ready to use. The configuration change is simple, and we provide an example that you can copy-and-paste into your portlet configuration file.
Solution details
This section delves into the details of extending your portlets.
Adding a custom plugin to WTP
WTP needs to know how to catch requests coming from your portlets. With this solution, WTP must be configured as a standalone proxy so it is listening on a port for HTTP requests. The new plugin extends an existing WTP that is acting in its HTTP proxy mode as an intermediary between the client and Web server to also operate as a backend service to a portal server,
as shown in Figure 1. Thus, the same WTP server can operate
both as a real network proxy and as a backend transcoding service for WPS. In its proxy role, the WTP server can still perform any transcoding functions that
work on the entire page, especially the deck fragmentation transcoder that breaks documents
into smaller sizes. For more information, see WTP documentation on the
WTP Library page (see Resources for a link).
The custom plugin is included with this article in a JAR file that is ready to
be downloaded and registered with WTP. Modifying your portlets to use transcoding
Now that we have the WTP stuff working, we need to set up the WPS side of
things. The ideal is to have the least impact on developers. Our
solution to this problem is to create a reusable base class,
which portlet writers can extend, that implements logic to send the POST request to WTP.
Make your ...PortletController class subclass TranscodablePortletController. Once you've extended this class, only one other code change is needed. You need to rename the
doView() method in your ...PortletController class, calling it
doViewBody(). That's it. By changing two lines of code, your portlet can invoke transcoding. Making the transcodable portlet class files available to your portlet
To make the transcodable portlet class files available to your portlet, simply package the JAR file we provide in your Portlet ARchive (PAR) file.
Configuring your portlet to reach WTP
Results (the fun part)
So, what do we do with all of this? As long as you extend our TranscodablePortletController class, the only thing you need to do is implement the doViewBody() method
in your portlet. If you have already written the portlet, just rename the
doView()
method to
doViewBody(). Make sure that your portlet controller doesn't
include a
doView() method, since that would override the method in
the superclass that invokes transcoding.
doViewBody() method
public void doViewBody(
PortletRequest request,
PortletResponse response)
throws IOException, PortletException {
PrintWriter writer = response.getWriter();
// Fetch the page and write it to the PrintWriter
URLConnection connection =
new URL("http://www.ibm.com/ibm/stock").openConnection();
InputStreamReader inputStreamReader =
new InputStreamReader(connection.getInputStream());
boolean done = false;
while (!done) {
char[] buffer = new char[1024];
int amountRead = inputStreamReader.read(buffer);
if (amountRead > 0) {
writer.write(buffer, 0, amountRead);
}
else {
inputStreamReader.close();
done = true;
}
}
} |
TranscodablePortletController
However, it doesn't seem quite right to stick an entire page into a portlet,
which is normally supposed to be small. Fortunately, WTP has an annotation
feature that can strip a Web page down to only what you want. It also ships
with a sample annotation that will clip the IBM stock page down to only the
summary table, so that work is already done for you.
External annotators are selected primarily by matching
request URLs against the URL patterns associated with the annotation. By default the IBM stock annotator is registered to match the URL "http://www.ibm.com/ibm/stock" for obvious reasons. We need to change its matching rule in WTP to "*/%%WPS/IBMStock",
since the request the TranscodablePortletController sends to WTP will look like
"http://localhost:8088/%%WPS/IBMStock." (IBMStock is
the name of our portlet). Also, by default, this annotator is disabled in WTP.
We need to enable it. You can do both of these operations with the WTP administration
console.
The portlet gets packaged with the portlet code, the portlet.xml file, and the JAR file containing our helper classes. We can then register it with WPS. Now it's time to see what you get. Figure 2 shows the portlet output if all we do is apply annotation to cut it down to size for a small screen. We won't show the full portal page here, and the document is still in HTML, since we're showing it on the Internet Explorer 5 browser.
Go to the full IBM stock page if you want to see the full page without any subsetting.
Figure 2. Portlet in IE
No doubt we could modify the content even further to make the colors match
and everything, but this is about the right amount of information for a phone. Now let's add more WTP power. WTP can convert HTML to WML for a WAP phone. How about other WTP features? How about machine translation? Let's say we're French and want to view the stock quotes in French on a WAP phone. What do we do? We turn on the Machine Translation plugin in WTP and configure it to use a translation server. That's it. The results are shown below in Figure 3.
Figure 3. French WAP phone
Pretty cool, n'est-ce pas? We have essentially opened up the entire set of WTP functions to the world of portlet development while minimizing the effort a portlet developer has to put forth. Now your portlet can exploit existing WTP functions and lets you add new WTP function for the portlet to use, such as specialized annotation files or Java plugins that manipulate the document. This article gives you all you need to program your own transcodable portlets, but if you want to know all about how we did it, stay tuned for an upcoming article on the subject.
Download | Name | Size | Download method |
|---|
| wpswtp.zip | | HTTP |
Resources
About the authors | | |
Jimmy Thrasher is a Software Engineer at IBM, and works as a developer for WebSphere Transcoding Publisher. Jimmy is a graduate of North Carolina State University in Computer Science and Applied Mathematics. He has altogether too many interests, not the least of which are playing guitar, programming in Ruby, and learning languages (human ones). Jimmy can be contacted at jjthrash@us.ibm.com.
|
| | | Alan Booth is a Software Engineer for IBM in Research Triangle Park, North Carolina.
He is currently working on WebSphere Transcoding Publisher.
His other interests include mountain biking. Alan has also written two other developerWorks papers, one on Stress Testing the Transcoding Publisher product and another on
Spinning your XML for screens of all sizes. Alan is a graduate of North Carolina State University and can be reached at aebooth@us.ibm.com.
|
| | | Kathryn Heninger Britton is a Senior Technical Staff Member for IBM in Research Triangle Park,
North Carolina. Before coming to IBM, she worked with David Parnas on the Software Cost Reduction project, a software engineering technology transfer experiment at the Naval Research Laboratory. During her 20 years at IBM, she has worked on two-phase commit protocols,
multiprotocol networking, and wireless applications. She led the development
of the IBM WebSphere Transcoding Publisher product from original inception through two releases in 2000. She now serves as the product architect. Kathryn co-authored an IBM Systems Journal article, Transcoding: Extending eBusiness to New Environments and a developerWorks paper,
Spinning your XML for screens of all sizes. Kathryn is a graduate of Stanford University and has two Masters degrees from the University of North Carolina at Chapel Hill. She can be reached at
brittonk@us.ibm.com.
|
Rate this page
| |
