Enterprise vs. Open Source Portals? 37
lowvato asks: "I have recently been tasked with building two enterprise level portals. One is already in the making using Apache Jetspeed and the other is in the planning stage. I have been impressed with Jetspeed and its progress and versatility as a portal environment. One portal needs a very high level of security and interaction with disperate web services while the other is more of a community building service with CMS, forums, and so forth.
Upon a limited review of the commercial portal solutions, I have found it hard to determine what they offer over open source solutions (especially since a few are based on products like Jetspeed or UPortal). I would like to hear what others have found using commercial and open source portal products."
Zope (Score:2, Informative)
Zope (Score:5, Informative)
Re:Zope (Score:3, Informative)
1. Easy management : yes and no. It's full of "objects", "class", "methods", etc. I can understand that; my client cannot.
2. Separation of code from content : if you don't count DTML as "code", that may be true.
3. Authentication scheme : I tried to coax Zope into authenticating to a MySQL database. Two package seems to be doing what I wanted. One was full of bug, the other would have required that I port it from PostgreSQL to MySQL.
Quality of module vary greatly. Some are good, but a lot are outdated or broken.
The zope.org site suck big time. The search engine lack option and return too many hit without any regard to revelance.
Documentation is uneven. It's better than none at all, however.
Error messages are useless. Although it might be nice to know the function call stack, I would have prefered something more informative than "KeyError" for error message. And have a look at the data that made Zope choke, too.
I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.
Re:Zope (Score:2)
I don't see how third party packages and modules are the fault of the zope software. Zope doesn't magically update modules to fix bugs and use the latest methods.
Why don't you can the error message then? The stack trace is because an uncaught exception is thrown. If you don't like the stack trace, then catch the exception and have the code output the error message that you want it to show. Incidentally, the stack track and exception type identifies the error pretty explicitly. Just based on your description, I'm fairly sure that the error was due to the code trying to look up something that wasn't present in a dictionary.
Well that's your problem. You don't like python so you are bitching about the fact that Zope uses python and a lot of Zope modules use python also. You do know that Zope modules can be written in perl as well right?
Re:Zope (Score:2)
I don't see how third party packages and modules are the fault of the zope software. Zope doesn't magically update modules to fix bugs and use the latest methods.
Authenticating to a RDBMS is not built-in (more precisely, it was'nt in the version I used) so you need to use a third-party module. If the module for the functionnality you need is buggy/inexistant, it impact the usuability of the whole package.
Why don't you can the error message then? The stack trace is because an uncaught exception is thrown. If you don't like the stack trace, then catch the exception and have the code output the error message that you want it to show. Incidentally, the stack track and exception type identifies the error pretty explicitly. Just based on your description, I'm fairly sure that the error was due to the code trying to look up something that wasn't present in a dictionary.
Excuse my ignorance, but I did not understand a thing about what you said. Why can't Zope output standard error messages, like "Can't locate object method "do_something" via package Neat::Gizmo" or "compilation error: syntax error at line 123" ? Also, not "canning" (whatever that mean) error message seem to be the default because I can't recall seeing a helpful error message in the two month I had been battling with Zope.
Well that's your problem. You don't like python so you are bitching about the fact that Zope uses python and a lot of Zope modules use python also. You do know that Zope modules can be written in perl as well right?
No, I am bitching because it did'nt fit my needs (no SSL, only Basic Auth in the default install ... I know you can use Apache's mod_proxy but come on!). As for fitting a square peg in a round hole, why not use a square hole in the first place (use a Perl-based portal toolkit if Perl is what you know) ?
What I really don't like about Zope is advocate claiming support for X and Y and, when you are down implementing it, you realise the module had not been maintained in two year and break with 2.5.x.
Overall, Zope leaved me an unfinished, unpolished and akward feel.
Re:Zope (Score:3, Insightful)
Java, Pascal, C++, Python, Perl, etc. are all also full of objects, classes and methods. The programmer's job is to hide these things from the client behind a friendly interface.
Somewhat true, for DTML. However, Page Templates were recently introduced and they (mostly) separate code and presentation quite nicely.
Well, most search engines suck; that's why I use Google with the "site:" constraint.
Re:Zope (Score:2)
DTML is but one of several template schemes Zope offers. The technology is evolving fast, and even recent books are a little out of date on this one, but if DTML doesn't meet your needs then check some of the other [zope.org] alternatives [zope.org]. In particular, Zope Page Templates, with their HTML attribute based markup, are a very interesting approach that has the nice side effect of keeping everything within perfectly well formed HTML -- thus keeping the web monkeys with their whizz bang frontdreamy editors happy.
Again, you have a wide variety of options here -- basically anything you want, anything you could do in pure Apache, etc. A quick search for authentication & authorization on Zope.org turned up this nice paper on the component architecture of the security system [zope.org].
In general most of your points deserve these kind of pat responses. It seems to me that the Zope system *is* very good, but the software itself is evolving much faster than the documentation is managing to keep up. That's not to say that the documentation doesn't exist -- it does, and help is out there if you want it -- but once the software hits a certain stable plateau a revamping of the documentation would be very welcome. Zope is an excellent system though. What finally won me over was to see a presentation on it at a Boston Perl Mongers meeting and having everyone watch in awe at the things this Python software could do so easily, with responses to the effect of "mod_perl is nice and all, but why haven't we come up with something high level like this?" Good question...
Re:Zope (Score:2)
a good chunk of time learning Zope and if I can find something open source
and better than their CMF [zope.com] I would
love to hear about it.
Re:Zope (Score:2)
As for recommending another solution, I put a lot of hope in the Horde framework (www.horde.org). Written in PHP, clean OO, easily extensible, featureful, etc. However, the content management feature is in early developement so not really useable yet, and documentation is basically inexistant.
Beside that, I am sorry I have not had the chance to work with any other solution.
Re:Zope (Score:1)
I'm sorry but comparing Horde to Zope is ridiculous.
The most powerfull thing about Zope is the TTW capabilities and filesystem independence. By the way that's why it's particularly suitable for portal and weblog type tasks.
But it's true that is requires some serious Python and OO fluency, specially when it comes to site-specific needs.
Re:Zope (Score:2)
Re:Zope (Score:1)
TTW = through the web
TTW is actually two separate things:
ZODB is important because:
Meh. (Score:3, Insightful)
Re:Meh. (Score:4, Insightful)
On the other hand, industry specific portals are hugely successful. You're looking at one right now [slashdot.org], but examples exist in many industries.
The point is that many of these portals now make money by:
Also (Score:3, Insightful)
Individual companies.
Portals are an excellent "intranet" tool, offering company news and documents to their employees. They're often a better and cheaper alternative to investing in one of the Intranet-ware applications that are provided by M$ and others or trying to develop them in-house, since generally most of what an intranet needs to do is share documents, which can be done easily and well through a portal.
Re:Meh. (Score:3, Insightful)
At this point, the definition of "portal" becomes blurry. I would consider Slashdot to be more like a weblog than a portal; Slashdot is, ultimately, a collection of links (a la Metafilter or Memepool) smooshed up against a pretty nice posting board system. I wouldn't consider that to be a portal, by any useful definition.
I would put netscape.com down as the canonical example of a portal. Just typing "netscape.com" into my browser shows me these things: "Eminem's a Movie Star!"; "Workplace Weasels Beware: Dilbert's Back"; "DJ30 8418.95 -118.18"; "Deal of the Day: Big Stereo Sound at Half the Price!"; "Weather (Enter ZIP:)"; and "When will the tech sector rebound? [Vote]". In other words, Netscape's site tries to look like the front page of a newspaper, with a couple of articles above the fold, the weather forecast in the corner, stock market statistics in the other corner, some ads, and a bunch of smaller articles and ads below the fold. It does this by scraping web sites or web services, assembling the content according to a template and/or some user preferences, adding a dash of advertising, and stirring until blended. This basic pattern is true of general portal sites, like my.yahoo.com and netscape.com and others; industry-specific portal sites; and corporate portal sites. The only difference is the sources from which the content is collected and how it's presented.
I don't think Slashdot (or K5, or MacSlash, or Metafilter, or any similar site) qualifies as a portal, in the traditional sense. Of course, if the definition of "portal" has changed over the past few years without my noticing-- before this morning, I hadn't been to netscape.com since about 1997, and that was to download Netscape Navigator 3 for IRIX-- then pretty much everything I've said here is outdated and irrelevant.
But I suppose, if I'm anywhere close to being right about this, that a discussion of what, exactly, constitutes a "portal" in the context of this Ask Slashdot is in order. Then again, I don't really care, so WTF.
Re:Meh. (Score:2)
I feel that the format of a portal, be it reverse chronological (thus emulating a weblog), or more "frontpage" style, is really secondary to its purpose and use.
My definition of a portal really is an interactive, frequently updated destination point for gathered information, and in this sense Slashdot really excels.
Portals (Score:1)
Often personally customisable for style and content.
This includes the link collection stuff, like
But it also includes functional portals, like 'my pages' that many companies have for their users.
Sites that allow the user to check their bill, update personal information, order new stuff, check order progress and so on.
Or internal corporate sites that lets the employees interact with the payroll and other HR systems, order stationary/hardware and that kind of operations as well of providing corporate wide information (guidelines, common procedures, forms).
Re:Meh. (Score:2)
It seems to me that Slashdot fits your criteria. Above the fold you have the latest headlines, a little advertising and links to other sections. Below the fold you have search functionality, a relevant quotation and links to past stories and other sites of potential interest.
The only point of difference is that Slashdot has the added criteria that all items have a technology slant but even within this restriction there's still the variety you described. Instead of sports, weather and entertainment we have Security, Anime and "Your Rights Online".
Re:Meh. What is a portal (Score:1)
Portal Software? What's That? (Score:2)
I would use vi, perl and postgresql, but that's just me
Re:Portal Software? What's That? (Score:1)
-Rupert
Re:Portal Software? What's That? (Score:2)
Maybe you really could set up the whole works by Monday, but sometimes it's better to take somebody else's wheel, clumsy at may be, rather than crafting it yourself.
On the other hand, if you have plenty of time to develop it, that's great. Coding it yourself gives you the best form of control, but often making these products do everything that is required of them takes much longer than expected, especially since there will often be a lot of back-and-forth exchanges with the client about features that they want.
Re:Portal Software? What's That? (Score:2)
Deadlines are the death of all good software. If the business guys need it done faster than it can be done right, that's their problem, not mine. Plan ahead
Enterprise vs Open Source Portals? (Score:1, Funny)
Re:Enterprise vs Open Source Portals? (Score:1)
Document Management (Score:3, Informative)
Re:Document Management (Score:1)
Additional questions (Score:2, Insightful)
Do both portals need to consume the same set of services?
Do these services already exist?
Are portlet standards an issue (sun vs. oasis)?
Do the portlets need to provide the security or be compatible with an existing security framework?
Do you have time to market considerations?
Platform considerations?
What's the usage going to be like?
Although portals attempt to do it all, there is no portal solution that resolves all issues. If there is limited functionality and you have time to market issues, jetspeed is a favorable choice. Webapp installation and deployment is probably the easiest of the bunch.
If you have only a community requirement, consider slashcode or phpnuke. These are probably the industry's best and free is a good price. However, these are primarily community portals, additional functionality is limited.
Plumtree excels at community + a little more. There seems to be scalability issues, and it does not provide a true highly available solution.
BEA does not have the same community support, but excels at it's integration with other features (J2EE, BPM, personalization).
These are all customizable, but the more you customize, the more difficult it is to upgrade. BEA seems to be the most customizable, but requires the most time to bring a portal up to production.
Re:Additional questions (Score:1)
No, both projects are independant
Do both portals need to consume the same set of services?
ditto
Do these services already exist?
In some cases yes,in others no. This is one of tha main points. I should be able to write a generic class to render content to the portal engine and then spend the rest of my time enabling the services.
Are portlet standards an issue (sun vs. oasis)? Standards are a big issue and should be regardless, if I wish to continue work on either site. I tend to not want to go the sun standards route.
Platform considerations?
Linux in both cases.
What's the usage going to be like?
Heavy for one, mild for the other...if I could just get clients to coordinate.
Oracle Portal or Zope (Score:1)
If you want something a little cheaper, install Zope, CMF and Plone. That will give you a very capable, basic portal. If you want something added that isn't already there, you have the option of writing it yourself or contracting with someone to develop the product for you.
I've been very impressed with both products. I use Oracle Portal at work and Zope at home.
Slashdot is probably the wrong place to ask (Score:1)
TheServerSide [theserverside.com] has some good reviews on the various enterprise servers, as well as some complete stinkers. A general rule of thumb is to throw out all the comments which seem to be lacking in spelling or logical argument.
Re:Slashdot is probably the wrong place to ask (Score:1)
Yeah and also all the comments that say there are other things beyond J2EE ...
The word "Portal" is too generic... (Score:2)
I have worked with one of the market leaders - Vignette - and their product is largely "framework" - you get very little out of the box, and have to do a lot of work to get something running that matches your particular requirements. Even though they sell themselves as a Content Management System, they don't support revisioning of documents.
On the other hand, products like Zope or PHP-Nuke - which also fall under the broad category - are far more like "web-site in a box" applications for content-driven, community-based websites.
On the whole, the big-ticket commercial systems tend to address a bunch of narrow concerns (e.g. documentum is very good at document management, Interwoven is very good at web-based workflow-driven content management), but often are weak in other areas (Vignette (certainly in the pre-version 6 days) is very poor at dynamic functionality so forums etc. are difficult to implement. I would suggest that you make sure any evaluation adequately addresses all the features you require, and ask for reference sites. We didn't and got burnt very badly as a result.
As far as open software goes, I like Cocoon. It requires you to do a lot of work, but should be very easy to work with once you've got it up and running. On the other hand, if you don't want to spend your life working on the portal, get Zope or PHP-Nuke, install it and walk away. They'll prob. do 90% of what you want, and are pretty easy to support.