In this new TechTalk on BEA's dev2dev portal, Nils Gilman explains what the portal market is all about, how it evolved, what portals are, and future key directions such as the possibility of federated architectures with Web Services Remote Portlets (WSRP). Nils explains the two main differentiators of BEA's own WebLogic Portal and provides clear insight into why to use a portal product versus rolling out your own.

Watch Developing Portal Applications.

I'm just going to echo Nils here and say that WSRP is going to be a very critical portal technology soon. Most of our medium/large clients are very much looking forward to use it, for a variety of reasons, including those which Nils mentioned.

Wow, it's amazing how marketing folks can talk a lot but really say very little of substance. They remind me of politicians.

For question 7, the interviewer asks Nils how BEA differentiates itself from other portal vendors. The summary of it is: BEA has portal lifecycle management and allows developers to use BEA Workshop to develop portlets.

I don't believe the former is true. WebSphere has good lifecycle management too (correct me if I'm wrong).

Nils mentions BEA Workshop because it will allow less experienced developers to code in GUIs/templates. I don't see that as a good differentiator, that would be like saying, WebSphere's big differentiator is that you can use WebSphere's developer tool to develop for WebSphere Portal, duh.

What really differentiates BEA Portal from other portals is that it's TIED to BEA WebLogic.

I would recommend looking at some of the open source solutions out there before spending big bucks on a portal. You'll have to navigate the marketing mumbo jumbo and really dig into architecture and functionality.

Here are some I recommend:

Jetspeed: great product by Apache (www.apache.org)

eXo: great product from the guys at Objectweb (www.objectweb.org)

Liferay: I'm the architect of this one, so my views are slightly biased (for example, it's my favorite :), (www.liferay.com)

- Brian Chan

Wow, it's amazing how marketing folks can talk a lot but really say very little of substance.

That is their JOB!

I recommend:Jetspeed: great product by Apache (www.apache.org)eXo: great product from the guys at Objectweb (www.objectweb.org)Liferay: I'm the architect of this one, so my views are slightly biased (for example, it's my favorite :), (www.liferay.com)- Brian Chan

There are cases when main driver for a portal solution is not user's ability to customize pages, but ‘component’ structure of a portal.
Would it be easier to build such “portal” with non-portlet component technologies like Tapestry, Echo, etc.?
Did somebody try that? Ready to share experience?
IMO Tapestry components would make a great portal technology but Tapestry seems lacking ‘lifecycle’ if it allowed deploying libraries into working application it would be killer ‘portal’ application.
Any thoughts, opinions?

Well, the way I look at it is, in some ways, portals are like any other technology. We'll compare it to EJBs for example.

EJBs are: heavy, good in some cases, unnecessary complexity in other cases, and can be used better by using something lighter like Spring or just straight java classes.

In the same way:

Portals are "heavier" than just using a struts framework. Some ppl even advocate just using straight iframes.

The benefit of portals over tapestry and other servlet frameworks is that portals provide the accumulation of multiple applications in one place.

If you want to buy an off the shelf JSR-168 portlet and plug it into your portal, you can. But if this isn't a requirement, then portals may be unnecessary.

So, choose a portal if:

1. You need customization

2. You want to leverage portlet security

3. You want to buy portlets to drop into the future

4. You want to expose your portlets to other portlets via WSRP

5. You want multiple applications sitting on one page, but want better performance that comes from caching the render requests vs action requests (this is a bit complicated, but once you develop for portlets, you see the beauty of the spec in this area)

6. You want to leverage an existing portal's built in portlets (like Liferay's blogs, wiki, email, user/role/group management, message boards, calendar, polls, CMS, etc.)

You can even see some portals as an added layer on top of some frameworks.

For example, using Liferay, you automatically get Spring and Struts because Liferay is built on top of Spring and Struts. So you get all of Spring's AOP/IOC advantages, the ease of Struts (since most companies know Struts - less retraining). This is from an architecture standpoint. Your developers develop in small hot deployed wars, cleanly separated from each other.

From a functionality standpoint, you also get the security management plus all the other built in portlets.

After 1 year of working with BEA portal, tons of money wasted on Workshop and Portal training, and two excruciatingly problematic production launches, I would never recommend BEA portal to anyone. I work for a fortune 500 company, and I touch A LOT of enterprise technologies. Let me tell you that BEA portal development is painfully slow. For portal to work, you need at LEAST 1.5Gig of memory, and that is for the basic deployment. Once we had the application deployed, the startup took about 15 min. This made the roundtrip development incredibly painful, especially in a team environment with deadlines to meet. The run-time mapping of portal entitlements is different than from the one used in Workshop, which caused a lot of confusion going from DEV to PROD. There are tons of little snags in the IDE, as well, which caused a lot of my developers and testers to loose their hair in bushels. For instance, their code is error free, but does not get deployed properly for reasons unknown to man. So you have to add a "space" at the end of the source code and save (This comes from the BEA consultants, who hate us now). Then, for no apparent reason, you have to rebuild and redeploy the entire app, and then it magically starts working. The framework is bulky and the overhead of EJB's deployed in the portal is immense.
The out-of-the box portal has no default basic portal to build and expand off of. You have to develop everything yourself from scratch.
After all the pain, missed deadlines, and wasted nights in the datacenter, I would NEVER EVER suggest BEA portal to anyone with a sane mind. I'd say, stick with a lightweight container, like Spring, and Velocity or Tapestry. They are easy to use, very simple to implement and work predictibly every time.

