Is there any PortletContaner API ?

[Kanchan Kumar Dey]

We know about Portlet API (jsr 168 & 286) which standardizes the communication with portlet (between portlet and portlet container).

Do we have any API for portlet container, so that there is a standard way to access the instance of Portlet container, invokes methods on portlet container without knowing which vendor has developed it? Till now i think a Portal and portlet container are tightly coupled and a portal cannot be easily deployed with any portlet container without knowing its interface methods and then changing code in the portal itself?
If this is so, I think we are not complete with jsr 168 & 286.
(I have seen source code for pluto portal and pluto portlet container. They are tightly coupled.)

Please correct if I am wrong?

[Cameron Wallace McKenzie]

What you are postulating is no different from how Servlets and JPSs work. So, if we are out of step with JSR168 and JSR286, then JSF is out of step, and Struts is out of step, and Servlets are out of step, and Cocoon is out of step, and JSPs are out of step, and.....

-Cameron McKenzie

[Kanchan Kumar Dey]

Thanks for the reply.
But not convinced completely.
Firstly I did not get my answer that whether Portal and portlet container is tightly coupled or not? Is there any Portlet container API?

2ndly, (if I am not wrong with my doubt,)with ref. to your response:
1) Servlet, jsp itself is an API and one can develop and deploy there own servlet/jsp web app. independent of any servlet container? Then why not there be a API for portlet container?

2) Web app. developed with struts are tightly coupled and there is no replacement for struts without changing codes on other parts. It is individual's choice to go for such design, coupling or not.

3)I don't know about cocoon or JSF. But thing is that I would always like to design portal which can run on any portlet container. Otherwise my effort in developing a portal with Apache pluto portlet container will go in vain if i want shift to any other better portlet container. A portlet container API only needs to support few statndard methods which are always ultimately triggering the methods on portlets itself.
A portlet container is in a different layer than portal itself and they should not be tightly coupled.

[Kanchan Kumar Dey]

4) Just to add to my earlier reply,
A portal and portlet container are developed by different stake holders. They must not know the details beyonds some contracts given by an interface(Portlet container API). Otherwise one has to develop both Portal and Portlet Container togetherly (and in effect implement another RI for jsr 168 & 286).

[Cameron Wallace McKenzie]

1) Servlet, jsp itself is an API and one can develop and deploy there own servlet/jsp web app. independent of any servlet container? Then why not there be a API for portlet container?

JSR168 is an API, just like Servlet and JSP.

You always need a Servlet container to deploy a Servlet/JSP app. In exactly the same way, you also need a portal server to deploy a portlet application. There really isn't any difference.

A JSR168 portlet can run on any portal server that supports JSR168 - which is pretty much every one: JetSpeed, Pluto, WebSphere, Liferay, OpenPortal, etc.

I'm not exactly sure what you want, but I have a feeling it's already there.

You can develop a portlet, and deploy it to any portal server. You don't need any knowledge of the portlet container to do this.

-Cameron McKenzie

[Kanchan Kumar Dey]

Yes true. You are talking about jsr 168 & jsr 286 and portlets...
A portlet container is a RI for jsr 168 & jsr 286 and any portlet compliant to that can run on any portlet container. True.

But I am not talking about portlet container <=> portlet communication. am talking about Portal <=> Portlet container communication.

A Action or Render request is received by a Portal (which is nothing but a web application with good CMS). Portal call methods on portlet container and in turn portlet container calls methods on portlet. Now we know from jsr168&286, what method a portlet container calls on portlet and so when and what we need to implement in a portlet. But jsr168 and jsr286 does not clarify what method a Portal calls on portlet container. So, if we intend to develop our own Portal, we need to look for that vendor specific portlet container's documents or need to dig the code to find what method to call on portlet container and how to get an instance of the portlet container etc.

I am saying we must have an API(portlet container API) so that we can develop our Portal without any vendor specifc knowledge of any Portlet container and can employ any Jsr168 & jsr 286 compliant portlet container for our purpose. Do we have that? If not, then we are not complete with JSR 168 & Jsr 286,we need one more API atleast.

[Kanchan Kumar Dey]

Just to add to my earlier reply...

Portal<==========>Portlet Container<=========>Portlet
|_ _ _ _??_ _ _ _ _ |_ _ _ Jsr168 & Jsr286 _ _ _ _ _ _ _ _ _ |

[ June 09, 2008: Message edited by: Kanchan Kumar Dey ]
[ June 09, 2008: Message edited by: Kanchan Kumar Dey ]

[Cameron Wallace McKenzie]

can develop our Portal without any vendor specifc knowledge

I've been developing JSR168 portlets for years, and deploying them to a variety of portal servers without any knowledge of how those portal servers are implemented.

I think we have what you are asking for.

So, if we intend to develop our own Portal, we need to look for that vendor specific portlet container's documents

What do you mean "develop a portal?" You want to develop your own portal server, like a new JetSpeed or WebSphere or Pluto? Or do you just want to deploy portlets. You can deploy JSR168 portlets to any portal server, and they will behave the same way. Again, no need to know how IBM or BEA implmented their portal. Nor should you know. It's not needed.

What is it you want to do that you can't do already?

-Cameron McKenzie

[Kanchan Kumar Dey]

I know that one can deploy jsr168 portlets to any portal server and I too have mentioned that no. of times(A portlet container is a RI for jsr 168 & jsr 286 and any portlet compliant to that can run on any portlet container. True. - extrats from my last comment).

Perhaps you are not reading my comments properly. From the beginning, I am only concerned about the Portal<=>Portlet container communication and not PortletContainer<=>portlet communication.

Yes, my intention is to develop a new portal like JetSpeed or WebSphere or Pluto and for that we need to know which portlet container I am working with and interface does it provides. There is no standardization on this part. One either need to go through the vendor specific documents or code base, to understand how to get an instance of the portlet container, and what methods are supported.

There could be many reasons to create a new Portal and not to choose Jetspeed, websphere etc.. But that is a diff. subject.

I repeat my question. If I want to develop my Portal(which is just a CMS like web application), can I do that without knowing which portlet container I am working with.
say, I develop a "MyPortalServer" which works with Pluto Portlet container.
Can I make it(MyPortalServer) work with Jetspeed portlet container or webspehre also without changing any code.
[ June 10, 2008: Message edited by: Kanchan Kumar Dey ]

[gurusamy jeyaram]

Hi Kanchan,

We are in a similar situation like you were in.

How did it go?

Did you write your own portal server and embedded a portlet container like Pluto or OpenPortal Porlet Container?

Regards
Jeyaram

[Kanchan Kumar Dey]

hi gurusamy,

Thing is that I had never into developing Portlet server. I was just studying and raise the question as I find it important issue needs to be addressed properly..

Anyway to help you out...

Either you can develop your own Portlet Containet after creating a Protlet Container API..Hope may sun in future also incorporate this...

Or you can create a Layer (Implementing a kind of Portlet container API) which in turn talks to the different Portalet container as configured or asked for...something like JDBC layer.

Your Portal (a web app. with good CMS) shall talk to this layer, and this layer shall talk to the actual portlet container on which it is deployed or configured with.

The layer must be implementing the different communication protocol vis~a~vis portlet container.

So this layer works as a bridge to integrate your portal with portlet container and in turns provides a abstraction which provides a uniform interface to all portlet container.

I hope this much is clear to understand what I am trying to say.

[gurusamy jeyaram]

Hi Kanchan Kumar,

Thank you very much for your reply.

It helped clarify few doubts.

Regards
Jeyaram