<<

. 78
( 87 .)



>>



Summary
In this chapter we walked you through a number of integration patterns.
We showed you the abundance of possibilities that are at your disposal and
explained what each one entails. We showed you both front-end integration
patterns and back-end integration patterns. Front-end integration patterns
make use of the fact that the vast majority of applications you will want
to integrate into the portal are Web enabled and have an Internet archi-
tecture. In these cases you can expose these screens directly within your
portal or use sections from the HTML pages and create subsets of infor-
mation to be exposed through the portal. This allows you to make use of
the existing application suites with very little development and with less-
than-perfect understanding of the underlying data model and functional
semantics forming the core of the application. This type of integration is
also useful when you already have a functional portal (for example, HR
portal with HR self-service) and are building a larger enterprise portal that
needs to provide functional elements as well. In this case you can get in-
tegration done very quickly with very little effort. The disadvantages are
that you are limited to the functions already exposed through the func-
tional portal and/or the Web-enabled applications, which you have to deal
with having a possibly inconsistent user interface look and feel, that you
need to handle single sign-on with the external application/portal outside
of WP (refer back to Chapter 21 for more on single sign-on) and that you
cannot have custom navigation among the existing functions. Even with all
these disadvantages, it has been our experience that front-end integration
is very effective, relatively easy to perform, and provides good return on
investment.
The other category of integration patterns we covered was back-end in-
tegration. In these patterns the application suite is accessed through an
adapter or connector that retrieves data from the back-end application and
uses APIs to perform transactions. Portlets make use of classes that use the
adapter to perform all this. Back-end integration provides you with much
more control because most application suites have very comprehensive API
sets and because (at least in some of these patterns) you are developing your
own portlets and can control the user interface and the navigation.
Back-end integration tends to be more complex than front-end integration
and tends to require more expertise. On the other hand, it is more stable”
APIs and adapters change much less often than user interface and if you
use some kind of screen-scraping approach you may be surprised when
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53




Integrating ExternalApplications withWebSphere Portal 471


the back-end application team upgrades their software. Back-end integra-
tion also usually means less operational cost because if all users access the
application through the portal then you only need to have an API server
running and do not require a full Web server environment for the appli-
cation. Finally, many of the front-end integration portlets have only been
tested for speci¬c application versions and are sometimes no more than a
proof-of-concept type of solution”be careful to check all the “small print”
before you opt to bypass the more comprehensive back-end integration.
In either case, prepackaged solutions mean much less work with a disad-
vantage of providing you with less control. While back-end integration usu-
ally involves more work than front-end integration, prepackaged portlets
that may be available on the portlet catalog require by far the least amount
of work. Therefore, regardless of whether you choose a back-end or a front-
end approach, our suggestion is that you try to use an existing integration
solution before you delve into development of new portlets and code and
stick with it if you can get most of the functionality you need.
Now that you know about the various methods that are available for
integrating applications that may be used by the large user base using your
portal, let™s turn to the subject of how to support ALL users”regardless
of where they access the portal from and what device they use. In the next
chapter we address the topic of mobile portals supporting users on-the-go
and users using devices other than conventional PCs.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53




472
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




CHAPTER

24

Supporting Mobile Users

In this chapter you will learn how to use WebSphere Portal to support mo-
bile users. You will see how WP (and products that extend WP) can be
used to deploy portlets that provide access using various browsers and mi-
crobrowsers commonly used on devices such as Personal Digital Assistants
(PDAs) and mobile phones. You will learn how to develop portlets that gen-
erate content for such devices and how to deploy Transcoding Technology
(TT) that can use existing portlets originally targeting standard browsers
to be used from these more limited platforms. You will also learn how to
address issues that come up due to the fact that mobile users do not always
have a continuous connection back to the server and sometimes need to be
able to continue using some portlets in an of¬‚ine environment.
WebSphere™s mobile strategy is centered on the WebSphere Everyplace
product family. Parts of this chapter discuss elements of this product fam-
ily, and predominantly WebSphere Everyplace Access (WEA). WEA is ac-
tually a product that includes WP as an embedded component and from
a server-centric viewpoint is an extension of WP. We will introduce you to
the features directly implemented in WP for allowing you to serve mobile
users as well as show you what WEA has to offer as an extension to WP. We
will also introduce you to TT allowing you to write portlets that generate
content once and have external rules that generate multiple markup types
(suited to multiple browsers and devices) from this single portlet presenta-
tion. This eliminates the need for multiple portlets that implement the same
function but serve different device types. Both WP as well as WEA includes
elements of TT and we will review the most important features in TT that
can help you deploy multidevice support quickly.



473
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




474 Chapter 24