So you have to add a "space" at the end of the source code and save

Funny that you said that, I remember adding newline at the end of the classes for them to be compiled. But if I remember correctly, these files cannot be chewed by javac, not by Weblogic tools.

Have you ever looked at Liferay?

Liferay on Tomcat boots up pretty fast (around 10 seconds). It has useful portlets to build off of as well. It's also built off of Spring and has Velocity based portlets.

Have you ever looked at Liferay?Liferay on Tomcat boots up pretty fast (around 10 seconds). It has useful portlets to build off of as well. It's also built off of Spring and has Velocity based portlets.

Yes I have, and it is awesome, In fact, I looked at all opensource portals you've mentioned in your post, and I found LifeRay the most mature.. Ramp-up is quick and it is well documented. The only problem I have is that I need more options to customize user properties. BEA has the concept of portlet preferences where I can easily define variables on a user basis in the code. I didn't have the time to dive into it in your product, but it is easy to create, persist and extend custom user profiles in BEA Portal without touching the DB schema manually. I wish you had some basic workflow and maybe some sort group collaboration built-in. Then it would be perfect for what we are doing. BEA WLI is what we are using, and that is actually pretty good.

Thanks for the input.

Some of the Liferay deployments for our clients included integration with JBPM. We've been given the code and will integrate some workflow engine in the coming releases.

The DB schema is definitely a feature Liferay lacks. We'll look to add that as well. Thanks again!

Brian, a couple of Liferay-speciic questions:

1.)Long-term, why maintain both the EJB and non-EJB versions? Even if much of the business logic is in POJOs, this surely requires some duplication. A non-EJB version will work anywhere. Is this separation permanent,or merely a transition to a non-EJB product?

2.)Liferay claims to support use as an ASP. However, I remember when I looked into this, over a year ago, each time a new client was added, the server had to be rebooted. Is that still the case?

Mike

1.) Maintaining an EJB and non EJB version for us is actually very easy.

We use Spring's dynamic proxies + code generation so maintenance is trivial. For example, to use the EJB version, set portal.release=enterprise in the props, or portal.release=professional

We use a Factory that will pick either the pojo impl, or the ejb wrapper that calls the pojo impl, based on the release property.

We do this because some of our clients require a specific EJB server: either scalability, legacy, or some political reason.

The pojo version currently lacks tx. The EJB version, though heavier, comes with all of the EJB benefits as well.

This way, you can test in tomcat, and deploy in jboss+tomcat. (tomcat boots up in about 10 seconds, jboss+tomcat takes a lot longer). It just makes things more flexibile.

2.) We do have the ASP feature, unfortunately, you still need to reboot. This is mainly due to the fact that hot deploying virtual hosts in JBoss or Orion (the two versions I test ASP for) never works right.

Brian,

The pojo version currently lacks tx.

It should be straightforward to add Spring declarative transactions: Simply define a Spring TransactionProxyFactoryBean for each facade that you also have an EJB version for.

This will give you equivalent transactional behavior, even with more fine-tuning options than EJB CMT (for example, per-transaction isolation level, read-only optimization, rollback rules for exceptions).

Juergen

Yes, we're planning on modifying the XML to give our spring ejbless version tx capabilities as well. Spring is definitely a good framework I'm happy to build ontop off.

I can second Marc's experience with BEA Portal. I worked also on a project using BEA Portal and Workshop and its just horrible. The company is also a fortune 500.

The performance is damm damm slow. I once used p6spy to see the database activity in BEA Portal Admin since it was dog slow. It used 80-100 SQL statements just to expand a node.

Roundtrips to restart BEA WebLogic server with portal is about 2-5 min. on a 1gb 2ghz PC. And recompiling is also 3-5 min, and the damm ant tasks that does the compiling doesn't support incremental compiling so you were forced to recompile everything even if you just have touched one single .java file. A lot of the time you had to restart the server since hot-deployment in a J2EE environment is troublesome.

As for enterprise ready the BEA products isn't quite there yet. Their propagation tool that is to be used to propogate portal data from TEST -> PRE-PROD -> PROD isn't working correclty and will only be fixed in BEA Portal 9.

And theire is toons of problem with the portal framework itself. Just to have two portlets to do inter communication is troublesome.

I haved worked many years with BEA products and it's only their pure BEA WebLogic server I can recommend. The rest is sh*te.

