WebSphere Portal 6 and the business case for Portals/Portlets
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 Magnolia, Alfresco, Liferay, JBoss Portal, Exo, and others. Another useful site is portal patterns.com.
Lightweight development environment required
So, IBM , its a great product, just needs to be packaged the right way when you offer to developers.
Re: Lightweight development environment required
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).