We recently spoke with David Sean Taylor, an open source software developer with Bluesunrise Software, based in Sonoma County, California. He's been involved with developing
Apache projects and, specifically, Jetspeed for almost four years now. We talked with him about Jetspeed and the Portlet spec detailed in JSR 168.

What's new in Jetspeed-2 (J2)?

Everything :) Jetspeed-2 is a complete rewrite of Jetspeed-1. It is
the next-generation enterprise portal at Apache Portals. It's hard to pick out the coolest new feature. Some may think that the component architecture and Spring
integration, others like CMS-based navigation model, and others like the
standardization of portlet development. Personally, what is cool to
me is the new community at Apache Portals, and how Jetspeed-2 fits
into that community as the enterprise portal.

The complete answer of what is new in Jetspeed-2 is:

Fully compliant with
the Java Portlet API standard

Separation of
portlet applications from portal

Live deployment
model for portlet applications and portal layouts

Component-based
architecture based on Spring

Multi-threaded
portlet aggregation engine

Scalable cluster
architecture

Pipeline-based
request processing

JAAS security
components

Apache Portal
bridges

Jakarta Struts

Java Server Faces

PHP, Perl
integration

Jakarta Velocity

CMS-based site
navigation

SSO component

Web content
component

Web services
component

Jetspeed-2 is a part of an
open enterprise development platform based on components and
standards. You have an excellent deployment model and component
integration framework that will enable people to write standard
portlet applications and supporting components, and deploy them live
to the portal.

Apache Portals provides a
powerful integration platform for all kinds of enterprise software
development. With Portals Bridges, you can now develop portlet
applications with JSF, Struts, PHP, or Velocity. When the Portals
applications project is accepted into Apache, we will have a
community for developing vertical portlet applications that are not
coupled to any portal server.

Does that mean I can grab any JSF/Struts application
and deploy it as a portlet?

Yes, although there are
some differences between portlets and servlets. For example, per the
spec, you can't have &lt;HTML&gt;, &lt;BODY&gt;, or &lt;HEAD&gt; tags in your portlet
fragments. With Struts, if you follow Struts best practices, such as
ensuring Struts applications always use Struts tags for URLs, the
migration of a servlet application is straightforward. Portals
Bridges is a separate project from Jetspeed-2 at Apache Portals. The
bridges are designed to run in any JSR-168 compliant portal; not just
Jetspeed-2.

Can you elaborate a little more about the Jetspeed-2 Live Deployment Model?

The Java Portlet
specification defines a standard deployment model for deploying
portlet applications. It is based on the servlet deployment model;
you simply provide a WAR file and an additional portlet deployment
descriptor: the portlet.xml file. The portlet descriptor defines your
portlets and overall portlet application.

With Jetspeed-2, portlet
applications are dropped into a live, running portal server. Jetspeed
will pick up the changes in the descriptor, and redeploy the modified
portlet application. There is no need to restart the application
server that houses Jetspeed. We currently run on Tomcat 4, Tomcat 5,
JBoss, WebLogic, and WebSphere.

As someone who was on the expert group for the 1.0 specification, what are your thoughts on JSR 168, AKA the Portlet spec?

My thoughts are mixed; a
lot of frustration. The portlet specification
was developed in a closed community. As an Apache committer and
representative of Apache, you can imagine the difficulty of this
situation. I wish we would get back
to working on the specification as soon as possible. I wish the Java
specifications weren't controlled and stalled by large corporations.
My goal is for the next specification to be developed as a truly open specification.

In a future version of the spec, I'd also like to see:

Event handling and portlet-to-portlet communication.

Formal model definitions
for portlet windows and entities.

Better support for
extending portlets.

The definition of an API
between container and portal.

More integration points
for portlets in the portlet render cycle.

Why do you think an enterprise should be using Jetspeed, besides the obvious advantage of being open source?

We have created an open platform for true enterprise integration,
based on a component architecture and Java standards. I am excited to
start developing applications with J2. The end result is an
integrator's dream enterprise portal. Portals are the ultimate
end-user integration points for communities or businesses. Jetspeed-2 makes integration as easy as selecting portlets, customizing them live, and dropping them in to your portal for immediate use. For those needing more complex integration, the Jetspeed API provides the clear assembly and interception points for component building and integration.

Since our components are simply (constructor) dependency-injected Spring components, integrators with Spring experience will immediately be up and running. This is where Jetspeed-2 really shines for system integrators. We have found that every portal requires integration with existing business processes. Typical cases are integrating user attributes from diverse applications, web content and service integration, authentication (SSO) integration with
existing LDAP or other commercial databases, and complex
authorization rules based on access control lists. Jetspeed-2 clearly isolates these integration points in the Jetspeed API, based on existing Java standards. This is where Jetspeed provides a clear and open advantage.

Wow! The Spring story is indeed compelling, but do you think
Jetspeed is mature enough to compete with the likes of BEA, IBM, and
Sun portal products?

Well, I can't really say that Jetspeed-2 is mature, since we do
not yet have our first release out. We're shooting for an M1 release in November, followed by a first
production release 2.0 hopefully by the end of the year. We are confident it will
mature and stabilize over the next year. The community is growing
strong; and that is the most important indicator for any open source
project.

I don't necessarily see
Jetspeed as competing with commercial products. At least, that is not
my goal in open source. I see Jetspeed enabling software developers,
consultants, and integrators in the conventional open source
tradition: building communities, contributing to the public commons,
and concentrating on quality software foremost.

Now, if someone wants to
base a commercial portal product on Jetspeed-2, that would be a very
intelligent decision, in my opinion. The Jetspeed-2 architecture is
designed to make assembling portal servers as easy as assembling LEGO
blocks. Everything is componentized with Spring beans and
interceptors. If I were a portal vendor, I would look strongly at the
unique architecture we've created here.

What is it that you are working on now?

I am developing in open source fulltime at the Apache Portals project
where I am a team member on Jetspeed-2, Jetspeed-1, WSRP-4J, and
Pluto. I am in the process of helping bring three new projects to
Apache Portals: Portals Bridges, Jetspeed CMS, and Portals
Applications.

I'm also writing two
books for Manning publications. The first book is about enterprise
portal technology, written along with my coauthors: Stefan Hepper
(the Portlet specification coauthor) and three other WebSphere Portal
Server architects. The second book is coauthored with Scott Weaver,
and is called Jetspeed In Action. JIA will cover everything
you need to know about J2 and Apache Portals. It will have some
useful examples and sample sites for developing full-featured
enterprise portals.

width="1" height="1" border="0" alt=" " />

Navaneeth Krishnan is an employee of Sun Microsystems based in Bangalore, India and he currently works with the Sun Java System Portal Server group.