I second Marc's opinion of BEA Portal. I am working on a project right now using BEA Portal. It is by far the WORST platform I’ve ever worked on. The Workshop IDE is terrible; I frequently have to shut it down to delete temp files in order to complete builds, and it seems that after several hours of use it becomes nearly unresponsive. The IDE and the App Server are both resource hogs, to the tune of about 800 MB with both running. I can run Eclipse and JBoss together in a footprint of 250 MB on the same machine. Also, the Portal tag library is very buggy and unclean. PageFlows (JPFs) are also a pain... they should have left it at Struts. (Jakarta Struts works!)

Yes I remember that problem as well - the need to delete certain temp files/folders to make Workshop run again/compile.

Yes I remember that problem as well - the need to delete certain temp files/folders to make Workshop run again/compile.

I'd like to second that. We have a script that cleans all the temp files generated by workshop as is puts them in both the directory where the project is (.workshop) and in several other temp directories.

Let me tell you that BEA portal development is painfully slow. For portal to work, you need at LEAST 1.5Gig of memory, and that is for the basic deployment. Once we had the application deployed, the startup took about 15 min. This made the roundtrip development incredibly painful, especially in a team environment with deadlines to meet.

I totally agree. Workshop may be quite a good tool for quickly developing simple page flows. However, when you need to write code it is very poor tool (and while there are many wizards in Workshop, you still have to write a lot of code). We have a small team of experienced J2EE developers familiar with practices like TDD and refactoring. Workshop does not support these features at all. Therefore we have to use Eclipse and Workshop side by side and copy files between them continuosly.

You gripes appear to be with workshop and not portal itself. Portal (by itself) does not require you to use workshop. You can use any IDE. The only thing portal shares with workshop are a set of XML files.

Also, unlike other portals, BEA’s portal supports many different types of applications not just JSR168. Struts, JSPs, Pageflows, WSRP, Web Services. You can develop these applications in you favorite environment and then just consume them in portal with no modifications.

Also, unlike other portals, BEA’s portal supports many different types of applications not just JSR168. Struts, JSPs, Pageflows, WSRP, Web Services. You can develop these applications in you favorite environment and then just consume them in portal with no modifications.

"Unlike other portals"... gimme a break. We can do that too and it wasn't exactly rocket science to implement. Either you can wrap your non-168 apps in a 168-portlet, or simply use some kind of proxy or iframe solution. Works pretty well.

Either you can wrap your non-168 apps in a 168-portlet, or simply use some kind of proxy or iframe solution.

I'm not talking about wrapping. and iframes don't maintain state once you refresh the portal. I'm talking about taking and existing struts application and placing it on a portal page and have it work as is.

I'm talking about taking and existing struts application and placing it on a portal page and have it work as is.

Interesting, because that's not what the Weblogic Portal 8.1 online docs say about the Struts integration. Are you saying they are wrong? Maybe they should be fixed then.

What docs are you looking at

http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html

BEA portal integrates PageFlow and Struts apps that run inside the portal. It supports full URL rewriting so the application runs inside the portlet not popping up a new window or having to use iframes . These apps can also be exposed as WSRP portlets (no portal license required on producer)

Brian,

Is there an install script for liferay on WebSphere (yet)?

Gordon

Yes, we finally put up the websphere install docs. Sorry for the inconvenience. Here it is.

http://www.liferay.com/documentation/installation/websphere.jsp

I'm curious to here fellow readers reasons for developing portals. Perhaps a definition of a portal would also be helpful.

I'm curious to here fellow readers reasons for developing portals. Perhaps a definition of a portal would also be helpful.

My understanding of a portal is that it's a "single place" that acts as a medium to which multiple applications converge.

A de facto example of the classic "portal" is something like "My Yahoo", where you have little blocks of functionality and the users can add/remove blocks, move them around, and basically let's them pick and choose from the available applications and how they're presented.

Now, certainly, "My Yahoo" has a bunch of fairly trivial applications, but a lot of little applications can be trivial yet offer high value.

I've never worked on a "corporate" portal, and I personally have little need for one where we work. But the portal concept is quite nice, and if you can work with the boundaries of something like portlets, it makes for a very modular and customizable site.

Here's my take on portals:

A portal is way of having multiple, isolated views aggregated in one view with "at-the-glass" integration between them.

Now, after having just taken some training, here's some of the things I see you can get from JSR-168, or vendor flavors:

1. Multiple disparate views aggregated into one view
2. At-the-glass integration
3. 2-phase handling (action, rendering)
4. i18n
5. customization
6. personalization
7. loosely coupled services
8. security
9. out-of-the-box portlets
10. plugability with third-party portlets

Now, some of those things have to do with my original definition, and some don't. In fact, some of these would be nice to have regardless of portlets! (2-phase handling, personalization). Others we actually already have (i18n, security, etc.)

Why did Sun/vendors choose to cram this all in portlets? Why not go back and enhance the servelt API (and by extension, JSPs) to support the cool stuff and just let portlets be view aggregators with view communication?

And, on a final note -- I question the usefulness of having two views aggregated in a single web page. Why not show only one view at a time and pick which one to view? If you really need both side by side, why not use iframes, or two windows? The web page as a UI sucks enough as it is.

And SSO.

