Oracle has released an early version of a new toolkit that allows you to build portlets which adhere to the two recently completed Java portal and Web services standards, JSR 168 and Web Services Remote Portlets (WSRP). The preview contains both a portlet container, and a plugin for Oracle's JDeveloper for constructing portlets.

Read: Oracle readies portal-building tools

View the press release: Oracle Application Server Supports Latest Industry Portlet Standards With New Tools

http://portalstudio.oracle.com

No Oracle. Memories hurts. O9iAS 9.0.2 on SuSE Linux server almost killed me. Only reason to release it was to sell support for this crap.

I can respect your opinion, since it surely is no walk in the park to install 9iAS. On the other hand, once you get it installed & configured properly (this IS possible, without the help of support) iAS offers quite a nice set of functionality.

I thought Linux would be the most stable platform for Oracle Portal. Then I am mistaken. We are not able to run Portal 9.0.2 with Discoverer option successfully on our HP-UX server after two months of neverending restarts, 4 TARs, several days of Oracle specialists installing over 1GB patches on our site.

Once you get it installed & configured properly...wait for the judgement day.

I would be interested in hearing from people who have used Oracle's Portlet/Portal implementations. How does it compare to other implementations? What was good and what was bad about it? Why would one choose to use Oracle's implementation as opposed to WebSphere's, BEA's, Sun's or even an open source implementation like UPortal or JetSpeed?

We are considering Oracle's implementation for a project and looking at other implementations as well.

Are you kidding?

Considering an Oracle offering out of the database product is not wise. Don't just take my word for it. Check out Oracle's technical message boards and see how people are having all kinds of problems. I still have nightmares about trying to un-install Oracle9iAS Portal and the rest of the jars lying around. Check out Oracle's response to this problem, my solution was fdisk.

I didn't get this experience with Oracle by choice. This non-technical technical manager decided to use Oracle9iAS and my number was up. Also, I had to suffer through Oracle's propaganda about how Oracle9iAS could replace Weblogic easily. Yes, I did convert Weblogic to Oracle9iAS, but only after I deleted 90% of J2EE EJB 2.0 code!

What ever happened to that Oracle replace Weblogic promotion?

-- do you like dogs?
-- NO!
-- well, you have to cook them properly!

AV

Please no! WSRP is one of the worst and most volatile ideas I have ever encountered. It reminds me of the totally knotted and cluttered integration scenarios I have seen in recent years. Hey, let's pull together a number of portlets that reside on a number of different servers in our intranet/extranet/website. All residing in different departments, with different uptimes, different SLAs, different security infrastructure, different L&F (yes its actually part of the portlet, not of the client), unpredictable latencies, insecure communication paths etc. etc. etc.

On the other hand WSRP is a *very* good incentive for getting an flexible single sign on framework, including sophisticated credential mapping accross the board, employing message level security and routing in SOAP etc. - All to show a portlets - Now really!

Hello Karl,

This is the point ! Portals wants to be able to integrate content/application from all over your network. The portlet will be able to be hosted where the application is ! OracleAS Portal for example uses remote portlet for more than 3 years now, and customers have the choice to select where they put the portlet:
 - with the Portal Framework
 - or with the application that you habe to 'portletize'.

WSRP gives flexibility on the topology of your portal, the SLA management will depend of the quality of the Portal framework to manage the different 'problems' that could be encountered (server down, portlet to slow, ...), Also WSRP will allows for example a Java Portal to consume portlets developped in another technology such as .Net, and this without any modification of the code.

About the look and feel, yes a portlet developer can code anything he wants in in the renderer, but the JSR-168 provide to developer a set of common list of styles that will enforce the consistency.

If you're in a company that has this many different sources of WSRP portlets and you have multiple different sign-on technologies and can't keep your servers up on a regular basis then I believe you have much bigger problems on your hands.

Anything that's critical that can't withstand the occasional "portlet is not available message" or "portlet timed out" message really shouldn't be on a departmental server without official operational support and the resources they require to insure that it stays up.

L&F is addressed in WSRP, although it does need improvement. That is being addressed in future versions of the standard.

> servers up on a regular basis then I believe you have much bigger problems on > your hands.

So what? Will this keep a company from using the "cool new WSRP" technology? Of course not. Are all servers in any large company "kept up on a regular basis"? No, they are not.
 
> Anything that's critical that can't withstand the occasional "portlet is
> not available message" or "portlet timed out" message really shouldn't be on > a departmental server without official operational support and the resources > they require to insure that it stays up.

Absolutely. And that's why WSRP is a stupid idea in the first place. You don't deploy a technology where your support efforts outrun your savings by far. What good is that? What's so wrong with providing a library. Even now, projects are barely able to understand what SLA they can offer, because they depend on the corporate LDAP, any number of databases and a couple of mainframes all with totally different availibility and run time characteristics.

> L&F is addressed in WSRP, although it does need improvement.
> That is being addressed in future versions of the standard.

Right, if I read something like "is addressed in future versions" I get a bit wound up. How about "it might be". And something being addressed is nice, but I want it to be *resolved* if anything.