Earlier this week, BEA unveiled BEA WebLogic Portal 7.0. WL Portal is a J2EE-based platform aimed at simplifying the development, deployment, and management of enterprise portals by providing frameworks, services and tools that deliver features such as personalization, skins, data integration, portlet-based UI development, workflow, etc.
J2EE is becoming the mainstreem technology for implementing portal platforms, with Broadvision recenlty announcing that the next version of their portal platform will be developed on top of J2EE.
Along with WL Portal 7, BEA has also launched a website for portal developers at: portalsolutions.bea.com
; I wonder if it was written with WL Portal. :)
Read BEA Delivers Industry's First Unified Portal Platform
Related read Portal Trend Takes Root in CRM Terrain
Looks like it is written in WL Portal. It's using the WebFlow tool as well. I can tell by the URL.
As far as I can see they have taken all their existing products WLI, Portal, Application Server etc and put them under one umbrella called Platform.
Yeah they announced Platform as everything under one umbrella at BEA eWorld in February. This looks like they fixed some bugs in Portal 4.0 (which were many) and added 3 points so everything has a seven at the end.
I'm just wondering how much it will cost for a license on a 4 processor machine... ;)
Unable to connect to portalsolutions.bea.com (connection refused). Has TheServerSide reached a userbase large enough to /. sites when announced? :)
Is it possible to have URLs longer than that.
The URL for navigation are like a paragraph long.
Is it possible to have URLs longer than that.
The URL for navigation are like a paragraph long.
Can you ever be any more DUMB than this? How much do they pay you if you monitor their URLs?? Or do the URLs bite you if they are too long for your narrow perspectives??
Has TheServerSide reached a userbase large enough to /. sites when announced? :)
maybe they should have hosted it on oracle for better berformance >:)
Does anyone know what is going on with JSR 168 (Portlet Specification)???
My company is planning to make available to our customers a set of portlets to access our repository directly from their Intranet. But as things stand now, we have to implement a set of portlets for every vendor with a portal offering (Sun, IBM, Oracle, BEA, ...), if we want to reach as many people as possible. I think this is a showstopper for many companies.
According to the JCP website, below is the timeframe for the Portlet API:
Portlet API Spec community draft: 08/2002
Portlet API Spec public draft: 10/2002
Portlet API final draft: 12/2002
Reference Implementation & TCK: 01/2003
Looks like an interesting product, although I also wonder about the relation between BEA's "portlets" and the corresponding JSR.
Was it just me, or where some of the pages incredibly slow to load in the portal site?
Click here (portalsolutions.bea.com)
to get some nice debugging messages.
I know you can do this with every website, I thought it would be more "human-friendly" :-)
We've been working with the BEA Platform 7.0 and it is pretty impressive. I'm not sure if I am just impressed by the size (it is huge) or what, but if you can't tell where they are headed, it's pretty obvious that they are gearing up for the next round of the platform battle, and it looks like they have a good shot at getting there. Product integration, tools support, working installs, a platform vision and reasonable tech support ... all you need to build a platforms company ;-).
We've been BEA Portal/Commerce server customers for almost a year now. Make sure that you'll be able to use a good bit of it. Otherwise a more home-grown approach will probably be more cost efficient.
We haven't been too impressed with tech support, especially recently.
There is a lot there, but unless you need some of their more specific aspects of the portal, using Struts and writing your own user/group/property library would probably be just as good, if not better.
Since you seem to have some experience with the Portal and especially the Commerce features, I have a question for you.
If you are interested in using only a small part of the Portal, let's say the shopping-cart in Commerce, would that be possible and how should that be done? Is it possible for example to just put the commerce .jar in the lib folder and call the API directly to integrate the shopping-cart into your app, and not having to run the full Portal app, or is the Portal more of an all or nothing thing?
It's not an all or nothing thing, but you'll have to test out to make sure your configuration works (documentation/support wasn't too helpful on this). I just recently attempted to reduce the number of .ears/apps that are deployed (since they come right out of the box). It's doable, just a bit of doublechecking to make sure a jar you just deleted doesn't affect your functionality.
Make sure you keep the web apps that allow you to sync with the e-Business Control Center.
The commerce app is the piece we've used the least. It's good for a single shop, but not so good if you want to handle multiple catalogs. We also had issues when trying to figure out how to sell non-book items, say a variable amount of a chemical substance.
We ended up using Notes/Domino for a small shop we did recently, but we needed multiple catalogs depending on which group you were in, and commerce couldn't do that.
The commerce piece seems to be nice if you need to set up a single shop quickly. It does taxes, shipping, etc. It seems to be about the equivalent of phpshop, except in Java. Another thing that wasn't so good for our internal stuff is that it requires credit card, you can't easily make it use a purchase order, or an account number of your own. I mean, you could, but why modify their code for $57,000 a pop?
Steve (& others),
Our (scientific) company has been struggling with BEA Portal Server 4 for almost a year now. We have a very small operation (2.5 developers) but ambitious goals which would make use of many of the features. Our experience has been that the learning curve is so extensive & the product so buggy & support rather sluggish that we are getting nowhere. I keep getting the feeling that we would do better just writing servlets & jsps or ColdFusion MX rather than continue to struggle with this (highly expensive) behemoth. What are your thoughts as to what can be achieved with PS4 or 7, how many developers are required, how much support? Does PS7 offer extensive enough enhancements to come to our rescue? Thanks!!
How experienced are your developers? I'm a mid-level developer and it took a while to grasp things. The theory is that you could take a JSP developer and have him/her do write the apps just in JSP. We found that we needed to integrate with our ERP, which wasn't a big deal, but you need more than JSP to do that.
What I've found is that support is good on small/medium issues, but if they ever have to deal with something hard, it either
a) Doesn't get picked up as a ticket
b) Never gets escalated
c) Involves me solving the issue by trial and error and then telling them what I did.
For the really hard stuff, expect to hire a BEA consultant and have them sit on the phone to support while they learn Portal on your dime. That's really the only way to escalate something.
The stuff isn't rocket science, but there's a lot there and it takes a while to understand the philosophy behind their approach. Things make sense once you figure it out, and I'm sure there are a few pieces that they write very nicely, but the user/group/properties aren't that impressive, which is mostly what we're using, as well as WebFlow, but that's just a Model 2 Struts-like tool. If you have need of a rules engine it may be nice. I don't know.
PS7 from what I've gathered is updated to work with WLS 7.0 and have a few bug fixes. Nothing super-duper, though.
So if you find you need several pieces of the PS, then it's not a bad deal. But just expect to take some time learning it. There's a lot there, and you gotta take the time to know your server. If you feel that you're getting nowhere, I'd hop on JBoss and start writing things from scratch.
For now we are sticking with Portal. We're beginning to see what exactly we may need of it in the future.
Please feel free to post questions to the newsgroup:
We are always willing to help out, especially if you have searched the archives first! ;-)
WLP 7.0 delivers lots of productivity improvements over 4.0 (end-to-end wizards for creating portals and portlets for example). WLS 7.0 also offers better hot-deploy so you don't have to keep bouncing the server. We've mainly concentrated on stability and better WLS integration, particularly for WebServices and the WLW tool.
There are also new P13N samples for using the RulesManager EJB, the expression package and combining the RulesManager and the DocumentManager to deliver rules-based content (showing you the code at the EJB API-level).
The documentation has also been improved (ongoing). I agree that there *is* a learning curve, so don't be shy to post any questions to the newsgroup about architecture or how to structure your apps.
As you can tell from the JavaDoc, there is a lot of power to exploit:
There is everything from Portal/Portlet rendering, site flow, rule-engine, entitlement, content management, commerce, user management, discounts, campaigns etc. etc.
(Staff Engineer, BEA)
I found this nice tutorial on building a "Hello World" Portal with WLP 7.0:
Maybe you can give me a heads up on why I have to go in, delete my data sync rows, restart, and then re-sync after re-deploying my application. Happened today. Not the first.
Can we post that question to the BEA public newsgroup please, and I'll be happy to help.
Here's a piss-take on BEA and IBM pricing from the JBoss site.
Ok, I have Oracle bias, but here me out...It amazes me how blindly people are when purchasing technology. BEA comes out with a Portal product and all of a sudden they are the Portal leaders. For instance, "portlets", as if it's something new...Oracle Portal came out way before BEA, and so didn't Oracle's "portlet" technology...hmmmm. BEA has these great "skins"...Oracle Portal has templates...hmmm. Oracle Portal is ALOT more inexpensive...compare $50,000 per processor for BEA with Oracle's $20,000 per processor. BEA comes out with a "platform" including the app server, WLI, Portal. Oracle's platform includes Portal, Java Container, Toplink, Wireless, Reports, Forms, Web Cache, Discover (adhoc reporting), Personalization, Integration, Clickstream Intelligence, an LDAP server, etc. I personally like the tag libraries for email, file uploading, and more.
Oh yea, Oracle Portal includes basic form building and report building right in Portal...try that with BEA.
Ok, that's my take on BEA Portal
Eric: "BEA comes out with a Portal product and all of a sudden they are the Portal leaders. For instance, "portlets", as if it's something new...Oracle Portal came out way before BEA, and so didn't Oracle's "portlet" technology...hmmmm"
There are two main reasons: Oracle's market share in the J2EE space is much less significant, and the current Oracle app server is the third completely different implementation that they've released.
Eric: "Oracle's platform includes Portal, Java Container, Toplink, Wireless, Reports, Forms, Web Cache, Discover (adhoc reporting), Personalization, Integration, Clickstream Intelligence, an LDAP server, etc."
I'm not sure what your point is. BEA has long had portal, TopLink integration (they were the primary platform for TopLink), WAP support, page caching, personalization and integration.
True: They don't have a database, a database-centric forms product, or a database-centric reporting tool.
But no one is busy knocking Oracle here. The thread was about a new release from BEA, and BEA gets covered because they happen to be the current market share leader in J2EE app servers.
I installed the latest Oracle 9i portal and it apparently is running off of JRE 1.1.7. Isn't this a bit out of date?