And SSO.

Agreed. And SSO is another one of thoise things that is uiseful even without a portal.

Sun JSR 168 - Portlet Specification, defines a Portal as:

"A portal is a web based application that -commonly- provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users."

Why use a Portal framework and not just Struts, Spring or Webwoks MVC?

Well, if your website is a collection of severl modules/portlets (news, calendar, CMS etc.) and you have to bring them togethe and have some reusability on the portlets level - you NEED to develop your site as a Portal.

If you are just writing one application (hardly ever possible, though) - you do not need to burden yourself with doing it Portal way

Well, if your website is a collection of severl modules/portlets (news, calendar, CMS etc.) and you have to bring them togethe and have some reusability on the portlets level - you NEED to develop your site as a Portal.If you are just writing one application (hardly ever possible, though) - you do not need to burden yourself with doing it Portal way

I'm not sure I agree, with one caveat (being that you mentioned portlet's explicitly).

Suppose I do want a calendar, a content management system and news. Why does it have to be a portal? First of all, if I want them on one page, I don't even have to use portlets. I could use iframes. And this could be accomplished quite simply. On the other hand, inter-poertlet communicationw ould be trickier (and I think that is one of the key values of portals).

But I might not even need them on one page. Generally, people wan tto multi-task. Start adding a calendar entry, but then answeer a chat. Are you looking at the calendar entry when you're chatting? More than likely not. So, make them on separate pages, but remember state inbetween.

Like I said elsewhere in this discussion, a lot of what a portal/portlets offer is enticing (i18n, customization, sso), but you don't have to aggregate that content all on one page for that.

Well, if your website is a collection of severl modules/portlets (news, calendar, CMS etc.) and you have to bring them togethe and have some reusability on the portlets level

Yes

- you NEED to develop your site as a Portal.If you are just writing one application (hardly ever possible, though) - you do not need to burden yourself with doing it Portal way

Why so? Why do you consider portlet to be the best component/module specification out there?

Tapestry component(as a library) seems more natural and straightforward thing than a portlet.

Not to mention really nice Delphi components I used to enjoy when developed for desktop. Hell, even real JavaBean is a joy to deal with when compared to portlets and their containers.
my 2c

Why so? Why do you consider portlet to be the best component/module specification out there?Tapestry component(as a library) seems more natural and straightforward thing than a portlet.

Because, bringing modules together means some kind of integration between them (most commonly on the user authentiction, user session and UI layers). When I say a Portal software - I mean a framework that does it in a non-code-duplicated way, central way and thus facilitates the modules.

For me "Portal" = best practice in the integration of modules that build up a website. Sun or JCP do not have monopoly on this term, or should not have even on the term "Portlet", for that matter. When I mentioned Portlet I said it like "module/portlet" implying that I do not necessarily mean JSR-168 compliant portlets.

I do have some problems with JSR-168 and consider it as good as EJB was in ver 1.0 which means - far from perfect :) By the way - problems those two try to solve, are quite similiar, too. EJB was, also, designed to provide reusable, self-contained components for the Enterprise java development.

EJB has only begun showing signs of getting more "human" in ver 3.0 and largely due to the wise decision of adopting best practices from Hibernate. Something similiar will happen with Portlets and Portals, too, I am sure.

That said - there definitely are best-practice patterns in how to build multi-component systems/websites in the easiest, most reusable way and whether current specifications capture that best-practice or not, the need to standardize and not create ad-hoc systems is obvious... well, IMHO, at l east.

Returning to the original topic - statement that JSR-168 is not perfect, actually, proves what I try to claim, too - Portal theory is far from being mature, leave alone perfect, so efforts to make it better are not in vain, and we should not, all, just begin using BEA Portal software :)

Off topic but anyone has a good recommendation
for C# based ASP.NET solution ?

Thanks
Ricky

The Rainbow Open Source Project
http://www.rainbowportal.net/

We have .NETnuke Open Source Project
http://www.dotnetnuke.com/

We have Microsoft flagship product SharePoint Portal Server, more sold than any commercial Java Portal product.

SharePoint to be a US $400M Product for Microsoft: Joel Spolsky says that nobody has SharePoint. Au contraire, mon ami. According to public comments made by Steve Ballmer, SharePoint is on track to be a $400M product for Microsoft, and one of the fastest products ever to get to that point for the company. Here's a fun experiment to try: Go to your favorite jobs site (mine is Monster) and do a search on the term "SharePoint". Then do the same thing with "WebLogic Portal", and then "Plumtree" (two other major portal software developers). See how many jobs come back looking for skills in each.

When I did this yesterday, SharePoint resulted in 448 hits. WebLogic Portal got 227, and Plumtree got 130. Now, which product should you be honing your skills on?.

http://www.joemarini.com/articles/sharepoint20041115.php

Personally I rather use Windows SharePoint Services which can do most of the things the full SharePoint Portal Server can do and more flexible, without costing anything (bundled with Windows 2004 Server).

Regards
Rolf Tollerud

Windows 2003 Server of course.

