If you were not able to attend the CM Professionals Summit in April, you can get the slides from the presentations here. Just be sure not to miss next time 
.
Related posts:
- CM Professionals Summit CM Professionals is holding its second Summit (press release)...
- CM Professionals Spring 2006 Summit On April 23-24, CM Professionals will be holding its...
- CM Professionals Summit – Boston 2006 I am back at work after attending the 2006...
- CM Professionals MA Chapter Meeting The CM Professionals Massachusetts Chapter will be holding a...
- CM Pros Spring Summit I am looking over the program for the CM...
Thanks for posting this Seth.
Looks like some interesting stuff. I got a chance to glance over the portal presentation. Passing fad? Hmm maybe as some of its incarnations.
Delivering static content just isn’t acceptable today. Delivering just your own content is not enough today. Look at the news industry. Yahoo is stealing the market from the major new websites. Today yahoo gets all of the feeds. People go to the Yahoo site and read what is relevant to them all in one place. There is no need to jump from site to site. Personalization and Aggregation are important. Portlet (not portal) is a weak, horrible standard.
We must move forward with standards for application aggregation. The specifications need to speak to both the container and the contained objects.
Anyway it all looks like terrific material, thanks for posting it. I love this blog; it’s an oasis of information.
In a recent presentation by Janus Boye and Tony Byrne entitled Portals: From Idea to Reality – the Dangers of the Current State of Portals in the Marketplace, portal is described and a current state of the technology is given. I think this presentation is excellent. I completely agree.
First the presentation points out that portal is not a simply an Intranet infrastructure; it is a framework for integrating applications and processes. It is applicable for many uses including internal and external sites/applications.
One of the problems with Portal today is that the name Portal is so widely used – but associated with diverse, sometimes incompatible definitions. Most of these definitions get very specific; the two most popular concepts of portal being websites like Yahoo!, and corporate intranets. These limited concepts of portal bias the mind and close it to the possibility of Portal as a general infrastructure of applications and even what is traditionally thought of as a Website. We no longer live in 1994, websites should be a composition of applications, not static pages.
I like Janus, and Tony view portal as a platform, a framework for the integration of applications and processes. This general definition of Portal opens up the concept to a wide range of uses.
Once we understand Portal to be a general infrastructure we can quickly see that it has the potential to provide a strong platform beyond what exists today in basic platforms such as J2EE and .Net. Organizations are looking for faster ways to move implementations from the developer desk into production. XP and Agile methods are recent attempts to introduce shorter iterations into the product lifecycle. The question remains; what is the application framework that supports this? Technology does not stand alone, neither does process. We require a platform that allows us to build small applications which can be easily deployed into a framework with other small applications on an iterative basis. When I say small applications I mean applications which are “service aligned†and handle a small set of closely related concerns. Such an application stands a chance at being well tested, and developed and deployed iteratively. Even moderately complex applications quickly outgrow the realm of testability and the possibility of truly iterative development. Through this approach [component-like applications] it is possible to build complex, composite applications based on simple, application components; individually developed and deployed, all with their own lifecycle. That is to say; the type of development called for by Agile, XP and other similar approaches. Portal, combined with a component-like application approach provides a strong solution for making such development possible and sustaining it over the lifetime of the composite application. Such approach also has addition benefits such as increased reusability of applications.
The current state of portal provides only a subset of the basic functionalities required to achieve this goal. JSR-168 provides only a Portlet specification but gives nothing in the way of portal container support such as access to inter-application communication. As portal grows to become a truly critical infrastructural component designed to support the goals of the XP and Agile like movements, a set of container services will need to emerge. Those who come together to forge the path of portal must put aside their desire to protect their current implementations and marginal competitive advantages in the name of advancing the cause lest it die before Portal really has a chance to come of age. That is to say, we must move Portal to its proper position by giving strength to the general definition both in terminology and in specification [through a broader spec which addresses both the application and the container].
The second point made in the presentation given by Boye and Byrne points out that Portal is immature. Sadly this is so. JSR-168 is now more then three years old and provides nothing more then the most basic guidelines by which Java based portlet applications can be built so that they can consumed by compliant portals. There is no standardization beyond these primitives. JSR (Java Service Requests) implies that this specification is targeted at the Java platform. We must move beyond Java if we are to truly make any real lasting impact. We should require a more verbose, event driven application lifecycle, inter-portlet communication, instance-able portlets, named/addressable instances, more declarative configurations, etc. Such capabilities should be based on language independent standards allowing for tooling to take place.
Portal may very well be at the cross roads of critical infrastructure and “has-been conceptâ€. There is no question in my mind that if the current state of Portal does not evolve it will die, yet something will take its place; as a vacuum still exists. Portal has the potential to completely commoditize the application server space if its course is corrected. We must move the container services up the stack and provide a stronger platform for which we can develop and deploy applications to.
A portal which will be successful in the future will (hopefully in accordance with standards) provide a provide container based services, and be based on a highly pluggable architecture. One of the great black eyes of the Portal today is “Performanceâ€. Let us lay this sorry argument to rest today. It should be with minimal effort that integrators can take the portal infrastructure down to basics and build it back up based on declarative configuration and plug-ins. Performance is often not defined by approach, but rather topology. We must allow for integrators to plug in the topology that works for them. I believe that the performance issues many people find with Portal today stem from the assumptions under which the technology was developed. As the concept is becoming clear and Portal is seen as framework, let us go back and build it based on these new general assumptions. Today too many portals try to meet one or more of Portals specific definitions making it a horrible candidate for the general case.