Oracle WebCenter Suite, a component of Oracle Fusion Middleware, combines the standards-based, declarative development of JavaServer Faces, the flexibility and power of portlets and runtime customization, and a set of integrated Web 2.0 services for developing context-centric, composite applications. Oracle WebCenter Suite offers the following key features:

• Enhanced support for standards-based portlet creation
• Expanded portlet consumption support for WSRP 1.0 and a preliminary version of WSRP 2.0
• JSF portlet bridge to expose JSF applications as WSRP portlets
• Content integration using JCR/JSR 170
• Runtime customization of JSF applications
• Leveraging of metadata management services
• Visual development environment integrated into JDeveloper
• One-click install

Build context-rich, customizable applications with Oracle WebCenter Framework WebCenter Framework supports the creation and execution of context-rich applications. To achieve this, WebCenter Framework augments the JavaServer Faces (JSF) environment by providing additional components, integration, and runtime options. In essence, the WebCenter Framework integrates capabilities historically included in portal products directly into the 'fabric' of the JSF environment – especially, the ability to bind portlets and customize the application at runtime. A complete, standards-based portlet development environment and business user tools support rapid creation of JSR 168-based portlets and deployment of WSRP 2.0-based portlet producers. Content is easily integrated and published using data controls built to the JCR/JSR 170 standard. Content repositories supporting the JCR standard can be configured and adapters are available for Oracle Content Database, Oracle Portal, file systems, and leading third party content management systems. In addition, Oracle JDeveloper provides a unified development environment for all of the framework pieces to simplify building your applications. Embed Web 2.0 into applications with WebCenter Services WebCenter Services include a complete set of Web 2.0 content, search, collaboration, and communication services that can be embedded directly into applications built with the WebCenter Framework. These services include:

• A content management solution for storing and managing files and documents (Oracle Content Database)
• A secure enterprise search application for locating and accessing data and documents stored within the enterprise (Oracle Secure Enterprise Search)
• A presence server and instant messaging service that enable users to see who is online and initiate communication via text, voice, or video*
• A voice option, offering a rich set of telephony infrastructure components*
• A discussion forum application for online, topical community discussions*
• A wiki/blog server for collaborative authoring of documents and sharing of ideas*

* Note: These features will be released shortly after general availability of Oracle WebCenter Suite 10g Release 3. Where can I find more information?

• Oracle WebCenter on OTN
• Oracle WebCenter software download (will be available shortly, look for 10.1.3.2.0)
• Oracle WebCenter demos and samples
• Oracle WebCenter documentation
• Oracle JDeveloper on OTN

That's awesome that I get to buy all those Oracle products and spend all that time getting it to work. Many kudos for your Marketing efforts. Bravo.

That's awesome that I get to buy all those Oracle products and spend all that time getting it to work. Many kudos for your Marketing efforts. Bravo.

In all fairness, I downloaded the Webcenter, and got those features working with fairly little investment of time.

In all fairness I'd like a constructive debate on when you should use these big products from big vendors? How do they compared to REST and Ruby On Rails, Python's Django, SEAM or anyother tool designed by and for developers. So many developers waste so much time on hyped up technology because some magazine or populars site like theserverside.com has an article on it. When should you really use portlets, WSRP or whatever else is the flavor of the day?

In all fairness I'd like a constructive debate on when you should use these big products from big vendors? How do they compared to REST and Ruby On Rails, Python's Django, SEAM or anyother tool designed by and for developers. So many developers waste so much time on hyped up technology because some magazine or populars site like theserverside.com has an article on it. When should you really use portlets, WSRP or whatever else is the flavor of the day?

That's a good question - why you should use them compared to REST, RoR, etc. I may bring this up to a top-level discussion sometime soon. As far as when you should use portlets, WSRP, etc., well... "when they're appropriate" comes to mind. I don't think anyone's saying you should go out an apply portlets as a one-size-fits-all solution.

That's a good question - why you should use them compared to REST, RoR, etc. I may bring this up to a top-level discussion sometime soon.