Windows 2003 Server of course.

http://www.theinquirer.net/?article=20817

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

ha ha, why don't you read through Linux security advisory archive at: http://www.linuxsecurity.com/content/blogcategory/0/76/

They carry considerable more credit than your "idealistic and radical" Open Source organization, that probably spends more time writing windows-attacks than doing real work. (occasionally they attack Unix though:Growth of radicalism within Open Source - SCO under attack)

State of Linux Security 2004
http://www.linuxsecurity.com/content/view/117655/49/

In 2004, security continued to be a major concern. The beginning of the year was plagued with several kernel flaws and Linux vendor advisories continue to be released at an ever-increasing rate..

(in January) started off on shaky ground with a flaw found in mremap(), a piece of kernel code that controls virtual memory. It affected versions 2.2, 2.4, and 2.6..

(in February), a second mremap vulnerability was discovered by the Polish security consulting firm ISec..

The remaining portion of the year was scattered with other kernel vulnerabilities..

The volume of press generated by (Linux) kernel vulnerabilities is ever increasing..

For example, 35 Linux vendor security advisories were released last week alone..

Don't forget to read the paragraph "Linux Vulnerabilities", a masterpiece of squirming excuses.

With utmost respect
Rolf Tollerud

Don't forget to read the paragraph "Linux Vulnerabilities", a masterpiece of squirming excuses.

Rolf, I love Windows as much as the next secretary, and I refuse to use anything else, but even you can't suggest to use it as a server after you read this:

According to data from the Symantec Deepsight Threat Management System Win32 servers in similar situations have a life expectancy of a few hours.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

I could say "how come I have had my own computer constantly connected to internet the last three years without the slightest problem?" But I won't bother. Someday you will learn that exaggerations only defeat their purpose. Also we can not pollute every thread here at TSS.

Meanwhile don't you try out Sharepoint so when you are getting old you can say that at least one time in your life you had experienced real software?

Regards
Rolf Tollerud
(Enjoy your 35 security breaches per month)

I could say "how come I have had my own computer constantly connected to internet the last three years without the slightest problem?" But I won't bother.

Rolf, you have to be the best Russian Roulette player ever!

Meanwhile don't you try out Sharepoint so when you are getting old you can say that at least one time in your life you had experienced real software?

Maybe he doesn't want to waste $30k. Yeah there are some goodthings about it. But many more painful things.

Mark, please read more carefully, didn't I say I prefer Windows Server 2003 SharePoint Services that is gratis? Or you can download SharePoint Portal Server for a 30 days trial.

>i>"were impressed especially of all of the stuff that comes with"

What have Liferay in the way of intrinsic document-management? After all the most important with a portal…

What have Liferay in the way of "Infopath/Sharepoint store" integration?

I agree with you that Liferay is a nice little product, but let us set the proportions here. Sharepoint have at least a 1000 timed more money and resources behind it.

Regards
Rolf Tollerud

Mark, please read more carefully, didn't I say I prefer Windows Server 2003 SharePoint Services that is gratis?

You told him try Sharepoint. I know you prefer Sharepoint Services. Can't be the same otherwise no one would pay $30k for Sharepoint.

Or you can download SharePoint Portal Server for a 30 days trial.

Trying out Sharepoint will take more than 30 days.

I agree with you that Liferay is a nice little product, but let us set the proportions here. Sharepoint have at least a 1000 timed more money and resources behind it.

Well, since Liferay conforms to the porlet jsr, it has the backing of all who develop for it. Who really cares how much money is behind it and who supports it if one can't afford it (at least right now)? From what I have seen, Brian is much more responsive to requests and support than Microsoft is. That is worth much more then billions of dollars. Plus it just works.

What have Liferay in the way of intrinsic document-management? After all the most important with a portal…

If is doesn't have it, I am sure it can be built/aquired for less than the cost of Sharepoint.

What have Liferay in the way of "Infopath/Sharepoint store" integration?

What does Sharepoint have in the way of multiplatform support and vendor choice? Why does a J2EE product have to integrate with a closed/single platform? Especially when it is the platform J2EE is replacing. Choose better tools.

What shall I say? What you are saying is equivalent to saying that the earth is flat and that people never have been to the moon. There is a name for it; it is called "blåneka" in my language: "flat denial". It is the same as when your wife comes home and finds you in bed with another woman, the best policy to choose is to deny it all, "no we didn't have sex", and stick to it through thick and thin.

But, as it is written, "father, forgive them because they don't know what they do". You have never seen the Microsoft power-users contribute to the population of unemployed programmers by utilizing Infopath XML tool with Sharepoint store and document management.

The question just is, how much longer shall the Java/Unix camp go through life with bindles before their eyes?

Regards
Rolf Tollerud

What shall I say? What you are saying is equivalent to saying that the earth is flat and that people never have been to the moon.

That is what I am saying you are saying.

But, as it is written, "father, forgive them because they don't know what they do".

Same again.

Here is another one -

But the natural man receiveth not the things of the Spirit of God: for they are foolishness unto him: neither can he know them, because they are spiritually discerned

