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
<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.xmlfile. 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.