The Way Business Is Moving published by
Issue Date: April 2007

BEA WebLogic hops on Web 2.0 bandwagon

18 April 2007
Tony Baer

BEA's newest version of its Java-based WebLogic Portal is designed to change itself from a passive to active tool. New Ajax capabilities that can be manipulated by the end user could make the portal not just a consumer of mashups, but a maker of them.
WebLogic Portal is one of two such products in BEA's portfolio. Alongside this Java-based offering is a more Microsoft-friendly offering, AquaLogic User Interaction, which came from the Plumtree acquisition.
The new WebLogic Portal 10 version upgrades Ajax support. Before, isolated JavaScript objects on a portlet web page could have updated themselves individually. Then the new version allows the whole page to update bunches of JavaScript objects without the dreaded page refresh.
It also adds the option for individual JavaScript objects on the page to update each other without having to roundtrip back to the server. So, for instance, with the classic Google Map mashup where you want to superimpose addresses on the map, you can do that locally on the client or roundtrip it to the server, both in standard Ajax style fashion (without the complete page refresh).
The active feature being added is that WebLogic Portal can publish these mashups on a URL for other apps to share. That is a reversal of role of sort for the portal, which usually consumes other applications (or portions of them). In this case, the idea is turned on its head, based on the value proposition that the portal is one of the places where information comes together. So why not let that mashup be re-used?
But the new feature of sharing what WebLogic Portal mashes up will only be useful if you know that the mashup has been published and the URL where it is available. There is now push, pubsub, or other kind of syndication feature included.
Another new bell and whistle of WebLogic Portal 10 is support of the latest 2.0 version of WSRP (Web services for remote portlets). That is an Oasis standard for standard APIs for portlets that are published, not on the portal server, but elsewhere. This way they can be requested as a web service.
Previously, WebLogic Portal supported the initial version of WSRP, which specified the interface. By contrast, WSRP 2.0 adds the ability for remote portlets to communicate with each other. So, using that same Google Maps example, if a Google Map is exposed as a web service on one server, while a list of client addresses is a portlet service that is published on another, the address portlet can now talk to the map portlet and generate the mashup.
Admittedly, with all major portal providers (save Microsoft) supporting WSRP, BEA wil not be the only one to offer this feature. Theoretically, with WSRP, WebLogic Portal could conceivably consume or aggregate a portlet from other platforms like IBM WebSphere or SDAOP NetWeaver, although proof will be in the details.
Finally, BEA is adding a little bit more REST support to its portals. REST is a lighter weight alternative style for requesting services that involve interacting with a database. It is considered a simpler alternative to placing the request through a SOAP message. In WebLogic Portal 10, you can now use REST 'Get:' statements, but at this point, you cannot do the other kinds of Rest 'CRUD' (create/read/update/delete) tasks. BEA says it may add these later.
Our view
It is not surprising that BEA is upping the Web 2.0 content on its portal. And in fact BEA will not be the only doing so, although its technology for sharing portlets and enabling them to shake hands with one another is, for the moment, innovative.
The challenge is that portals have been considered rather static platforms, especially since developers have seized on relatively simplistic Ajax-style programming techniques to take the law into their own hands.
The challenge is not exclusive to BEA, but to the idea of portals. Portals traditionally were supposed to provide one-to-many views of enterprise assets that could be tailored to a specific end user, under the full control of any end user access and authorisation policies that have been enforced from above.
Conversely, Ajax-style mashups have provided less formal tooling, methodology, and governance to replicating one-to-many displays, often on the same HTML screen. If the asset is represented on some intranet web page as a JavaScript object, it becomes fair game for somebody to mash it up without having to go through the portal bureaucracy.
But with unfettered access something that is definitely not cool in an age of SOX, portal providers are finding themselves under pressure to ease barriers to development to make themselves more popular collaborative platforms.

Others who read this also read these articles

Search Site


Previous Issues