One could replace the natural man with Rolf, Spirit of God with Java/OSS, and spiritually with technically.

You have never seen the Microsoft power-users contribute to the population of unemployed programmers by utilizing Infopath XML tool with Sharepoint store and document management.

I haven't? It is my wifes job to read my mind and she does a much better job, and that doesn't say much.

All that is great as as long as you don't do anything outside what Microsoft provides.

BTW, the only programmers out of a job are local ones. Wouldn't you rather use a tool that cost much less, lets them pay YOU more (instead of lining Bill's pockets) and is open and extensible?

The question just is, how much longer shall the Java/Unix camp go through life with bindles before their eyes?

Bindles?

How much longer shall the Microsoft camp go through life with blinders on their eyes?

Someday you will learn that exaggerations only defeat their purpose.

I love it when you talk about yourself without realising it.

Also we can not pollute every thread here at TSS.

Not for want of trying though, eh Rolf...

>We have Microsoft flagship product SharePoint Portal Server, more sold than any commercial Java Portal product.

Having used Sharepoint - you might want to try one of the other .Net portals. I have a client who uses Sharepoint. I showed them Liferay and they were impressed especially of all of the stuff that comes with it.. Unfortunately they have locked themselves into MS tools and have no choice but to pay big bucks. At least for current projects. :)

And try doing SSO with Sharepoint and not have physical access to the server it is installed on. Man, I love Windows security (NOT).

Another option for both Java and .NET is the plumtree portal product. I did quite a detailed comparison of a number of portal products as part of a product selection for a client about 12 months ago for a client and felt that Plumtree was probably the best of the bunch.
http://www.plumtree.com/default_flash.asp

One thing to be aware of is that they do struggle with cross browser compatibility – as it indicated by their horrible web site!

Off topic but anyone has a good recommendationfor C# based ASP.NET solution ?ThanksRicky

Hey I am back and been looking for you call me asap

James Davis
805-371-0069 office
818-294-0937 ceil

Suppose I do want a calendar, a content management system and news. Why does it have to be a portal? First of all, if I want them on one page, I don't even have to use portlets. I could use iframes. And this could be accomplished quite simply.

Sure, but then you would typically have to manually log in to the separate apps. Yuch. And what if you want to require some stronger auth, like certificates or SMS tokens or whatever. Are you going to do that on your own for all those apps? Yuch.

A portal can handle these kind of things. Sure, in the end it'll probably use iframe's (or something similar), but there's a ton of things related to security integration and application integration that it will do for you (note: yes,
I'm a portlet vendor developer myself).

On the other hand, inter-poertlet communicationw ould be trickier (and I think that is one of the key values of portals).But I might not even need them on one page. Generally, people wan tto multi-task. Start adding a calendar entry, but then answeer a chat. Are you looking at the calendar entry when you're chatting? More than likely not. So, make them on separate pages, but remember state inbetween.Like I said elsewhere in this discussion, a lot of what a portal/portlets offer is enticing (i18n, customization, sso), but you don't have to aggregate that content all on one page for that.

Sure, I'm not much for the "all on one page" approach myself, but as above, there's a little more to the kind of app integration than just "create a bunch of iframes". I would not do that kind of stuff without a proper portal. But then again I'm spoiled with decent portal software, which doesn't seem all that common considering the comments in this thread ;-)

Sure, but then you would typically have to manually log in to the separate apps. Yuch. And what if you want to require some stronger auth, like certificates or SMS tokens or whatever.

I think the statement assumes that those ‘other’ applications provide some kind of backdoor for “portlet� face.

