Does the BOOK discuss about different AppServer supporting Portals

[Ko Ko Naing]

I just would like to know whether there is any section in the book that discusses about the different features of portal-based application servers like WebLogic Portal, Websphere Portal, ATG Portal and so on...

I have one project in my hands, which is based on ATG Portal Application Framework and wondering if the book helps me in this project...

Thanks...

[somkiat puisungnoen]

This is good for you .

Editorial Reviews
Book Description

How do developers bring existing applications into a portal? How do developers integrate content management systems and search engines with a portal? And how do developers get started with the Portlet API? Jeff Linwood and Dave Minter show you how to solve these real problems in Building Portals with the Java Portlet API.

This book describes the new Java portlet API, including security, portlet life cycles, and portlet interaction with servlets and JSP. The examples will work on any portal that complies with the JSR-168 portlet API. Several example portlets are developed to give you hands-on portlet experience. You'll even learn how to port existing servlet and JSP applications into a new portal environment.

The authors also discuss Single Sign-On (SSO) using Kerberos and the GSS-API, syndicating content with RSS, and integrating a charting solution with JFreeChart. Other topics covered are the open-source Apache Jakarta Lucene search engine, personalization, portlet configuration, portlet preferences, and Web Services for Remote Portals (WSRP). XDoclet is also used throughout portions of this book.

More information

[Nicholas Cheung]

But what actually means by Java Portlet API?

Does it refer to SUN's? In fact, does WAS/OAS support the same set of APIs?

Nick

[Nicholas Cheung]

Ko Ko,

You can find more info here:
http://www.apress.com/book/bookDisplay.html?bID=362

and download the TOC here:
http://www.apress.com/ApressCorporate/supplement/1/362/1590592840-2055.pdf

Nick

[Pradeep bhatt]

Originally posted by Nicholas Cheung:
But what actually means by Java Portlet API?

Does it refer to SUN's? In fact, does WAS/OAS support the same set of APIs?

Nick

Yes it is from Sun. check this
www.jcp.org/en/jsr/detail?id=168

[somkiat puisungnoen]

In this book have example of Apache Pluto that Pluto is the Reference Implementation of the Java Portlet Specfication. The current version of this specification is JSR 168

[Ko Ko Naing]

Originally posted by somkiat puisungnoen:
Pluto is the Reference Implementation of the Java Portlet Specfication.

Well, I'm wondering if Sun got its own RI for its Java Portlet Specfication or not... It's pretty wierd that Sun is referring to one of Apache's projects as its RI...

[Nicholas Cheung]

Sun's RI, even it exists, is only good for learning concepts of portal, however, we wont use it in production environment unless we use SunONE servers.

Nick

[K Huang]

Nick:
Do mean SunONE servers is the only kind using Java Portalet API ? WAS and others have their own API ?

[Nicholas Cheung]

Every container will have its own set of API implementations. The APIs for developers are the same, but every vendor might add their own to fit in their application servers.

Just think of SUN has defined JCE for security implementations, but lots of open source projects extend it, and add more functionalities.

Nick

[Ko Ko Naing]

Originally posted by Nicholas Cheung:
Sun's RI, even it exists, is only good for learning concepts of portal, however, we wont use it in production environment unless we use SunONE servers.

Nick

So do u mean that Sun could refer to any open source implementation as RI for its product? How can Sun ensure that Pluto implementation is exactly compatible with the Portlet API specification? Or there should be some kind of QAs from Sun, who analyze the quality of Pluto?

[Nicholas Cheung]

No. I mean that SUN's APIs is the backbone for other vendors. Say, IBM will implement every method defined in SUN's interface, but then it will do some enhancements (just like what EJB stubs did).

And as SUN's RI is just a preliminary container, you wont use it in production environment, isnt it? Just like you wont use RI as EJB container in production.

Nick

[Lasse Koskela]

Originally posted by Ko Ko Naing:
So do u mean that Sun could refer to any open source implementation as RI for its product? How can Sun ensure that Pluto implementation is exactly compatible with the Portlet API specification? Or there should be some kind of QAs from Sun, who analyze the quality of Pluto?

In order for Pluto to be allowed to claim compliance with the JCP's Portlet API specification, it needs to pass a TCK (technology compatibility kit) developed by the expert group in charge of running the JSR. At least that's the way it works for most JSRs.

[Nicholas Cheung]

Lasse,

In such sense, all open source projects that claim to be JSR XXX compliant would need to have such *testing*?

Nick

[Ko Ko Naing]

Originally posted by Nicholas Cheung:
Lasse,

In such sense, all open source projects that claim to be JSR XXX compliant would need to have such *testing*?

Nick

I think only the projects that wants to be RI implementation of Sun's published API specification need to pass TCK... All open source projects that claim to be JSR XXX compliant are not needed to pass TCK, I guess... If so, the certain JSR expert groups will be very busy with just for TCK...

[Nicholas Cheung]

If so, the certain JSR expert groups will be very busy with just for TCK...

That's true. In fact, I guess the testing should not be limited to open source projects. All commerical products should pass the test as well, otherwise, how come they can say their ASs are JSR XXX compliance?

Nick

[somkiat puisungnoen]

Originally posted by K Huang:
Nick:
Do mean SunONE servers is the only kind using Java Portalet API ? WAS and others have their own API ?

Sun Java Portal System

[Nicholas Cheung]

I am quite sure that IBM, in addition to JSR 168 and 170, has implemented a set of interfaces and functions that does not include in these specs.

I believe SunONE will do the same because the portal support for JSR 168 and 170 is really limited.

SUN's API is just the most common APIs for portal access, but they are not user-friendly enough. As I said in the example, SUN APIs provide JCE for security, however, we usually need a third party to do the real things (like Cryptix, OpenSSL, etc).

Nick

[David Ulicny]

I am quite sure that IBM, in addition to JSR 168 and 170, has implemented a set of interfaces and functions that does not include in these specs.

You could be sure Nicholas, if you will start developing a portlet you could choose, if it should be JSR 168 portlet or IBM specific.

[Nicholas Cheung]

You could be sure Nicholas, if you will start developing a portlet you could choose, if it should be JSR 168 portlet or IBM specific.

If we use IBM portal APIs, we could make use of the Global context (which implemented by IBM already) to make communication between portal applications possible.

Just we dont wanna use such vendor-specific implementation.

Nick

[Axel Janssen]

question: Do you consider http://www.gridsphere.org/gridsphere/gridsphere a viable alternative for WAR Portal Server regarding "IBM portlets"?

[Nicholas Cheung]

We do consider GridSphere before, however, it is an open source product, which is not accepted by our customer for this project.

We might need to wait for IBM to release the portlet server 5.1 (with APIs) to cater these needs.

Nick