<<

. 79
( 87 .)



>>

WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




478 Chapter 24




Figure 24-4 Multiple markup support for a portlet application project.


Once you have ¬nished adding the various markup types (for example,
as shown in Figure 24-4), save the portlet con¬guration ¬le.
And ¬nally, if you prefer to edit the portlet.xml ¬le directly, markup is
speci¬ed within the supports tag shown below:

<portlet-app
uid="mobileportal.MobilePortalPortlet.50a1bb94df0e00181166c78cbc0d3e57"
major-version="1" minor-version="0">
<portlet-app-name>MobilePortal application</portlet-app-name>
<portlet id="mobileportal.MobilePortalPortlet" href="WEB-
INF/web.xml#mobileportal.MobilePortalPortlet" major-version="1" minor-
version="0">
<portlet-name>MobilePortal portlet</portlet-name>
<cache>
<expires>0</expires>
<shared>no</shared>
</cache>
<allows>
<maximized/>
<minimized/>
</allows>
<supports>
<markup name="html">
<view />
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 479


</markup>
<markup name="wml">
<view />
</markup>
<markup name="chtml">
<view />
</markup>
</supports>
</portlet>
</portlet-app>

HTML, WML, and cHTML are all supported by default with every in-
stallation of WP. There are additional markup types that are supported only
through the use of WEA, and within WSSD only when you install the Ev-
eryplace Toolkit. In this case additional markups that are provided include
the following:
PDA”a subset of HTML useful for PDA browsing. This markup is
also used for of¬‚ine access with the WEA client.
VXML”VoiceXML is a markup language that is used to develop and
deploy voice-enabled portlets. VXML is supported by many
commercial voice servers, and by using VXML markup you can
deploy functionality that can be used by making a voice phone call,
selecting menu options, and making data-entry commands”all
using a normal voice call and pressing your phone keys.


WebSphere Everyplace Access
WEA is a part of the WebSphere Everyplace product line and allows you
to deliver content to mobile devices. Interestingly enough, WEA includes
an embedded instance of WP. In fact, the main goal of WEA is to extend
portal functionality to mobile devices. WEA includes a set of tools as well
as portlets for mobile use. From a tool perspective, it includes enhanced
transcoding capabilities, synchronization functionality with Microsoft Ex-
change and Lotus Notes, and support for of¬‚ine access. From a packaged
application perspective, it includes a set of productivity and personal in-
formation management portlets.

Supporting Of¬‚ine Access
In many companies with mobile workforce, there are situations where
users have less-than-perfect coverage. If you have a cell phone you must
be used to the problems of incomplete coverage. Even if you have good
coverage, wireless connections are often considerably slower than landline
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




480 Chapter 24


connections and conventional Internet connections. All this means that sup-
porting a good experience for mobile users often means synchronizing con-
tent onto a mobile device, ensuring that the mobile unit is fully functional
although it is not connected, and allowing the user to upload actions that
were performed on the mobile unit and resynchronize content at a later
point in time.
WEA and the WEA client (which needs to be installed on the mobile
device) allow you to view, browse, and interact with portal content of¬‚ine.
One of the pages that is created for you by WEA is the of¬‚ine page. All
you need to do per portlet that you want to use of¬‚ine is make sure that it
supports the pda markup and add it to this of¬‚ine page (incidentally”this
means that only HTML-generating portlets can work in an of¬‚ine mode).
The WEA client will then synchronize with WEA and access a special servlet
called WebCache that traverses links on the of¬‚ine page and rewrites the
links and pages referenced by the of¬‚ine page. The rewriting process is
done based on a depth parameter that can be con¬gured within WEA and
controls how many links will be traversed. As an example, if you have a Web
page structure as shown in Figure 24-5 and provide a depth of 4, then the
highlighted pages will be of¬‚oaded to the mobile unit. To specify the link
depth, log in to WEA as an administrator and modify the depth parameter
of the of¬‚ine browsing administration portlet. The default link depth is
de¬ned on the WEA Home ➪ Administration page. A user can also de¬ne
a user-speci¬c link depth value by navigating to WEA Home ➪ Con¬gure.
Once you™ve de¬ned the depth level, you use the WEA client to view the
of¬‚ine page. You need to start the client, con¬gure the access to the WEA
server, and synchronize the of¬‚ine content. As an example, if you are using
a PocketPC unit follow these steps:

1. Select Start ➪ Everyplace Client.
2. Enter your portal name and password.
3. Select My Settings from the drop-down list.
4. Select Network Pro¬les.
5. Enter the fully quali¬ed name to your WEA server.
6. Select Home from the drop-down list and click the Synchronize icon.
This will get the of¬‚ine portlet content onto your unit.