Mobile Users
Most people think of portals in terms of Web pages that are accessed by
workstations or laptops used in an of¬ce environment and/or from the
home. Portals help organize the various applications and data that can be
accessed and provide a way to manage the Web desktop.
The reason most people have this large-computer-centric view of portals
is that portals, as any computing technology, were initially used primarily
by users with a high degree of sophistication when it comes to informa-
tion technology. However, two trends are making this PC and workstation
viewpoint incomplete.
More and more portals serve very large communities”often serving com-
munities that are not necessarily information technology professionals nor
have a strong af¬nity to computers. The second is that today there are a very
large number of devices that can access the Internet that are not computers
in the classic sense (all these devices have some kind of processor and are
technically computers too). These devices include Internet-enabled phones,
PDAs, and handhelds. In fact, there are already more such devices being
used today than there are PCs and the number of such devices is constantly
growing”both in the consumer world and in the business world. This is
especially relevant for portal developers. As an example, when large com-
panies decide to build and deploy a large employee portal that will cover
all Human Resource functions, the effect can only be achieved through very
high utilization levels by employees. This sometimes means that multiple
access channels need to be provided to the functionality deployed on the
portal.
The direct result of these two trends is the fact that developers of portals
and portlets need to address a wide variety of devices that can be used
to access content and applications. Different devices have different form
factors and different data-entry interfaces. A portlet that creates content
that looks good on a laptop may look awful on a mobile phone”in fact,
it will probably be unusable. In addition, different devices have data-entry
mechanisms. Phones should be used in a way that users are asked to select
among various options but should not be forced to key in large amounts of
information. Another example includes Symbol Technologies™ PDAs that
have a barcode reader”in which case data can be entered without any key-
ing in or graf¬ti-type typing (see Figure 24-1). Symbol has two such product
lines”one based on the Palm OS and one on the Pocket PC operating sys-
tem by Microsoft”both having a barcode scanner. If you have a job that
includes delivering packages, you can simply scan a barcode on a label that
is attached to the package rather than key in the number, thereby cutting
the delivery time as well as errors that will undoubtedly occur if you have
to type in the package number.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




Supporting Mobile Users 475




Figure 24-1 Palm OS based Symbol PDA with bar code scanner.



Addressing many devices means carefully thinking not only about the
user interface, but also about some technical challenges including the fact
that different platforms have different browsers and microbrowsers sup-
porting different languages. For example, both Internet Explorer (IE) on a
laptop and Pocket IE on a PDA support HTML but most microbrowsers
on mobile phones support the wireless markup language (WML) or an
older (and quickly fading) markup language called HDML. In Japan, mobile
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




476 Chapter 24


phones (called i-mode phones) support yet another language called cHTML
(compact HTML).
Support for different languages, screen sizes, and input mechanisms are
not all you need to worry about. People who use workstations and PCs are
normally in an of¬ce environment and connected through a high-speed net-
work to the Internet. People who are in the ¬eld (such as service technicians)
will often need to have access to the portal using a wireless environment”
and we don™t just mean hot spots in Starbucks shops. Such workers need to
have access over true wireless networks that are usually provided by large
cellular companies or through private radio networks. These networks tend
to be slower and in many parts of the world (for example, the United States)
provide spotty service. In order for these workers to be effective, they need
to be able to continue to use their data and applications even when the
network is down or when coverage is nonexistent (regardless of whether
the reason is that there are simply no cell towers in the area or work needs
to be performed in a basement of a large building).
To recap, the issues that you should keep in mind when building por-
tals and portlets serving large and mobile communities (and that we will
address in this chapter) are as follows:

Support for multiple presentations for different devices
Support for both online and of¬‚ine access
Support for multiple access networks



Supporting Multiple Markups
Most devices that could be used to access portal functionality have some
kind of browser. Such browsers are based on a markup language, exam-
ples being HTML, WML, and cHTML. The ¬rst thing you need to ensure,
therefore, is that your portlets have the right setup for supporting multiple
markups.
If you are working within WebSphere Studio Site Developer (WSSD) and
have the portlet toolkit installed, you can specify the additional markup
support when creating a new portlet application project. Speci¬cally, when
you use the wizard for creating such a project click the Next buttons rather
than the Finish button; the last wizard panel will allow you to specify ad-
ditional markup types as shown in Figure 24-2.
Alternatively, if you already have a portlet application project and you
want to add additional markup support, double-click the portlet.xml
¬le. This will open the portlet con¬guration editor. The following steps
allow you to add or remove markup supported by your portlet:
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




Supporting Mobile Users 477




Figure 24-2 Specifying additional markup within the WSSD portlet application project
wizard.


1. Select your portlet from within the PortletApplication selection.
2. Scroll down”the fourth section on the right-hand side allows you to
add additional markup support. By default you only have HTML
support.
3. Click Add and select the markup type as shown in Figure 24-3. Click
OK.




Figure 24-3 Adding markup within WSSD.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH

<<

. 78
( 87 .)



>>