The value of portal software is not in the portal itself

Http://tb.blog.csdn.net/TrackBack.aspx? Postid = 547606

Portal products are a hot topic in the past two years. This year, the portal craze has indeed declined. Many people even think that the portal has passed the era of Enterprise Application Integration, the portal is no longer available. It is true that these ideas have their own principles. I believe that the value of the portal is definitely no longer the portal itself.

First, let's take a look at why a portal is required. In J2EE enterprise application development, components on the interface are deployed on the enterprise application server in the form of war packages, each war is simply a website oriented to a specific application. Basically, each application has the same architecture. For example, the navigation bar, logon interface, and permission management required by the artist. For a large enterprise, there are not only three or five such applications, but thirty or even three hundred such applications. Imagine that all applications have to do repetitive things, such as the artist and login. Even if you have SSO, it still cannot solve the embarrassing situation where users need to differentiate the content of different websites. So why don't we use portals and a unified interface to integrate all applications? Even if you have 30 war instances, they are only used as 30 customizable Portlet instances in the portal. They do not require additional, fancy art designs. Each application only needs a professional business interface.

The performance is no longer a problem for the portal, and the portal's Portlet has a local HTML cache mechanism. Recently, the popular Ajax technology can achieve the portal load as needed by the Portlet.

Okay. Since we do not deny the role of the portal, why should we use the jsr168 standard compatible portal? Yes, you can develop a portal by yourself and call war through JSP include. But note, why do we use J2EE for development? We use J2EE to standardize and reuse components. I am writing a Portlet now. If it follows the standard, I can temporarily deploy it in an open-source portal to debug it. And then purchase a commercial portal. In this way, no repeated investment is guaranteed to the maximum extent. Of course, we know that there is no 100% compatibility in J2EE, but there is another advantage of using compatible technology, you can directly purchase standard-compliant Portlet products from other manufacturers to integrate them into your own standard portal container.

In the end, the above ideas are still advocating portals. However, these ideas are still not the deciding factor for the portal to occupy the market. The value of the portal is not only reflected by a Portal Server.

IBM will never sell you a Portal Server. It will sell its content repository, CMS, integration suite, groupware, and so on. What really gives customers the most obvious value is these.

Therefore, Exo platform takes this into consideration when designing its own product development test. In the portal platform V2.0, Exo integrates CMS website content management, JCR Java content warehouse, WebDAV, Bi components, OLAP, Custom reports, and data mining, and groupware, email, schedule management, team collaboration, etc. Of course, any compatible Portlet, such as Jira's Portlet, can be integrated. Exo also uses CAs as the SSO framework. All these sub-projects are creating value for exo platform and for exo portal.