I do not know any (widely used) infrastructure that provides security context propagation. If I am in the dark, please enlighten me.
I am currently planning limited deployment of CAS (http://tp.its.yale.edu/tiki/tiki-index.php?page=CentralAuthenticationService) , so any suggestions, tips are welcome.

I think that SSO and security context propagation are important but slightly separate from portal issues.

I think the statement assumes that those ‘other’ applications provide some kind of backdoor for “portlet� face.

If you mean that I assumed that the other apps were portlets, then no, not really. It helps, for sure, but it's definitely not required.

I do not know any (widely used) infrastructure that provides security context propagation. If I am in the dark, please enlighten me.

Basic/digest authentication works quite well for this. We also do security propagation for any app that has form logins of some kind (=most apps).

As for SSO-authenticating the client the most popular ones we see are NTLM and Kerberos (for Windows-integration).

I am currently planning limited deployment of CAS (http://tp.its.yale.edu/tiki/tiki-index.php?page=CentralAuthenticationService) , so any suggestions, tips are welcome.I think that SSO and security context propagation are important but slightly separate from portal issues.

In my view a portal is all about application and security integration (to do application integration without security integration is kind of pointless).

HTH.

If you mean that I assumed that the other apps were portlets, then no, not really. It helps, for sure, but it's definitely not required.
........

Basic/digest authentication works quite well for this. We also do security propagation for any app that has form logins of some kind (=most apps).

It looks like we use terms “context propagation” and “application” differently or I miss something.
For me “application” != “web-application”, that means it does not have html login form.

And from your description I understand that you do not do “context propagation” rather credentials propagation (and potentially credential mapping).

Am I correct?

It looks like we use terms “context propagation” and “application” differently or I miss something.For me “application” != “web-application”, that means it does not have html login form.

Right, I am assuming webapps. Doing context propagation for heavy apps (if that's what you mean) is something different, and I think that's much more difficult. Which is why webapps are better, generally, from an integration perspective.

And from your description I understand that you do not do “context propagation” rather credentials propagation (and potentially credential mapping).Am I correct?

Quite correct (and yes, including credential mapping).

Well, if your website is a collection of severl modules/portlets (news, calendar, CMS etc.) and you have to bring them togethe and have some reusability on the portlets level - you NEED to develop your site as a Portal.

This is exactly the kind of stuff that gave portal technology a bad name. If you need componentization, portal technology is usually not only overkill it will actually hinder yur development since people tend to make anything into a portlet regardless if it makes sense or not, often requiring a bizarre amount of interportlet communication, usually done in the most primitive way. Example include "Date Chooser/Calender" Portlet, Navigation Portlet, "Hero" i.e. advertisment portlet etc.

This led to a lot of frustration and lost development time, mostly because some analyst told some customer they need a "portal" without knowing what "portal" means when it comes to ootb products.

Portals/Portlets are an excellent choice if you need a certain number of its features, like componentization of functionally distinct visual entities (portlets), user segmentation, rule based personalization. A portal product may also make sense if you can subscribe to just use a subset of the functionality, like web based state machines (like BEAs pageflows), standardized programming model, user management and good interface apis to enterprise CMS systems.

My previous company we started off using portal due to the fact we had BEA consultants everywhere who main job was to rubbish Struts everytime I brought it up. At the time it was the previous version of portal and it nearly brought the web development process to its knees. When I came on as the permanent technology lead I replaced the entire thing with a standard Struts app. I know Struts is not perfect but it is well understood by the majority of the java web development community.

Where I currently work we are going in the opposite direction and bringing Portal in to replace all the stand alone Struts applications. The view is that management wants to do this because it thinks based on some pretty one sided data that it will speed up what I agree is a slow development process. Of course the speed of development is nothing to do with Struts but the fact we live in clearcase merge hell.

I think there is a market for this stuff but it is not the majority of sites large or small. This is sad for BEA as since the application server is a commodity they need to find a new cash cow.

I thought WL Portal 8.1 used Struts?

I thought WL Portal 8.1 used Struts?

Pageflows created in BEA Workshop use Struts 1.1 internally.

Yes, WebLogic Portal is integrated with Struts.

Brett

I'm perhaps spoiled, but I see web portals as a giant kludge: how can you pretend to aggregate multiple applications and interact separately with each one when the basic unit of transfer that the browser uses is the HTTP request? It just doesn't make sense to me, it looks like an abuse of tecnology.

Now, if we had a different transport protocol, and browsers supporting it that would be a different thing: web portals would actually make sense. And, to clarify, I'm not talking about something like XmlHttpRequest (another horrible kludge).

I'm perhaps spoiled, but I see web portals as a giant kludge: how can you pretend to aggregate multiple applications and interact separately with each one when the basic unit of transfer that the browser uses is the HTTP request? It just doesn't make sense to me, it looks like an abuse of tecnology.Now, if we had a different transport protocol, and browsers supporting it that would be a different thing: web portals would actually make sense. And, to clarify, I'm not talking about something like XmlHttpRequest (another horrible kludge).

I agree with the earlier sentiment from Mr. Oberg:
'In my view a portal is all about application and security integration (to do application integration without security integration is kind of pointless).'

That you can't get around the fact that you can't isolate activity to one portlet, due to HTTP protocol, doesn't really matter to users. They're either indifferent or ignorant of such details. Just meet their general performance requirements. It's all about giving the user's what they want - even if that means pushing the technology beyond its intended purpose. The web browser isn't going anywhere for a long, long time.

I've heard alot of bad things about BEA's product, but I would like to know more about the scalability of offerings from Liferay and Exo. They seem to perform pretty well.

Mike

Mike

I'm perhaps spoiled, but I see web portals as a giant kludge: how can you pretend to aggregate multiple applications and interact separately with each one when the basic unit of transfer that the browser uses is the HTTP request? It just doesn't make sense to me, it looks like an abuse of tecnology.

I don't mean to point out the obvious, but the whole HTTP/HTML evolution is one giant abuse of the technology. Don't believe me? Go back and read the HTTP 1.0 spec, and look at the original markup discussions -- even a site as "simple" as TSS is light years beyond what was contemplated.

Like many things, when people realized what the possibilities were, the technology took on a life of its own. The portlet concept is rather "simple" compared to many of the abuses being done to HTTP and HTMl today ;-)

In the end, the question you have to ask is this: Is it doing what software should do: Is it wasting computer cycles to save people cycles?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

My guess (who can tell the future right?) is that portlet vendors will start releasing categories of portlets that work together.

For example, there may be a eCollaboration suite (calendar, msg boards, etc, that all work together), Education suite (what you're working on), CMS (Documentum, etc).

So it's somewhere in the middle.

Well, looking at our own portlets we have all sizes. The smallest portlet only shows a text or an image (since we're approaching this as a CMS), and then we have everything up to full-blown apps like survey and booking management apps.

My guess is that portlets that will be accessed through WSRP will be more convenient to have coarse-grained, as I'm not sure how well inter-portlet communication is going to work if you have many remote portlets that want to communicate.

<brian>
So it's somewhere in the middle.
</brian>

the same idea of reuse is also used in EJB (for business components reuse). I remember 4 years ago, there was a site "EJBComponents" which tried to be a mediator for re-usable EJBs. Also the idea of IBM SanFransisco Framework, which tried to offer reusable business components. All of them failed.

The same idea is now coming with portlets. They should be reusable. Not only as business components but also the "presentation/view" of them should be reusable.

The point is that we all know today that the chance to have reusable components (at least the *best* chance) only in the following granularities and domains:
- Coarse grained and reusable in many domains: standard applications, os, app-servers, dbms, ...
- Fine grained and reusable in many domains: utilities, UI components, ...

"Middle-grained" and only "in some or few domains" reusability is just the hardest one (student component, enrollment component) :-)

If the same thing happens in portlets, we will see "bookmark, weather" portlets and "a complete application" portlets to be reusable. But no "student", "enrollment" portlets...

So, my point is that, is it worth it to "decompose" your application e.g. OpenUSS into portlets? If the same thing happens just like in EJBs, the answer would be no. It is only worth it to offer your *whole* application as a portlet...

Cheers,
Lofi.

You're right, in order for the student package to work, you'd have to release the whole application as a bunch of interdependent portlets.

I don't mean to point out the obvious, but the whole HTTP/HTML evolution is one giant abuse of the technology. Don't believe me? Go back and read the HTTP 1.0 spec, and look at the original markup discussions -- even a site as "simple" as TSS is light years beyond what was contemplated.

I agree! I would mugh rather read these discussions in a client made for reading discussions (think: newsreader). Or, at least, an RIA application designed for this.

Wouldn't it be something if Java "sites" used Java applets for Java Web Start to launch a lcient in which to read the content?

Brian, there is a news and forums reader coming for webstart, at boardVU.com. You can check it out and comment on it if you want (not here but there)
.V

I don't mean to point out the obvious, but the whole HTTP/HTML evolution is one giant abuse of the technology. Don't believe me? Go back and read the HTTP 1.0 spec ..... were, the technology took on a life of its own. The portlet concept is rather "simple" compared to many of the abuses being done to HTTP and HTMl today ;-)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

Very well said. I would just point-out one more obvious fact - the simplicity of HTML is exactly what makes it the masterpiece that made Web revolution possible. There were numerous attempts both before and, definitely, after its adoption to come up with (much) more sophisticated solutions. Some of them are pretty nifty but HTML is, still, the one.

If you look at the Portal approach as just a best practice/reusable approach of 80% of web-development tasks, you may feel more understanding to it.

Well, if Portal/Portlets are kludge, then what is Java Server Faces? JSF is an attempt to use a technology for everything it was not meant to have been used for, in the first place. Developing web-applications like desktop ones? Not while Web is run on stateless HTTP protocol, for God's sake and not while everybody wants to have their own, branded look-and-feel.

I think JSR-168 (as en example of the attempt to capture the best-practices) has issues but it is way better than most of the specifications in version one. It's OK.

I don't mean to point out the obvious, but the whole HTTP/HTML evolution is one giant abuse of the technology.

Oh yeah!

Talk about "emperor's new clothes" (That was for Rolf so he will understand :) ).

Hi Brian,

I also like your product LPortal, great stuff!
I would like to hear your opinion about the granularity of portlets. Do you think that the future of portlets will the the fine-grained (bookmark), middle-grained (calendar) or coarse grained (fully functional application) portlets?

Is that possible for example to build *a portlet* which contains the whole OpenUSS application (eLearning) or a complet CMS application or an ERP application? So that we can have a portal which consists a lot of fully functional applications (instead of just fine-grained portlets like bookmark, weather)? Does this sound applicable to you?

Thanks for your insight,
Lofi.

These days I must be influenced by my recent reading of Tate's book "Better, Faster, Lighter Java", but i'm wondering... do we really need all this stuff? Can't we have the job done with lighter, simpler and more manageable approaches?

These days I must be influenced by my recent reading of Tate's book "Better, Faster, Lighter Java", but i'm wondering... do we really need all this stuff? Can't we have the job done with lighter, simpler and more manageable approaches?

Does the title have "tastier" in it too?

For somethings, we probably can. It does fit for some others, however, and it is nice to have it when you need. But as usual (just like EJBs), it is overused. Plus we need it so Rolf can't say J2EE doesn't have portals.