I would really like to have this discussion. When I reads the comments from forums like this I begin to wonder what types of companies and what types of project contributors are working on. I am an Architect/Developer (love discussion on what is an Architect but I digress) working in financial market for a large consultancy (and outsource) company. When I talk to clients they all want to protect their investments. They all want to go with new technology but they don't want to go too outside the box. Most are concern with making sure the solution can be supported 5 maybe even 10 years from now, that there is a community around it, and then there are the FURPS+ (Functionality, Usability, Reliability, Performance, Supportabiltiy, and Constraints)discussions. Every technology solution is not for every project. When someone says why should I pay for this or that, or why use Vendor vs Open Source, complex framework vs simple, etc these questions can only be answered in terms of non-functional requirements. At one level its fun talking about the solution soup in Java but at some point you must make selections based on project realities and client concerns. In fairness to Oracle, they have a good offering that is far superior when compared to WebSphere for example. WebLogic and JBoss have great products as well. I have found that some customer are open to discussing JBoss while others are just set on WebSphere, WebLogic, or Oracle for example. Then you have to provide solutions within those offerings. Maybe smaller projects have more lead way, mine typically don't. Thus for me, standards have some traction in that I can typically get an implementation from one of the major vendors that I might have to use. Thus I specialize in applyinig a/the standards and don't have to specialize in a vendor.

The Achilles heel that previous versions of Oracle Portal suffered from was that migration did not work. When QA approved your Portal (configuration, groups, permissions, Portlets, etc.) you couldn't trust Oracle's migration to properly migrate the entire Portal with all the settings that it depended on to your production portal. You had do a second round of QA on the production portal too.

The migration of earlier Oracle Portal versions has been overhauled and it works wonderfully in Oracle Portal 10.1.4, the production release for more than a year now. For Webcenter the migration is nothing but exporting and/or packaging a J2EE/JSF application and portlet/customization meta-data and deploying to another instance of the application server. So, it basically follows the life cycle of a J2EE app starting from development, test, debug, package, and deploy.

Migrating the binaries was never an issue. It was all the administrative settings that the Portal depends on - users, groups, roles, permissions, etc. Those had to be set up manually using web based tools, and they did not migrate properly. User customizations didn't migrate properly either. So if that is what you mean by portlet/customiztion meta-data then that will be a big relief. The best migration strategy would be to simply tar up the Oracle Portal installation directories and copy them to another server. That would guarantee that what passed QA was what was being deployed on the production server with no missing settings or binaries. That requires identical servers for development, QA and production, but that is a good idea anyway. The reason we couldn't do this is that we couldn't figure out how to change the IP address(es) the portal assigns during installation. We had scripts to back up and restore the portal onto the same server like that but the inability to change the IP address prevented doing this for migration.

We have Oracle 10.1.4 and we do have trouble with migration. It is never predictable. I wish the tar/untar or a repeatble packaging mechanism will be in place for content and meta data. Most of the portal products have the same problem. I did go through Web Center features, it is fascinating to go through all the standards based features. I am not familiar with Oracle ADF but I heard that it is needed to make the best use of WebCenter. I am not sure where webcenter and portal meet to provide a unified solution. Do I still go with Portal product for my enterprise portal requirements and use webcenter for typical application needs?

When 10.1.4 was released we checked with other Oracle Portal users who had tried that release to see if the migration problems had been fixed. They told us that there were still problems so we didn't move off of the old version (10.1.3 I believe). The project was eventually cancelled so the client never had to deal with migrating from QA to production.

Oracle Portal migrations between Dev, Test, Stage and Production have been reasonably clearly documented since Portal 10.1.2 (released in 2004) as we put a lot of work into this area due to customer feedback on Portal 9.0.4 (released in 2003). There are clear, automated processes for initial moving/reusing users and groups, changing IP addresses as well as subsequent incremental migration of elements. The main documentation can be found as per below links. Initial move: - Chapter 11 Staging a Test Environment from a Production Environment - (Link: http://download-west.oracle.com/docs/cd/B14099_19/core.1012/b13995/prodtest.htm#CHDHBJCH) - Chapter 12 Changing from a Test to a Production Environment - (Link: http://download-west.oracle.com/docs/cd/B14099_19/core.1012/b13995/testprod.htm#BHBGBJFH) Subsequent incremental updates: - Chapter 10 Exporting and Importing Content - (Link: http://download-west.oracle.com/docs/cd/B14099_19/portal.1014/b19305/cg_imex.htm#i1030999