InfoQ

News

WebSphere Portal 6 and the business case for Portals/Portlets

Posted by Floyd Marinescu on Aug 25, 2006 05:00 PM

Community
Java
Topics
Portal/CMS
Tags
IBM,
Portlets,
WebSphere Portal,
WSRP,
Java Content Repository
IBM has announced Websphere Portal Server 6.0, it's entry level Portal offering. Portal Serve includes Portlet Factory (a wysiwyg component-oriented Portlet design tool), the ability to create composite apps with Portlets and connect to diverse backends, basic SSO, personalization-rules, configurable security policies, built in search, the ability to host multiple distinct sites off one instance, WSRP, and JSR 168 Portlets extended with IBM's inter-portlet communication framework.  InfoQ spoke to IBM's Bill Swatling and Chris Lam to get more background on IBM both the announcement and also IBM's experiences with Portal development in the enterprise.

Websphere Portal Server is intended to be a way for a with existing information systems to get started with the portal/portlet approach. The biggest difference between Portal Server and the other two editions (Enable and Extend) is that it doesn't have it's own document repository and document  management features (those come in Websphere Portal Extend).   Portal Server is intended for departments which may already have a system for authoring content (like Vignette, Documentum), but want to re do their public-facing site with a portal.  They can use the hundreds of Portlet connectors provided with PortalServer to connect to their existing backends to draw data from the repositories. Another strong feature is that you can put various portlets together onto a template, allowing different departments to modify the template to customize what components are served and how they look, all served off of the same instance of the Portal Server in the datacenter.

IBM is a chair of both JSR 168 and the WSRP committees and has been driving those specs in response to customer demands for reuseable, composite web applications, that are configurable by the lines of business in a large enterprise - without needing involvement from the IT organization.   According to Bill Swatling:
Cutting edge composite apps are generally in finance where IT departments build hundreds of different portlets and then use Portal technology to build internal and external apps composed of one or more portal pages consisting with multiple portlets. Statestreet bank is a long time portal customer in the Boston area and they built a b2b app serving institutional investmentors, they built 200 portlets for the app, with dashboarding, etc. Metlife in South Carolina has multiple projects primarily using WS Portal for building applications. Portlets are for more than aggreagting content on a screen like traditional Portals; the future of the Portal approach is to be a framework of building apps of all different kinds.   Callcenters:  customer call history portlets, campaigns portlets, customer information portlets.  Part of the value is that they can tap the services within the portal framework (access control, personalization, etc) without writing those parts of an app themselves.
But still, why use a portal/porltet when you can just roll your own components using existing Java web frameworks? Bill responded:
The portal part of the composite app story gives the ability of the line of businesses to customize, personalize,  and target their portals to the individual audiences that they need to serve - without the involvement of the IT organization.  HSBC uses WS Portal for their internet banking app, on their public website they want to marry the application portions of their portlets and merge them with their marketing and product information that helps them sell different services. The IT organization builds portlet component for these and promotes them via structured process into the Portal environment - then individual lines of business have the abilty to assemble their own apps in different ways that makes sense to them.  The power of the Portal is that IT can contribute backend stuff and while the lines of businesss can change things things in a fine grained manner (appearance, even what components and where do they appear).  Every day they can change the portal, view the logs to seee what happened and what worked, etc.
On the importance of Portlets and JSR 168, Bill responded:
we think jsr 168 and portlets is important enough to invest one person to the spec and a number of developers to build the RI. It's important to us is because  a standard is a way to provide business flexibility and choice to our customers in a way that avoids vendor lockin and creates a community around the standard that creates a reusable skillsets around it.
On the Java Content Repository spec defined by JSR 170 (which InfoQ itself uses and swears by).
JSR 170 isn't quite complete enough to do everything we need inside Portal so we augment it with defined extenstion points in the spec.  WS Portal Enable is based on that spec, although haven't tested compliant.   We would like to get to the point through the spec where the content respoitory is interchangeable beneath WS Portal, so that customers could use a third party vendor repository underneath Portal, such as Documentum - but letting people take advantage of personalization and role based action control provided by WS Portal.
Gartner and IDC have positioned IBM as #1 in the Portals market. There is however lots of competition from BEA, Oracle, and a growing number of open source Portals targetting the enterprise such as MagnoliaAlfresco, Liferay, JBoss Portal, Exo, and others.   Another useful site is portal patterns.com.

2 comments

Reply

Lightweight development environment required by karan malhi Posted Aug 28, 2006 7:40 PM
Re: Lightweight development environment required by Kenny Smith Posted Oct 26, 2006 7:18 PM
  1. Back to top

    Lightweight development environment required

    Aug 28, 2006 7:40 PM by karan malhi

    Websphere portal is really good. In my experience, the portal guys really need to figure out a way to provide the developer with a lightweight development environment. I dont know of too many people who use all the IBM portlets which come with portal toolkit. Instead, there should be a "really simple" mechanism to add or remove IBM portlets which are shipped with the toolkit and that they should not be loaded by default. So, IBM , its a great product, just needs to be packaged the right way when you offer to developers.

  2. IBM has announced the the beta of their Rational Development Platform 7. Unfortunately you must register for it. This version includes the tools to develop the themes and skins for Portal 6 as well as a test environment. I think it will be far from lightweight however. You can tune the IDE for better performance to get the most out of it. The alternative is to use Eclipse with the WTP, but you need to know the JSR168 pretty well before you start. There is also no facility to import an export the skins and themes, other than FTP. This makes it rather hard to update them, unless you really know what you're doing. The Portal 6 is a much better packaged solution than prior releases. IBM has not refined it enough for their much revered iSeries server. They advertise it much much the built in Process server is not supported on that platform yet (as I found out the hard way). http://thejavablues.blogspot.com

Exclusive Content

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.

Nick Sieger on JRuby

Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.

Rustan Leino and Mike Barnett on Spec#

Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.

10 Ways to Screw Up with Scrum and XP

Henrik Kniberg talks about 10 possible reasons to fail while doing Scrum and XP. Maybe the team does not have a definition of what Done means to them, or they don't know what their velocity is.