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.
-
BEA dev2dev Tech Talk: Developing Portal Applications (74 messages)
- Posted by: Dion Almaer
- Posted on: January 21 2005 10:35 EST
Threaded Messages (74)
- Tech Talk: Developing Portal Applications by Rickard Oberg on January 21 2005 11:46 EST
- Tech Talk: Developing Portal Applications by Brian Chan on January 21 2005 12:00 EST
- Tech Talk: Developing Portal Applications by Konstantin Ignatyev on January 21 2005 12:31 EST
- Tech Talk: Developing Portal Applications by Brian Chan on January 21 2005 12:44 EST
-
Would never recommend BEA Portal by Marc Mulzer on January 21 2005 01:04 EST
- Would never recommend BEA Portal by Michael Jouravlev on January 21 2005 01:19 EST
-
Would never recommend BEA Portal by Brian Chan on January 21 2005 01:22 EST
-
Would never recommend BEA Portal by Marc Mulzer on January 21 2005 01:31 EST
-
Would never recommend BEA Portal by Brian Chan on January 21 2005 02:24 EST
-
Would never recommend BEA Portal by Michael Klaene on January 22 2005 12:51 EST
-
Liferay: EJB and ASP by Brian Chan on January 23 2005 10:12 EST
-
Liferay: EJB and ASP by Juergen Hoeller on January 24 2005 03:42 EST
- Liferay: EJB and ASP by Brian Chan on January 24 2005 12:30 EST
-
Liferay: EJB and ASP by Juergen Hoeller on January 24 2005 03:42 EST
-
Liferay: EJB and ASP by Brian Chan on January 23 2005 10:12 EST
-
Would never recommend BEA Portal by Michael Klaene on January 22 2005 12:51 EST
-
Would never recommend BEA Portal by Brian Chan on January 21 2005 02:24 EST
-
Would never recommend BEA Portal by Marc Mulzer on January 21 2005 01:31 EST
-
Would never recommend BEA Portal by Claus Ibsen on January 22 2005 05:33 EST
-
Would never recommend BEA Portal by S M on January 27 2005 10:20 EST
-
BEA Workshop by Claus Ibsen on February 21 2005 06:40 EST
- BEA Workshop by Anders Holmbech Brandt on March 08 2005 06:25 EST
-
BEA Workshop by Claus Ibsen on February 21 2005 06:40 EST
-
Would never recommend BEA Portal by S M on January 27 2005 10:20 EST
-
Would never recommend BEA Portal by Markus Hjort on January 24 2005 04:26 EST
-
Would never recommend BEA Portal by Chris Jolley on January 25 2005 12:23 EST
-
Would never recommend BEA Portal by Rickard Oberg on January 26 2005 02:31 EST
-
Would never recommend BEA Portal by Chris Jolley on January 26 2005 12:13 EST
-
Would never recommend BEA Portal by Rickard Oberg on January 26 2005 06:00 EST
- Would never recommend BEA Portal by Chris Jolley on January 26 2005 06:42 EST
-
Would never recommend BEA Portal by Rickard Oberg on January 26 2005 06:00 EST
-
Would never recommend BEA Portal by Chris Jolley on January 26 2005 12:13 EST
-
Would never recommend BEA Portal by Rickard Oberg on January 26 2005 02:31 EST
-
Would never recommend BEA Portal by Chris Jolley on January 25 2005 12:23 EST
- LifeRay on WebSphere by Gord Johnston on January 22 2005 15:41 EST
- Liferay on WebSphere by Brian Chan on January 23 2005 10:08 EST
- Tech Talk: Developing Portal Applications by Konstantin Ignatyev on January 21 2005 12:31 EST
- Why a portal? by Brian Sayatovic on January 21 2005 12:41 EST
- Re: Why a portal? by Will Hartung on January 21 2005 12:58 EST
- My view on "portal" by Brian Sayatovic on January 21 2005 13:34 EST
-
My view on "portal" by Mark N on January 21 2005 01:56 EST
- Portal, SSO by Brian Sayatovic on January 21 2005 02:01 EST
-
My view on "portal" by Mark N on January 21 2005 01:56 EST
- Why a portal? by Irakli Nadareishvili on January 21 2005 15:16 EST
-
Why a portal? by Brian Sayatovic on January 21 2005 03:42 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 04:11 EST
-
Why a portal? by Irakli Nadareishvili on January 21 2005 06:19 EST
-
Portals in dotNet by Ricky Datta on January 21 2005 06:39 EST
-
Portals in dotNet by Rolf Tollerud on January 22 2005 06:07 EST
-
typo by Rolf Tollerud on January 22 2005 06:10 EST
-
typo by Cameron Purdy on January 22 2005 09:06 EST
-
champion of lost causes by Rolf Tollerud on January 23 2005 02:24 EST
-
champion of lost causes by Cameron Purdy on January 23 2005 11:59 EST
-
Cameron, champion of lost causes by Rolf Tollerud on January 23 2005 02:58 EST
-
Cameron, champion of lost causes by Mark N on January 23 2005 03:52 EST
-
hundreds of web parts available by Rolf Tollerud on January 23 2005 04:20 EST
-
hundreds of web parts available by Mark N on January 23 2005 05:35 EST
-
a record in unreasonableness by Rolf Tollerud on January 23 2005 06:52 EST
- a record in unreasonableness by Mark N on January 23 2005 07:37 EST
-
a record in unreasonableness by Rolf Tollerud on January 23 2005 06:52 EST
-
hundreds of web parts available by Mark N on January 23 2005 05:35 EST
-
hundreds of web parts available by Rolf Tollerud on January 23 2005 04:20 EST
- Rolf - polietness means I can't put in a comment by Fred Bloggs on January 24 2005 06:25 EST
-
Cameron, champion of lost causes by Mark N on January 23 2005 03:52 EST
-
Cameron, champion of lost causes by Rolf Tollerud on January 23 2005 02:58 EST
-
champion of lost causes by Cameron Purdy on January 23 2005 11:59 EST
-
champion of lost causes by Rolf Tollerud on January 23 2005 02:24 EST
-
typo by Cameron Purdy on January 22 2005 09:06 EST
- Portals in dotNet by Mark N on January 23 2005 02:23 EST
- Portals in dotNet by Fred Bloggs on January 24 2005 06:10 EST
-
typo by Rolf Tollerud on January 22 2005 06:10 EST
- Hi Ricky Datta by James Davis on March 27 2006 07:00 EST
-
Portals in dotNet by Rolf Tollerud on January 22 2005 06:07 EST
-
Portals in dotNet by Ricky Datta on January 21 2005 06:39 EST
-
Why a portal? by Irakli Nadareishvili on January 21 2005 06:19 EST
-
Why a portal? by Rickard Oberg on January 21 2005 04:12 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 04:25 EST
-
Why a portal? by Rickard Oberg on January 21 2005 04:48 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 05:01 EST
- Why a portal? by Rickard Oberg on January 22 2005 02:31 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 05:01 EST
-
Why a portal? by Rickard Oberg on January 21 2005 04:48 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 04:25 EST
-
Why a portal? by Konstantin Ignatyev on January 21 2005 04:11 EST
- Why a portal? by Karl Banke on January 26 2005 04:15 EST
-
Why a portal? by Brian Sayatovic on January 21 2005 03:42 EST
- Tech Talk: Developing Portal Applications by David Jones on January 21 2005 13:50 EST
- BEA consultants everywhere who main job was to rubbish Struts by Roger Lee on January 24 2005 05:39 EST
- BEA consultants everywhere who main job was to rubbish Struts by Markus Hjort on January 24 2005 06:15 EST
- BEA consultants everywhere who main job was to rubbish Struts by Brett Hovenkotter on January 24 2005 06:51 EST
- BEA consultants everywhere who main job was to rubbish Struts by Roger Lee on January 24 2005 05:39 EST
- Portals a kludge? by Sebastiano Pilla on January 22 2005 05:34 EST
- Portals a kludge? by Michael Klaene on January 22 2005 08:24 EST
- Portals a kludge? by Cameron Purdy on January 22 2005 11:11 EST
-
Portals a kludge? by Brian Chan on January 22 2005 11:31 EST
- Portals a kludge? by Rickard Oberg on January 22 2005 12:08 EST
-
Granularity by Lofi Dewanto on January 22 2005 12:38 EST
- Granularity by Brian Chan on January 23 2005 10:14 EST
-
TSS is a kludge by Brian Sayatovic on January 22 2005 05:48 EST
- Tss is great by Vic Cekvenich on January 23 2005 12:37 EST
- Portals a kludge? by Irakli Nadareishvili on January 22 2005 09:20 EST
- Portals a kludge? by Mark N on January 23 2005 02:25 EST
-
Portals a kludge? by Brian Chan on January 22 2005 11:31 EST
- Portlets Granularity by Lofi Dewanto on January 22 2005 10:15 EST
- Do we need this stuff? by Vania Cilli on January 24 2005 06:05 EST
- Do we need this stuff? by Mark N on January 24 2005 07:47 EST
-
Tech Talk: Developing Portal Applications[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 21 2005 11:46 EST
- in response to Dion Almaer
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. -
Tech Talk: Developing Portal Applications[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 21 2005 12:00 EST
- in response to Dion Almaer
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 -
Tech Talk: Developing Portal Applications[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: January 21 2005 12:31 EST
- in response to 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? -
Tech Talk: Developing Portal Applications[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 21 2005 12:44 EST
- in response to Konstantin Ignatyev
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Marc Mulzer
- Posted on: January 21 2005 13:04 EST
- in response to Konstantin Ignatyev
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: January 21 2005 13:19 EST
- in response to Marc Mulzer
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 21 2005 13:22 EST
- in response to Marc Mulzer
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Marc Mulzer
- Posted on: January 21 2005 13:31 EST
- in response to Brian Chan
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 21 2005 14:24 EST
- in response to Marc Mulzer
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! -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Michael Klaene
- Posted on: January 22 2005 12:51 EST
- in response to Brian Chan
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 -
Liferay: EJB and ASP[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 23 2005 22:12 EST
- in response to Michael Klaene
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. -
Liferay: EJB and ASP[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: January 24 2005 03:42 EST
- in response to Brian Chan
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 -
Liferay: EJB and ASP[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 24 2005 12:30 EST
- in response to Juergen Hoeller
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Claus Ibsen
- Posted on: January 22 2005 05:33 EST
- in response to Marc Mulzer
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: S M
- Posted on: January 27 2005 22:20 EST
- in response to Claus Ibsen
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!) -
BEA Workshop[ Go to top ]
- Posted by: Claus Ibsen
- Posted on: February 21 2005 06:40 EST
- in response to S M
Yes I remember that problem as well - the need to delete certain temp files/folders to make Workshop run again/compile. -
BEA Workshop[ Go to top ]
- Posted by: Anders Holmbech Brandt
- Posted on: March 08 2005 06:25 EST
- in response to Claus Ibsen
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Markus Hjort
- Posted on: January 24 2005 04:26 EST
- in response to Marc Mulzer
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Chris Jolley
- Posted on: January 25 2005 12:23 EST
- in response to Markus Hjort
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 26 2005 02:31 EST
- in response to Chris Jolley
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Chris Jolley
- Posted on: January 26 2005 12:13 EST
- in response to Rickard Oberg
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 26 2005 18:00 EST
- in response to Chris Jolley
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. -
Would never recommend BEA Portal[ Go to top ]
- Posted by: Chris Jolley
- Posted on: January 26 2005 18:42 EST
- in response to Rickard Oberg
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) -
LifeRay on WebSphere[ Go to top ]
- Posted by: Gord Johnston
- Posted on: January 22 2005 15:41 EST
- in response to Brian Chan
Brian,
Is there an install script for liferay on WebSphere (yet)?
Gordon -
Liferay on WebSphere[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 23 2005 22:08 EST
- in response to Gord Johnston
Yes, we finally put up the websphere install docs. Sorry for the inconvenience. Here it is.
http://www.liferay.com/documentation/installation/websphere.jsp -
Why a portal?[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: January 21 2005 12:41 EST
- in response to Dion Almaer
I'm curious to here fellow readers reasons for developing portals. Perhaps a definition of a portal would also be helpful. -
Re: Why a portal?[ Go to top ]
- Posted by: Will Hartung
- Posted on: January 21 2005 12:58 EST
- in response to Brian Sayatovic
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. -
My view on "portal"[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: January 21 2005 13:34 EST
- in response to Brian Sayatovic
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. -
My view on "portal"[ Go to top ]
- Posted by: Mark N
- Posted on: January 21 2005 13:56 EST
- in response to Brian Sayatovic
And SSO. -
Portal, SSO[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: January 21 2005 14:01 EST
- in response to Mark N
And SSO.
Agreed. And SSO is another one of thoise things that is uiseful even without a portal. -
Why a portal?[ Go to top ]
- Posted by: Irakli Nadareishvili
- Posted on: January 21 2005 15:16 EST
- in response to Brian Sayatovic
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 -
Why a portal?[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: January 21 2005 15:42 EST
- in response to Irakli Nadareishvili
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. -
Why a portal?[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: January 21 2005 16:11 EST
- in response to Brian Sayatovic
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 a portal?[ Go to top ]
- Posted by: Irakli Nadareishvili
- Posted on: January 21 2005 18:19 EST
- in response to Konstantin Ignatyev
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 :) -
Portals in dotNet[ Go to top ]
- Posted by: Ricky Datta
- Posted on: January 21 2005 18:39 EST
- in response to Irakli Nadareishvili
Off topic but anyone has a good recommendation
for C# based ASP.NET solution ?
Thanks
Ricky -
Portals in dotNet[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 22 2005 18:07 EST
- in response to Ricky Datta
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.
http://www.joemarini.com/articles/sharepoint20041115.php
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?.
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 -
typo[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 22 2005 18:10 EST
- in response to Rolf Tollerud
Windows 2003 Server of course. -
typo[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: January 22 2005 21:06 EST
- in response to Rolf Tollerud
Windows 2003 Server of course.
http://www.theinquirer.net/?article=20817
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters -
champion of lost causes[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 23 2005 02:24 EST
- in response to Cameron Purdy
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 -
champion of lost causes[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: January 23 2005 11:59 EST
- in response to 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 -
Cameron, champion of lost causes[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 23 2005 14:58 EST
- in response to Cameron Purdy
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) -
Cameron, champion of lost causes[ Go to top ]
- Posted by: Mark N
- Posted on: January 23 2005 15:52 EST
- in response to Rolf Tollerud
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. -
hundreds of web parts available[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 23 2005 16:20 EST
- in response to Mark N
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 -
hundreds of web parts available[ Go to top ]
- Posted by: Mark N
- Posted on: January 23 2005 17:35 EST
- in response to 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. -
a record in unreasonableness[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: January 23 2005 18:52 EST
- in response to Mark N
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 -
a record in unreasonableness[ Go to top ]
- Posted by: Mark N
- Posted on: January 23 2005 19:37 EST
- in response to 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? -
Rolf - polietness means I can't put in a comment[ Go to top ]
- Posted by: Fred Bloggs
- Posted on: January 24 2005 18:25 EST
- in response to Rolf Tollerud
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... -
Portals in dotNet[ Go to top ]
- Posted by: Mark N
- Posted on: January 23 2005 14:23 EST
- in response to Rolf Tollerud
>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). -
Portals in dotNet[ Go to top ]
- Posted by: Fred Bloggs
- Posted on: January 24 2005 18:10 EST
- in response to Rolf Tollerud
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! -
Hi Ricky Datta[ Go to top ]
- Posted by: James Davis
- Posted on: March 27 2006 19:00 EST
- in response to Ricky Datta
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 -
Why a portal?[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 21 2005 16:12 EST
- in response to Brian Sayatovic
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 ;-) -
Why a portal?[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: January 21 2005 16:25 EST
- in response to Rickard Oberg
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. -
Why a portal?[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 21 2005 16:48 EST
- in response to Konstantin Ignatyev
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. -
Why a portal?[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: January 21 2005 17:01 EST
- in response to Rickard Oberg
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? -
Why a portal?[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 22 2005 02:31 EST
- in response to Konstantin Ignatyev
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). -
Why a portal?[ Go to top ]
- Posted by: Karl Banke
- Posted on: January 26 2005 04:15 EST
- in response to Irakli Nadareishvili
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. -
Tech Talk: Developing Portal Applications[ Go to top ]
- Posted by: David Jones
- Posted on: January 21 2005 13:50 EST
- in response to Dion Almaer
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. -
BEA consultants everywhere who main job was to rubbish Struts[ Go to top ]
- Posted by: Roger Lee
- Posted on: January 24 2005 05:39 EST
- in response to David Jones
I thought WL Portal 8.1 used Struts? -
BEA consultants everywhere who main job was to rubbish Struts[ Go to top ]
- Posted by: Markus Hjort
- Posted on: January 24 2005 06:15 EST
- in response to Roger Lee
I thought WL Portal 8.1 used Struts?
Pageflows created in BEA Workshop use Struts 1.1 internally. -
BEA consultants everywhere who main job was to rubbish Struts[ Go to top ]
- Posted by: Brett Hovenkotter
- Posted on: January 24 2005 18:51 EST
- in response to Roger Lee
-
Portals a kludge?[ Go to top ]
- Posted by: Sebastiano Pilla
- Posted on: January 22 2005 05:34 EST
- in response to Dion Almaer
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). -
Portals a kludge?[ Go to top ]
- Posted by: Michael Klaene
- Posted on: January 22 2005 08:24 EST
- in response to Sebastiano Pilla
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 -
Portals a kludge?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: January 22 2005 11:11 EST
- in response to Sebastiano Pilla
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 -
Portals a kludge?[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 22 2005 11:31 EST
- in response to Cameron Purdy
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. -
Portals a kludge?[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: January 22 2005 12:08 EST
- in response to Brian Chan
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. -
Granularity[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: January 22 2005 12:38 EST
- in response to Brian Chan
<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. -
Granularity[ Go to top ]
- Posted by: Brian Chan
- Posted on: January 23 2005 22:14 EST
- in response to Lofi Dewanto
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. -
TSS is a kludge[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: January 22 2005 17:48 EST
- in response to Cameron Purdy
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? -
Tss is great[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: January 23 2005 12:37 EST
- in response to Brian Sayatovic
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 -
Portals a kludge?[ Go to top ]
- Posted by: Irakli Nadareishvili
- Posted on: January 22 2005 21:20 EST
- in response to Cameron Purdy
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. -
Portals a kludge?[ Go to top ]
- Posted by: Mark N
- Posted on: January 23 2005 14:25 EST
- in response to Cameron Purdy
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 :) ). -
Portlets Granularity[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: January 22 2005 10:15 EST
- in response to Dion Almaer
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. -
Do we need this stuff?[ Go to top ]
- Posted by: Vania Cilli
- Posted on: January 24 2005 06:05 EST
- in response to Dion Almaer
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? -
Do we need this stuff?[ Go to top ]
- Posted by: Mark N
- Posted on: January 24 2005 07:47 EST
- in response to Vania Cilli
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.