The of¬‚ine page supports a perception that you have direct access to
the portal at all times. You can navigate between pages and view data. The
only difference between of¬‚ine operation and online access is that when you
press Submit in a form, the WEA client will inform you that the submission
has been deferred until you resynchronize with the main server. Speci¬cally,
you will get the following message:
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 481




Figure 24-5 Of¬‚ine synchronization of portlets with a depth of 4 for traversal of links.

Your request is deferred
Due to no active connection now, your request is stored in the database
successfully and will be posted by invoking a sync application later.

In addition to the depth parameter, there is one additional WEA con¬g-
uration step; you need to turn on URI addressability by changing the value
of use.requestId to false in
<WAS HOME>/lib/app/config/services/ConfigService.properties.

Writing portlets that can work of¬‚ine is nontrivial and requires a different
discipline to that you may be used to. When building portlets that will be
used in an of¬‚ine mode you should adhere to the following rules:
1. Always support pda markup.
2. Have only one form per page (this is true for both portlet pages and
pages that can be reached from the portlets).
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54




482 Chapter 24


3. Use only POST in your forms; do not use GET.
4. Write code that maintains session in a way that is resilient to
duplicate submissions of the form. Synchronization does not
guarantee that submissions will occur only once.
5. You can use simple Javascript validations but avoid complex
Javascript code.
6. Do not include links within Javascript and do not rely on Javascript
navigation.
7. Make sure your pages are well formed. You should verify that all tags
are closed correctly as per the XML well-formed-ness rules. You can
use tools such as jtidy available at http://lempinen.net/sami
/jtidy.
8. Do not use PortletActions.
9. Avoid dynamic behavior on screen that affects submission
parameters (for example, pages that dynamically add to HTML
tables for inclusion in a collection; in this case put all options in the
table with check boxes used for de¬ning which entries should be
added to the collection. Always avoid cascading forms).

Before completing this topic we would like to point out that there are ad-
ditional packages other than WEA that provide of¬‚ine portlet capabilities.
Probably the best known is AvantGo by Sybase, which can also be used to
provide of¬‚ine portal capabilities. In this case you will be working directly
with WP but will need to install an AvantGo server that will be doing the
synchronization and caching work.


Supporting Multiple Wireless Environments
When building portals that will be used by mobile users not only do you
need to worry about devices, markup, and of¬‚ine capabilities, but you also
address connectivity issues. Wireless networks can be highly complex and
diverse and this is a topic that we cannot fully address in this book. Our
goal is merely to point out that this is an infrastructure issue you should
plan for.
The Internet is an IP-based network and is ubiquitously available from
homes and of¬ces throughout the world. This means you do not have to deal
with connectivity issues when deploying your portlets and you do not need
to think about how users will get access to your portal. For mobile users
this is not necessarily true. Different geographies have different networks,
some areas have multiple connection types, and others have none. In addi-
tion, wireless networks are not always IP-based and some involve highly
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 483


proprietary radio frequency protocols. The connectivity options include
Hot Spots and 802.11b networks, CDPD, GPRS, Mobitex, GSM, CDMA,
TDMA, satellite networks, iDEN, TETRA, EDACS, and so on. Each of these
networks potentially has its own complexities and peculiarities. Without
getting into too much detail, you should distinguish between the following
types of wireless networks.
1. IP-based networks that provide you with an “always on” connection.
This is the simplest case for you to support because in this case you
don™t have to do anything special”each mobile unit is perceived to
be a node on the Internet and can access your portal in a normal way.
2. Dial-up networks. In these networks you use a phone or another
device that acts as a modem. Once setting up a connection through
another protocol (for example, PPP or over GSM) you can proceed as
though you were connected to the Internet. In this case you will need
to use a connection manager that is suited to the network and the
devices you are using.
3. All other options have proprietary protocol suites. In these options
you will need to either develop a set of adapters using SDKs of the
network providers or use a wireless gateway. A wireless gateway
abstracts the differences in the networks and provides you with a
uni¬ed way to access the server regardless of the networks your
users will be using. Different wireless gateways have different
abstractions. For example, the WebSphere Wireless Gateway (another
component within WebSphere Everyplace) abstracts all the networks
to an IP network resolving all the complexities. A different example
is the Broadbeam Wireless Gateway that creates a queue-based
abstraction that allows your client-side applications to place
messages that need to be delivered to the portal and have messages
come back. The Broadbeam software then takes care of delivering
these messages regardless of the underlying networks.
While adding an additional server to the mix certainly complicates your
environment (see Figure 24-6), we strongly suggest that if you need to de-
ploy your portlets over non-IP networks you use a gateway architecture.
The alternative integration to multiple-carrier SDKs are far more complex.


Transcoding Technology
TT is an enabling technology that allows you to easily deploy portlets that
can support different devices. TT implements three methods that trans-
form content based on device information associated with the request.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-24 WY009-BenNatan-v1.cls May 11, 2004 14:54


<<

. 79
( 87 .)



>>