Sorting out WSRP, JSR168 and Web parts

I’ve noticed a lot of confusion and misunderstandings around these portlet ”standards”. This posting aims to sort things out on a fairly high level of understanding by reasoning around the strengths and weaknesses and suggesting some best practices.

So, what is WSRP?

The abbreviation stands for Web Services for Remote Portlets, and the key word here is “Remote”. It is now a fairly old standard, version 1 came 2003 and version 2 is still in draft although many portal vendoers have already made their own implementations of the not-decided version 2. The standardisation work is run in an OASIS committe’ (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp).

WSRP basically defines how to use SOAP to request and retrieve blocks of HTML, instead of XML as regular web services does. This means that the WSRP portlet runs on a one web server and can appear in one or many web portals running on other web servers by sending HTML-code to these web portals. WSRP portlets can be written in any programming language. Before getting into the reasoning around when to use WSRP, we need to sort out the two “non-remote” portlet specs, JSR168 and Web parts.

Comparing JSR 168 portlets with Web parts

JSR 168 is a standard for coding portlets in Java. It consists of a set of class definitions to be installed on portal products supporting JSR168.

To compare apples with apples, JSR168 competes with Web Parts. WSRP is a completely other kind of fruit. Both can support WSRP. These are the most important points of comparison between Web parts and JSR 168:

• Language : JSR168 portlets can only be developed in Java. No other language works. Web Parts can on the contrary be developed in any language supporting .NET, which at least in theory includes Java/J++…
• Support for different portal plattforms : JSR168 portlets can, at least in theory, be codes once, and run in any os the JSR168-compliant portal produkcts out there. In reality, it is very easy in the Java development tools for each portal product, include product-specific class libraries breaking the standard. Using them makes You tied to a proprietary portal product anyway. In any case, every portlet needs careful testing and debugging when porting from one portal product to another. I personally think that the JSR168 in reality provide very little value from a standardization och reuse point of view. Web Parts makes no secret it’s a proprietary technology and Microsoft makes the most of that freedom not having to compromise in standards committees. Web parts is therefore a superior portlet technology to the JSR168 implementations.
• Support for different environments : JSR168 portlets are just portlets. They only execute in the context of at portal product. Web Parts runs in MOSS/Sharepoint Portal, in Windows as Win32-apps as well as in so called Smart clients for handheld devices.
• Consuming WSRP : Some portal products have built-in WSRP support while others goes through a JSR168 portlet. Microsoft takes that road by offering at out-of-the box WSRP consumer Web part.
• Producing WSRP-portlets : Most JSR168-portal products includes code to emit JSR168-portlets as WSRP. Microsoft haven’t built in WSRP produces support in MOSS 2007, but 3rd-party solutions from NetUnity Software supplies tool to develop WSRP producer portlets on the .NET platform.

This is a simple architecture for JSR168/Web parts portlet applications:

When to use WSRP portlets?

Scenarios motivating use of WSRP are:

• From a host / web server deliver portlets as presentation oriented web services to be included in aggregating web porta application. On such host can cater for many web apps.
• Web portal apps consuming and in a portal framework integrates presentation oriented web services delivered by internal and external WSRP suppliers.

The WSRP-specification says nothing about the implementation of the portlet, it defines its interface. This is where WSRP connects to Java's portlet specification, JSR 168, and Microsoft’s Web parts. WSRP is not a competing technology, it’s more like complementary. JSR 168/Web parts are used to define the portlet whereas WSRP is used to define the portlets appearance in a remote portlet container (like a web portal app).

Experiences of WSRP

WSRP has some limitations when it comes to complex web applications with advanced user interfaces (interactivity, design). These limitations are:

• Separation and handling of presentation/design and the use of Cascading Style Sheets.
• Handling of DOCTYPE making accessibility /WAI-adoption harder
• A WSRP-portlet knows nothing about its content. The content and design of a WSRP portlet may look different from the rest of the web page it is appearing in.

How to think

If You have a ”pure” Java or .NET –miljö without any needs to remotely distribute portlets, then You develop directly in JSR168 or Web parts. No need for WSRP.

The advantages of WSRP are obvious, it can easily be used in any portal application without local installation, but what are the downsides?

• Consider if You can live with the limitations described above.
• The extra development work to add the WSRP-interface to Your portletspå dina portlets.
• Code running locally (JSR168 and Web parts) generally runs faster than remotely run code. There is overhead in the Web service calls.
• Code running locally has access to more information about the execution environment, both the hardware to execute on and the web page to appear in. Using that information, the portlet can act smarter. Communication with other portlets are easier if you know what other portlets that surrounds You.

One smart way of setting up a WSRP-enabled system architecture is to use a “portal UI staging tier”:

The plan here is to develop WSRP producer portlets either in in Java or .NET. Render them in a web portal application using a thin layer of portal specific code (for instance a JSR168 or Web part). This is a SOA-friendly architecture, easy to deploy and modify, that also scales well.

© Copyright 2007, Tomas Elfving

BEA turns down Oracle bid

It appears my guest appearance as IT business analyst wasn't completely out-of-line as BEA on Friday turned down Oracle $6,7 billion bid, saying it seriously undervalued the company. Now I'm only waiting for HP to make its move ;-)

