Ease Communication Between Portals and Back-End Systems
IT managers are continually asked to do
more with less. Competitive pressures
and budgetary constraints compel IT
departments to capitalize on the organization's
existing infrastructure as well as
maximize the value of any extensions or custom
development efforts.
This has been especially true in the
realm of Web portals, and the barriers to
success are all the more challenging.
Many organizations that run multiple, heterogeneous
portal environments want to deliver pieces
of application functionality as portlets that can be
consumed through various internal and external
portals. The custom development, reconfiguration,
and integration work involved in deploying and
redeploying portlets inside of multiple application
servers can take tens of thousands of dollars worth
of IT staff time.
All of which gives the IT industry ample cause
to celebrate the long-awaited ratification of two
complementary specifications - Web Services for
Remote Portlets (WSRP) and JSR 168 - as industry
standards. WSRP allows for "plug-and-play" of portals,
intermediary content aggregation applications,
and integration with applications from disparate
sources. JSR 168, also known as "Portlets
1.0," is a Java Community Process portlet specification
that defines a set of Java APIs to enable
interoperability between portals and portlets.
As portal vendors far and wide adopt these new
standards and begin to build support for them within
their products, the potential for delivering lowcost
composite applications to a single, contextual
interface through the Web is more of a reality than
ever. Building custom applications upon standardsbased
logic such as JSR 168 and WSRP will enable
developers and IT managers to reuse application
portlets in a variety of delivery platforms. This is a
key element of a services-oriented architecture
(SOA) in which software components can be
exposed as services on the network and reused for
different applications and purposes.
However, it's also important to recognize that the
ability to more flexibly deploy portlet applications by
writing standards-compliant linkages is just one piece
of a successful portal initiative. Other crucial capabilities
- such as how to utilize the portlet, permission it,
customize it, and make it available to other portal
sites - are handled by the portal management infrastructure
itself. And that is where the rubber
meets the road in terms of evaluating how
capably the different portal software
providers will leverage the power of WSRP
and JSR 168 for their customers.
The challenge now for the vendors
involved is to implement intuitive interfaces
that allow organizations to take advantage of
standards-compliant portlets within multiple
portal sites in a cohesive and consistent
way. Developers and IT professionals need to carefully
scrutinize every vendor's performance and hold
them accountable.
Some of the key criteria for IT organizations to
apply in evaluating their current or potential portal
software provider's capabilities for achieving interoperability
between multiple portals in heterogeneous
enterprise environments include:
Dedication to supporting standards through
delivered product features: Every vendor
should be able to utilize Web services and JSR
168 portlets within the portal, including the
ability to:
- Discover SOAP-based XML data input and
output parameters and to build custom application
interfaces on top of those parameters.
- Run portlets developed to the JSR 168 standard
as well as portlets previously developed
against a proprietary API as a means of providing
backward-compatibility. Organizations
will need a transition period in which the
portlets may be written either to JSR 168 or
the vendor's API.
Ability to incorporate standards-based portlet
functionality in a seamless and integrated way:
How the vendor incorporates third-party or custom
functionality inside the portal management
system is as important as the ability to use
portlets and portal applications developed in a
standards-based way in the first place. Both the
end user's and the administrator's experience of
the portlets - regardless of their origin - should
be completely transparent. Whether they are
based on WSRP or JSR 168 standards or a vendor's
native API, portlets should behave consistently
and deliver key application functionality
transparently to end users. Characteristics of
this behavior and functionality include the
following:
- Customizable permissions based on user and group permissions
- Easy configuration and delivery to end-user pages
- The ability to share portlets between portal sites
- The ability to scale to large enterprise deployments
- The ability for end users to easily personalize their own
portlets and customize where they are used within the portal
The JSR 168 and WSRP industry standards will unquestionably
be cornerstones in the foundation of any truly successful portal
deployment that aspires to the SOA ideal. However, portal administrators
also require a solid infrastructure for creating, customizing,
deploying, and reusing portlet application functionality across multiple
portal instances. Developers should look for a portal solutions
provider with a vision and a long-term track record of developing
standards-based portals that encompass all of these building blocks
as well.
About the Author
As vice president of product strategy, Edward Anuff is shaping Vignette's go-to-market strategy and maintaining a line of award-winning products and services. He joined Vignette following their acquisition of Epicentric, a portal software company, where he was chairman, cofounder, and chief strategy officer. Since the acquisition, he has taken an active role in the integration of the companies. He is the author of The Java Sourcebook (J.Wiley and Sons), one of the first books on the Java programming language.
anuff@vignette.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com