Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Slashback

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."
This discussion has been archived. No new comments can be posted.

Enterprise vs. Open Source Portals?

Comments Filter:
  • Zope (Score:2, Informative)

    try Zope [zope.org] ... it's open source, and very well-known, too.
  • Zope (Score:5, Informative)

    by Scaba ( 183684 ) <.moc.aicnarfeoj. .ta. .eoj.> on Monday November 11, 2002 @11:47AM (#4642805)
    Zope [zope.org] may be what you are looking for. It's hard to beat for ease of use, maintenance, separation of code from content, etc. Zope is scalable, can also do enterprise-like stuff, connect to RDBMS and all, use any number of authentication schemes other than its own built-in scheme (LDAP, *nix passwd files, NT domains, databases). I believe you can also run Zope behind Apache w/SSL, which should take care of your security needs. Give it a try, anyway.
    • Re:Zope (Score:3, Informative)

      by Etyenne ( 4915 )
      I had to work with Zope recently and had been quite underwhelmed :

      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.
      • 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.

        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.

        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.

        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.

        I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.

        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?

        • 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.

          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.

          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.

          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.

          I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.

          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)

        by Scaba ( 183684 )
        1. Easy management : yes and no. It's full of "objects", "class", "methods", etc. I can understand that; my client cannot.

        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.

        2. Separation of code from content : if you don't count DTML as "code", that may be true.

        Somewhat true, for DTML. However, Page Templates were recently introduced and they (mostly) separate code and presentation quite nicely.

        The zope.org site suck big time. The search engine lack option and return too many hit without any regard to revelance.

        Well, most search engines suck; that's why I use Google with the "site:" constraint.

      • 2. Separation of code from content : if you don't count DTML as "code", that may be true.

        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.

        3. Authentication scheme

        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...

      • Can you suggest something better? This is not a troll, I may be spending
        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.
        • It really depend on your particuliar situation and what you try to build. Which language do you know ? Which feature do you need ? The only real advice I can give you is to try a little a pilot and make sure all the features you need WORK and are well supported. Ie if you need LDAP support for your portal, don't trust the fact that John Doe said on a weblog that Zope support LDAP; go out and find out if the LDAP module work with current Zope version, if developpemet is still active, etc.

          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.
          • 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.

            • Just curious : what make filesystems independance such a deisrable feature for Web portal ? And what are "TTW capabilities" ?
              • TTW = through the web
                TTW is actually two separate things:

                • html textarea you probably know,
                • webdev/ftp remote access
                It is important because it enables access regardless of location, data gathering through xmlrpc/rss channels and, most importantly gives possibilty of setting up the permition system without giving people shell account and messing up with fiilesystem.

                ZODB is important because:

                • makes all that possible,
                • enables some really funky stuff with urls (remember acquisition ?),
                • makes room for some unique cataloging capabilities (remember ZCatalog ?)
                Cheers
  • Meh. (Score:3, Insightful)

    by Twirlip of the Mists ( 615030 ) <twirlipofthemists@yahoo.com> on Monday November 11, 2002 @12:03PM (#4642908)
    I thought portals went out with stock options, VRML, and "push."
    • Re:Meh. (Score:4, Insightful)

      by greenhide ( 597777 ) <`moc.ylkeewellivc' `ta' `todhsalsnadroj'> on Monday November 11, 2002 @12:38PM (#4643143)
      That only really applies to portals that tried to make money through banner ads, particularly portals that were too generalized or didn't have a specific audience or target ("Our target is Gen-Xers" is a good example of a target that was not specific enough).

      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:
      1. promoting certain companies outright, not through banner ads but with articles, detailed press releases, and product showcasing
      2. online catalogs, which sell items of great interest (not bumper stickers or t-shirts) to the customer
      3. actually charging the user for access
      Also, if you look at portals that are still in existance, most of them rely heavily on volunteer-provided content. About.com [about.com] is a good example. It's still going fairly strong, mostly because its costs aren't that huge (sure, they have to cover hosting costs, but in the long run, providing their own content would have been much, much costlier). Notice also that they employ two of the other "success techniques" -- they promote other companies (using sponsored links -- studies have proven that people have developed banner ad "blind spots", but they still pay attention to links, sponsored or not) and have links to purchase products.
      • Also (Score:3, Insightful)

        by greenhide ( 597777 )
        I completely forgot to mention the number one consumer of portals these days:

        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)

        On the other hand, industry specific portals are hugely successful. You're looking at one right now...

        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.
        • My definition of portal is a lot broader than yours, I guess.

          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.
        • by hdw ( 564237 )
          IM(nv)HO portal software is intended to create a single point of entrance to a wide set of content and/or applications.
          Often personally customisable for style and content.

          This includes the link collection stuff, like /., and other news or industry portals.

          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).
        • 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".

        • One thing to think about is that the front end of a portal could be like a newspaper front page or an intranet's main resources smooshed together, whatever fits the need the most, but to the developer, it is an architecture. One that allows writing small classes or scripts or programs to provide it's share of content to the end result. I don't really care if a user see's something as a portal or not, I care about my definition of a portal as an architecture for rendering content from a variety of resources. Of course, there are many websites and intranets that do this, but most not with an abstracted layer that does all the rendering to the client.

  • I would use vi, perl and postgresql, but that's just me :)
    • Wouldn't we all love to have an employeer pay for us to sit down and code our own full blown portal software. But for most cases, this does not make buisness sence. No offence but, homegrown software for something as complicated as CMS and as truly generic as portal software is like throwing money down a toilet. You might as well open up Emacs and start cloning SAP unsing python/MySQL.

      -Rupert
    • "Great. We want it done by next Monday."

      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.
  • Is this anything like Enterprise vs the Death Star [grudge-match.com]?

  • Document Management (Score:3, Informative)

    by dimer0 ( 461593 ) on Monday November 11, 2002 @01:32PM (#4643552)
    Document Management? .. Plumtree has this, Jetspeed doesn't. I see this as being a pretty large effort to get this built in. Sure, I can arrange gadgets all over the place, but managing the content on these pages is another huge task I don't believe Jetspeed addresses.

    • That is correct, jetspeed does not do content management but there are other jakarta packages that do (is it Lucene? I forget) and then you just have to write the portal that uses it.
  • Do you have to choose the same solution for both portals?
    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.
    • Do you have to choose the same solution for both portals?
      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.

  • If you have some $$ to spend, look into Oracle's Portal product that comes with 9iAS. The middle tier is Apache with their own module for PL/SQL and everything is web-based with the data stored in a back-end database. Very capable and fast to develop in, also very good support.

    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.
  • Not that there aren't some smart people here, but statistically speaking far more people are going to have used open source software.

    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.

  • Different people mean different things when they use the word "Portal", or "Content Management System".
    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.

This file will self-destruct in five minutes.

Working...