© Copyright 2007, Tomas Elfving

Wouldn't HP be better for BEA than Oracle?

I generally don’t comment on IT business acquisitions and business events but this one has implications on the entire application/portal-server market, so I feel it is time for an exception ;-).

The backgroud is Oracle’s recent bid to aquire BEA Systems.

Oracle feels they needs to fill out its product portfolio by acquiring BEA, but will the acquisition bid be successful? Oracle will be faced with a great deal of redundancy in the product range, and as fierce as the competition in that portal servers market is, it is hard to believe that any player has the resources to R&D more than one portal server platform.

Futhermore, It won't be easy to convince BEA's customer base that Oracle only has their best interests at heart. BEA is a serious competitor to Oracle, with some fine technology that is making it difficult for Oracle to become dominant in the middleware space - so BEA has to go whatever the consequences.

BEA has made it clear that being acquired by Oracle is not foremost in its business plan, but Oracle several times has shown its ability aquire companies against their will. It therefore looks likely that BEA will ultimately be acquired - but not necessarily by Oracle. BEA has a strong product set, but would benefit from the additional financial stability of being acquired by a large IT vendor. If not Oracle, then which other vendors might join in the chase?

IBM would be the most obvious competition for Oracle, and it has also been very active on the acquisition trail recently. However, the same issue of product set overlap would make this equally unwelcome to BEA's customers and board.

However, BEA has been very successful in partnering with HP, and since HP abandoned its service-oriented architecture (SOA) platform foray (which it entered through the earlier acquisition of Bluestone) the two product sets have become extremely complementary. HP has waded into the SOA management and governance market through the acquisition of Mercury, but has steered clear of providing its own SOA platform. The combination of HP and BEA, if executed well, would create a significant force in the industry and a natural balance to the otherwise dominant IBM and Oracle.

If BEA should happen to survive the onslaught by Oracle, it would certainly be weakened by the experience and will probably see its market share slip. This would not be good for customers, shareholders or employees, and would probably lead to a further acquisition attempt (by Oracle or others) being ultimately successful. Now might be a better time for BEA to seek a friendly acquisition by a vendor looking for something more positive than simply to trash the competition.

© Copyright 2007, Tomas Elfving

Popfly, an enterprise-ready environment for end-user-driven mashups?

Popfly features programmable blocks using JavaScript is at the moment not very integrated with the .NET framework-based technologies. Popfly is an example of evolving technologies that exploit the power of combining mashups and Web 2.0.

Initially, the Popfly environment will mostly target public Web users, but it has the potential to become an enterprise-ready environment for end-user-driven mashups. By “Enterprise ready”, I mean that the Popfly environment and block portfolio is managed as an enterprise repository containing assets to enable end-user composite application building. The potential benefits are compelling and with Popfly, Microsoft joins product such as Yahoo (Pipes), IBM (QEDwiki), Oracle (WebCenter) and BEA Systems (Aqualogic Ensemble) in the mashup tool market.

Popfly is primarily interesting in two ways:

1. The Silverlight-based user interface is powerful, engaging, and sufficiently easy to use that non-developer users can get involved in building composite applications. Users make mashup applications by usings the build-in blocks library, or build their own blocks. These blocks can be service-oriented architecture (SOA) services. The blocks may include visualization service blocks or data service blocks, and the application can also demonstrate a block that handles transformation between two other blocks. Popfly goes far beyond dropping a gadget into a Web portal.
2. Popfly is also a mashup Web 2.0 community, applying the "network effect" to the mashup world. A user-driven mashup composite application environment is only as valuable as the quality and quantity of services (or blocks) available to users. Users can think of the Popfly community as a "programmable Web" that allows developers and nondevelopers to easily find, consume, create, rate, sell and share blocks and mashups. Popfly's success on the public Web will depend on Microsoft's ability to engage and develop this community.

© Copyright 2007, Tomas Elfving

Popfly now in public beta

Microsoft is now done ironing out the bugs and feedback gathered during the invited-only alpha release period. Now anyone with a Live ID can start a Popfly account and start being creative.

Microsoft® Popfly™ is a web site and tool to help people create and share web sites, mashups, and other kinds of experiences. It has two parts: the social network ("Popfly Space") and the online tool for creating different mashups and web sites ("Popfly Creator."). In addition to the Popfly web site, Microsoft® Popfly™ Explorer Beta is an add-on component for Microsoft Visual Studio® 2005 that enables you to create and share Visual Studio® projects on the Popfly Space network.

The list of added features of the beta can be summarized as follows:

• Gadgets. Popfly can create both Windows Vista Sidebar gadgets and Windows Live gadgets.
• Tweaking and Properties. Last iteration, we added “tweaking,” but many blocks didn’t have a lot of properties to tweak, so we added properties to a host of our output blocks including Photoshow, Virtual Earth, PhotoSphere, Gauge, and Page Turner.
• Tweaking and the color picker. When you tweak a mashup you now have a color picker so you don’t have to remember the alphanumeric codes for colors.
• New and updated blocks. Popfly has a category for new and updated blocks.
• New screencasts. Updated videos explaining how to use Popfly.
• New blocks.
  
• Updated block documentation.

Finally, check out the release notes before you get started!

© Copyright 2007, Tomas Elfving