Discussions

News: An implementation of inter-portlet communication

  1. Michelle Osmond has posted a library for facilitating inter-portlet communication, a task that the current portlet specification (JSR-168) supports but doesn't actually address.

    There are limitations to the process, the most severe being that the intercommunication can only happen between portlets hosted in the same web application and that portals that cache content might hide changes (caused by messages) until a refresh is done.

    That being said, however, the fact that the problem has been addressed in a library might be the first step to seeing a formal solution in the next Portlet JSR. What do you think?

    Threaded Messages (19)

  2. Is there anything "shared" across portals that are in different web applications? For example, will they have the same portal session ID? Anything?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  3. It depends on the portal implementation.

    Tomcat 5.5 has been modified to accept to put the session ID cookie on the root path in order to make session handling work in a better way.
  4. From a spec point of view nothing is shared. The session Id may be different, and the sessions themselves are different, as with regular servlet apps.

    One thing some of our partners have done is use the Subject from JAAS, to store data that should be always accessible as "credentials". Not pretty, but works, and the Subject is the same object regardless of which portlet/web app access it.
  5. There are a number of issues that have to be resolved for inter-portlet communication. I don't know if a library like this really goes very far towards defining anything for the next JSR.

    One of the big issues will be order of execution. When the portlet being interacted (is that a word?) with sets some sort of state/data for the other portlets to pick up that's a relatively easy scenario. The particulars of how this data is namespaced, etc. isn't that big of a deal. But what if a portlet that is not being interacted with sets some new state? Maybe it's pulling data from a remote source and that affects other portlets on the page. You could get into a situation where some of your portlets are displaying data based on old state and some on the new state. That's where it gets interesting.

    Do you cause a full refresh at that point? How is that decided? How do you know if you need to? Portlets might tell you what data/state they're interested in and then you could determine if any portlets are interested in the state that changed and then do the redraw or invalidate their caches, etc. Or do you just not allow the non interacting portlet to update this shared state?

    I couldn't tell from the documentation if there was any provision for this sort of scenario.

    -Mike
  6. You could get into a situation where some of your portlets are displaying data based on old state and some on the new state. That's where it gets interesting.Do you cause a full refresh at that point? How is that decided? How do you know if you need to?
    Where do they get data for an old state, if there is only new data available?
  7. You could get into a situation where some of your portlets are displaying data based on old state and some on the new state. That's where it gets interesting.Do you cause a full refresh at that point? How is that decided? How do you know if you need to?
    Where do they get data for an old state, if there is only new data available?

    I think it can be the case when two portlets are rendered on the same page, you have no garantees in the order in which they will be rendered by the portal.

    For instance on first render portlet A put ("counter", 0) in session and portlet when then portlet B is rendered it gets the 0 value.

    When you refresh the page, portlet A will increment the counter but if portlet B is rendered before you will get 0 and not 1.

    The example is stupid but I hope it shows you how you cannot rely on the session sometimes.

    Normally my opinion for that kind of session usage is that the objects should be put in the session when the action phase is triggered by the container. Rendered portlet should only use the objects stored in the session.
  8. That's why you should only make state changes in the processAction method. If you change state during a render, for any portlet, then obviously the results are not going to be good.

    Also, this library doesn't solve what we want, so I hope somebody helps the guy fix it. We need this style of inter-portlet communication, but without the nasty requirement of putting the cooperating portlets into the same web-app.
  9. We need this style of inter-portlet communication, but without the nasty requirement of putting the cooperating portlets into the same web-app.

    We've got a number of Weblogic Portal customers using Coherence to do web-app-to-web-app data sharing (obviouly most/all of them are also clustered deployments).

    I'm trying to figure out how the API would support a simpler and more standard way of plugging in a solution for the "share data across portlets in different web apps" problem. For example, with regular web apps it's a bit easier because we can drop in session management into almost any container, but with portlets, it's a lot less clear if that same approach will work.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  10. We use Tangosol coherence..[ Go to top ]

    We used Tangosol coherence for InterPortlet Communication among multiple portlet webapps..

    Quite easy to do with with WebSphere Portal as all Portlets (even in different war files) share the same SESSIONID (note, different per web-app realms but has the same id). The only side effect is that one has to disable portlet caching in order to make it work, then - there's the problem w/ portlet execution order.

    It would be nice if there were some sort of event driven layer exposed by the container to all Portlets (even in different war files), IBM had some tricks in regards to Inter Portlet Communication by using WSRP.
  11. JMS[ Go to top ]

    In another note, using JMS might also be a solution..

    A Pub/Sub approach if it's a Master Portlet / Slave Portlet scenario.

    On the render phase (doViews) - it will still be useful for the portlets to receive change messages (for example, to invalidate some view data and repopulate it with a full model lookup).
  12. We use Tangosol coherence..[ Go to top ]

    We used Tangosol coherence for InterPortlet Communication among multiple portlet webapps. Quite easy to do with with WebSphere Portal as all Portlets (even in different war files) share the same SESSIONID (note, different per web-app realms but has the same id). The only side effect is that one has to disable portlet caching in order to make it work, then - there's the problem w/ portlet execution order.

    Hi George, any way I could pass some ideas by you via email? I'd also appreciate any additional feedback you have from the approach that you took.

    Things I've been pondering:

    1) Could any portlet add a cookie that all portlets could "see"? It could be as simple then as generating a UUID and stuffing it in a cookie whose name has been pre-agreed-upon by the application as a whole.

    2) The ordering issue, when it exists (portlets being rendered potentially in parallel, I assume) sounds somewhat unsolvable (in a generic way) from my reading of the 168 spec. Is that your take?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  13. One of the big issues will be order of execution. When the portlet being interacted (is that a word?) with sets some sort of state/data for the other portlets to pick up that's a relatively easy scenario. The particulars of how this data is namespaced, etc. isn't that big of a deal. But what if a portlet that is not being interacted with sets some new state?
    From a spec point of view portlets that are called in the render phase may not change data, so any portlets doing that are outside the safe confines of well-defined behaviour.
  14. One of the big issues will be order of execution. When the portlet being interacted (is that a word?) with sets some sort of state/data for the other portlets to pick up that's a relatively easy scenario. The particulars of how this data is namespaced, etc. isn't that big of a deal. But what if a portlet that is not being interacted with sets some new state?
    From a spec point of view portlets that are called in the render phase may not change data, so any portlets doing that are outside the safe confines of well-defined behaviour.

    That's a good point. If you restrict it to just allowing the portlet that initiated the request to set shared data then you're probably okay.
  15. Can we call another j2ee application (servlets,jsps and ejbs) from one portlet? (may the portlet may be a separate and diffrent from that web/J2EE application)
  16. Yes, in addition portlet containers are built on top of servlet container, so when you access a portlet it is always in the context of a servlet request serving.

    If a container is correctly implemented it should propagate your subject identity to the layers you call like EJBs.
  17. It is high time that the next JSR168 version started talking about the behavior of the portlet containers with respect to the portlets. In most cases the limitations with the JSR168 portlets are accentuated because of the limitations of the portlet containers. Issues like session sharing, inter-portlet communication will be best resolved if responsibilities are imposed on the containers themselves. Of course this is something which will be strongly opposed by key portal vendors since it might mean some major rewrites. That is one of the key reasons why the JSR168 has been treated with so much callousness (the last version was out in 2003) and no new versions have been proposed yet although enterprise portal and content aggregation is one of the biggest concerns for large organizations. Vendor lock in on portal products have to end and the portlet specification now has to address how to integrate well with different presentation frameworks and make portlets truly portable. I think the current spec just makes portlets portable in an amateurish kind of way. Professional portals just cannot be built with the current spec.

    Coming to the current topic, I have been involved in doing something similar in the past year although I hated doing every bit of it because of the non-standard way I had to do it. Putting objects in the application scope of the portlet session in one portlet, then reading it from the other portlet(s), blah, blah, blah. Sun ended up stating that what I did can be part of a standard because this has been done for the first time, blah, blah (I hope they were not serious). We must get out of this now and expand the portlet spec.
  18. I blogged about inter-portlet communication last week : http://jboss.org/jbossBlog/blog/jviet/2005/07/14/The_recurring_interportlet_communication_dilemna.txt
  19. portlet identity[ Go to top ]

    A much simpler problem than communication that has also not been addressed in jsr168 is portlet identity. In order to communicate, you need to be able to identify individual portlet instances (a portlet can be used multiple times on the same page).

    I was trying to give two portlet instances of the same portlet their own configuration file and found out that it can't be done since there is no way to identify the portlet instance. The identity information that the portal obviously maintains is not exposed through the API at all.
  20. portlet identity[ Go to top ]

    The identity information that the portal obviously maintains is not exposed through the API at all.
    The closest you can get is the getNamespace() method in RenderResponse. It will probably include the identity somehow. But it is, admittedly, a very weak solution.