Discussions

News: Interportlet Communication API notes from Roy Russo

  1. Roy Russo, in "InterPortlet Communication API," has summarized how JBoss Portal manages interportlet communication (IPC) in JBoss Portal 2.2, while pointing out that the next revision of the portlet specification (JSR-286) has IPC as something to be addressed. IPC in JBoss Portal is managed with accessing a hierarchy of Portal Nodes, almost as if addressing portlets via a DOM (although this analogy fails, because portlet attributes aren't part of the "portlet document.") Full documentation of this feature is contained in the JBoss Portal reference documentation, chapter 6.

    It's an interesting idea, although slightly verbose. How do you think portlet communication should be accomplished? The Portlet specification is still early in development, so it may be worthwhile to consider what options are appropriate sooner rather than later.

    Threaded Messages (16)

  2. IPC in JSR168[ Go to top ]

    Yes,i agree ,most of the vendors have created their own apis for IPC and that surely was a necessary step as with JSR168 IPC ,there are number of issues with portlet1.0 ,eg..
    If u r Using the PortletSession for IPC between two portlets(say "A" and "B") :

    The portlet spec does not mandate any order in which the doView() be called for multiple portlets on the same portal page.
    This means if you were to set an attribute in the doView() method of 'A'Portlet you may or may not get the attribute in the doView() of 'B' Portlet (depending on the portal server and perhaps the layout that you are using).

    Few questions are still unanswered or are under heavy debate like
    1- In the A/B example, what would happen if the user decides to remove the 'A 'from his page? Would the 'B' still be functional.
    2- what abt IPC in different wars.

    We hope that all these big -small issues will be resolved in portlet2.0 .

    --lokesh

    http://lokeshpant.blogspot.com
  3. IPC in JSR168[ Go to top ]

    Well IPC have a procedure to be followed. The attributes should be set in action method and not in render methods. I dont think it will be feasible and would add much if we specify an order in which render methods should be called in portals.

    The portlets who are closely related should be put in one application. Thus if the portlets are in different wars, the communication generally should not be required. But i do agree there are times when such needs arises and some external messaging technique is required to be used.

    One major issue is that, if the portlets are not on the same page. Suppose they are on the different PageUrls. In such scenarios, we need to use Navigation API's to change the page url at runtime from code. These Navigation API's are vendor dependant. Thus if u have coded for one Portal platform it may not work on the other. Can some specifications be laid about this Navigation API or changing pageURL at runtime?

    Regards,
    Vikramark
    http://portlets-jsr168.blogspot.com
  4. No thanks![ Go to top ]

    That was a proposal full of quite ugly anti-patterns. Yuch.

    I would suggest that it might be a better idea to consider making the Portlet API work with JCR instead. If portlets were accessible using JCR it would suffice to send a JCR node to the portlet from which it would be possible to do the communication.

    That would also allow a portlet to programmatically discover what other portlets and pages are available, by iterating through the JCR model. So, the spec would be to define what the JCR model should look like in the case of a portal. This way we can handle not only the actual communication but also the configuration phase of these relationships.
  5. No thanks![ Go to top ]

    I would suggest that it might be a better idea to consider making the Portlet API work with JCR instead.

    +1. This is the philosophy used in the JBoss Portal IPC API, although it does not (currently) use jackrabbit.

    The use of JCR, would allow for the "Portal Tree" or hierarchy to be navigable, allowing a developer to link-to any window, page, or even portal instance by walking the tree of nodes or even searching for a specific one (XPath).

    ie...

    PortalNode thisNode = req.getPortalNode().getParent();
    PortalNode linkToNode = thisNode.resolve("../SomeNodeName");
    PortalNodeURL pageURL = resp.createRenderURL(linkToNode);

    I think this methodology is best, but I'm not sure if this is the route the committee will take.

    STAY METAL!
    Roy Russo
  6. No thanks![ Go to top ]

    I think the Portlet API should also flesh out contracts on the Portal Container side. The PortalContext was always a little thin as far as I was concerned.

    Eg:

    1) A portlet registration contract.
    2) A portal message/event bus. I think this would resolve some of the interportlet communication issues.
    3) A portlet lookup contract. The JCR idea would fit in here as an example.


    The Portlet API implicitly assumes a Portal container anyway, why not flesh out some more concrete Portal container use cases into the API.
  7. No thanks![ Go to top ]

    1) A portlet registration contract. 2) A portal message/event bus. I think this would resolve some of the interportlet communication issues.3) A portlet lookup contract.

    I agree with Franck.

    We have implemented a portal engine (pict), based on Pluto, and this is the model we use to make portlets interact together. However, we avoid direct communication between portlets. Instead, the portlets can be “orchestrated” by the portal itself:

    - Each portlet has a set of entry points (through processAction) and a set of output events (created during the execution of processAction).

    - The portal engine makes use of a rules engine (Drools) to react to events and modify the states of other portlets. This leverages the power of the rules engine (cascading etc.) and does not require portlets to be in the same war or on the same page. The benefit is that portlets do not have to know each other. In this model, a portlet A does not interact directly with a portlet B. Instead, the portal knows about A and B and is used as a “controller”.

    It is also possible to write rules to control the portal itself, for instance to transfer the user on another page automatically.

    Finally, the user can also send an event to the portal engine through a certain type of URL (called “abstract URL” in pict).

    As Franck said, what could be standardized here is the description of the portlets entry points and events, as well as a message bus the portlets could use to post their events.

    Guillaume Bort
    http://www.p-i-c-t.org
  8. No thanks![ Go to top ]

    I really think people should look at why they are using portlet containers.

    If you are delivering portal pages where "content aggregation from different sources and hosts"(from the spec) then the specification we have now fits the bill(it may need to be more precise in places, have you seen how many times "the portlet container may" is specified), therefore if you are only aggregating content is IPC needed.

    If you are delivering an application that is to look and feel like a portal, but require each portal page and the portlets on each page to work together then the portlet spec just does not cut it..In this cas IPC is just a small part that is missing..

    What we did was develop our own portlet container using the portlet api, developed it in a way so we could embed it into our Spring context, by doing this we took complete control over the url, we created an abstract spring MVC servlet controller to interact with the injected portlet container, we extended this controller for different portal pages, each dynamically determining the portlets to be included on the page and which one gets the action call and also determining which view to render the results. I must admit we don't allow users to change window state and mode..which has made this easier, we are developing the portlets using the spring portlet MVC.

    One reason why I think the spec has failed is that it only half defined personalization and the then left the rest up to the vendors.. The spec should have concentrated on the portlet container and left the portal implementation up to us developers.. then CMS, user management, personalization and portal layout could be defined by the requirements of the particular portal being developed.. not the vendors.

    Jason Bradfield.
  9. I really think people should look at why they are using portlet containers.

    If you are delivering portal pages where "content aggregation from different sources and hosts"(from the spec) then the specification we have now fits the bill(it may need to be more precise in places, have you seen how many times "the portlet container may" is specified), therefore if you are only aggregating content is IPC needed.

    If you are delivering an application that is to look and feel like a portal, but require each portal page and the portlets on each page to work together then the portlet spec just does not cut it..In this cas IPC is just a small part that is missing..
    ....
    This is an old thread, but I just like to put in my 2 cents. I agree with Jason here, people tend to forget that a Portal is also a development platform. If a portal is well-designed, it should make web application development modular, and should make a web project more manageable. However, IPC has been the Achille's heel in the specs, creating more trouble than it had to. We, IDSignet (http://www.idsignet.com), are a software company located in Shanghai, and we have developed our own IPC mechanism, which still allows the portlet container to be compliant to the JSR-168 specs. We take the approach that portlets are application components that should be able to communicate with each other as designed by the portlet developer. A portlet can define its IPC API, and let any other portlets to "make call" on it, if they feel like it. The communicating portlets do not have to be deployed in the same war package (and that's the whole point of modularity). Please take a look at the papers here: http://www.idsignet.com/web/portal/insights/whitepapers Chen Shaopeng
  10. This looks like it behaves, mechanically, a lot like JSF's component trees but with clientIDs vs. XPath
  11. Correct. And so this allowed us to use the JSF tree component for our management ui. ;-)

    http://labs.jboss.com/portal/authors/articles/portal/whatsnew22/images/management.gif

    STAY METAL!
    Roy Russo
  12. Correct. And so this allowed us to use the JSF tree component for our management ui. ;-)http://labs.jboss.com/portal/authors/articles/portal/whatsnew22/images/management.gifSTAY METAL!Roy Russo

    I really do see a need for a general component model w/ event management-- where does inter-portlet state come into play? Maybe it's my lack of knowledge around portlet scopes. In one example in your ref docs, you explicitly define rendered parameters from one portlet to communicate with another by parameter name. What about name collision or rollback on failed actions with retaining portlet states in the UI?
  13. I really do see a need for a general component model w/ event management-- where does inter-portlet state come into play?

    Portlet state is managed by the portlet container as normal... IPC does not affect this.
    In one example in your ref docs, you explicitly define rendered parameters from one portlet to communicate with another by parameter name. What about name collision or rollback on failed actions with retaining portlet states in the UI?

    Not sure of where in the sample you're referencing, but portal objects at the same level in the hierarchy have to be uniquely named, so name collisions between portal objects/nodes should be a non-issue:

    PortalNode windowB = node.resolve("../HelloWorldPortletBWindow");

    There should only be one "HelloWorldPortletBWindow" defined _on this node_.

    I guess if you wanted to break it down, the main point that enables our IPC is the listener defined in the "receiving portlet"... http://docs.jboss.org/jbportal/v2.2/reference-guide/en/html/ipc.html#d0e1308

    This listener is simply intercepting calls to that the our PortletA made to itself, using PortletURL, as defined by the spec api. So PortletA creates links just as before, but PortletB is "listening" for these calls:

    if(nodeName.equals("HelloWorldPortletAWindow")

    STAY METAL!
    Roy Russo
  14. That's really cool, I've been looking at generic events-- is it by convention that the WindowActionEvent gets passed to processAction or are there explicit bounds to event/listener relationships in portlets (ex, could you wire a generic WavedHandEvent)?
  15. is it by convention that the WindowActionEvent gets passed to processAction or are there explicit bounds to event/listener relationships in portlets (ex, could you wire a generic WavedHandEvent)?

    Not sure what the purpose would be for extending the event mechanism beyond what the spec allows. I think most common use-cases would simply want to affect the Mode, State, and parameters of the receiving window.

    STAY METAL!
    Roy Russo
  16. is it by convention that the WindowActionEvent gets passed to processAction or are there explicit bounds to event/listener relationships in portlets (ex, could you wire a generic WavedHandEvent)?
    Not sure what the purpose would be for extending the event mechanism beyond what the spec allows. I think most common use-cases would simply want to affect the Mode, State, and parameters of the receiving window.

    That's true, I was just thinking that a more specific event system (in whatever form) would be easier to program to where a developer could generate events that were semantically in line with the purpose of entity. But then again, it would possibly be more difficult to decorate similar behavior over the like events (WindowActionEvent). You probably could find some gray in this realm with a single mode of event communication, allowing delegation to more specific handlers by extension.
  17. ditto Frank Bolander's comments[ Go to top ]

    I'd hope JSR286 implements something like that. I've been complaining about JSR168 since it was released because any significant portals I've seen used some form of portlet IPC; Lotus needed it for Lotus Workplace and SAP needs it for its custom portal. As I understand it, Websphere Portal Server (which Lotus Workplace uses) is similar in that it has a communications bus you can register for events with.

    It'll be interesting to see how well JBoss Portal's IPC implementation matches JSR286 and whether it'll be easy to intermix portlets. One of the ugly aspects of Websphere Portal is that you can code to the Websphere Portal container or the JSR168 container but you can't do IPC between servlets in both since they're separate containers running on the same server :-P