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 <HTML>, <BODY>, or <HEAD> 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.
Navaneeth Krishnan is an employee of Sun Microsystems based in Bangalore, India and he currently works with the Sun Java System Portal Server group.
It seems that new development has been done. Is this project dead?
about j2 clustering
2005-08-03 02:33:07 duduxuan
[Reply | View]
i wonder to know that does Jetspeed2 support clustering?and how to ? thanks:)
WSRP Support
2004-12-17 08:29:52 bcastle
[Reply | View]
I don't see WSRP listed in the overview of features for Jetspeed-2. Does Jetspeed-2 have the ability to act as a WSRP Consumer? If not, is WSRP support planned in the future?
In Jetspeed2 :
While trying to add new portlests, i need to chose from the existing list.
Is there any setting so that i can add my own portlet [Its possilble in jetspeed 1.6]
jetspeed2 and performance issues
2004-12-03 07:10:30 speculatrix
[Reply | View]
jetspeed1 is a real performance hog, when I tried it out early this year. Even with just one or two self-written simple portlets, it would eat memory and CPU, till my dual-p4-xeon with 2GB of memory gave very sluggish performance - rendering pages in 100's of milliseconds.
In contrast, the same machine running the portlet code as a simple tomcat servlet could render a page in less than 35ms.
Will J2 address this issue, or will I have to buy 8-way Opteron boxes with 8GB of memory just to make the thing run at an acceptable speed?
Paul
jetspeed2 and performance issues
2004-12-16 20:28:47 impauk
[Reply | View]
"jetspeed1 is a real performance hog, when I tried it out early this year. Even with just one or two self-written simple portlets, it would eat memory and CPU, till my dual-p4-xeon with 2GB of memory gave very sluggish performance - rendering pages in 100's of milliseconds."
I think it depends on how you developed your portal. I have developed 3 enterprise portal with Jetspeed 1 for 2 fortune 100 companies. We used velocity as default template engine as it has better performance than JSPs. We have extended for parallel content loading and proper content and object caching based on provided JS1 and turbine cache. It is up and running as P1 application. It was pretty easy for new portlet developments, personalization , error/exception handling and scalablity. Average page loading is less than 40 ms with 13 portlets.
Only issue we had concerned was about not standard to jsr 168.