The recurring interportlet communication dilemna

First the we need to shorten the name "interportlet communication", I propose IPC.

Often people on our forums talk about IPC. The thing is that this is always ambigous in the sense that they are not talking about the same thing. After all what is the exact meaning of the term ? It loosely means that portlets communicate between themselves. Well if you read the JSR 168 specification it is obvious that the component model they have built works isolated, meaning that a portlet has access to information about itself or can trigger events that will affect itself.

So you can see on our forums conversations that looks like :

- we absolutely need IPC
- what if you put the object in the application scope of the session
- what do you mean ? I want to provide a link to another portlet
- ahhh.... ok sorry

It shows that people need IPC, because in the real world portlet never work alone and they need to exchange some kind of information. But before IPC, before all they need names to have non ambiguous conversations. Even internally we have the same issues, for instance here is an excerpt of my IM conversation with Roy :

julien: why do we need to talk with Ben ?
julien: I don't see the reason
roy: we should tap him for ipc too, no?
julien: IPC ?
roy: no
julien: it should be possible to do it without JBoss Cache using some tricks with the HTTP session replication (which uses JBoss Cache under the cover)
roy: then we dont talk to Ben
roy: most vendors have their own api for ipc
julien: it depends what you call IPC
julien: they have IPC API for events
julien: not attribute session sharing
roy: this seems to be the ipc that people want... not the session hack
julien: or for do cross linking
julien: so what do you call IPC ?
julien: at the end perhaps we don't speak the same language
roy: portlet A action triggers reponse in portlet B
julien: yes
roy: yes. i speak spanish, u speak french.
julien: JBoss Cache is not going to help you doing cross linking
julien: JBoss Cache replicates object
roy: implementing cache, couldnt you get all the above forms of IPC to work?
julien: it does not make linking
julien: we really need to define a language
julien: let's define
roy: we need to define ipc
julien: IPC/xlink
julien: IPC/event
julien: IPC/session

You see what I mean ? I am a big fan of naming concepts, so then people can refer to it with a simple name. It is how we started to put names on those concepts.

 

So far from my personnal experience, I have seen three forms of IPC :

• IPC/session : portlet sharing objects, this is possible today by using the PortletSession provided during the request and using the application scope. However there are limitations in the sense that the portlet need to be bundled in the same application to be capable to share objects.
• IPC/xlink : A portlet provides a link to another portlet : this is not possible today. I have a hack in mind to resolve that but this is really an hack that should work with any container :-) .
• IPC/event : A portlet is capable to create events that are consummed by other portlets.

I don't pretend to know all the form of communication between portlet, perhaps I am missing some others.

 

Finally in our case the firts conversion could have looked like :

- We need IPC/xlink
- ok, why don't you try IPC/session rather ?
- no it is not what I need
- ahhh... ok sorry

Ok the conversation ended up the same but at least the second guy did not look stupid.