0 Replies Latest reply on Mar 3, 2006 6:26 AM by julien1

    Component invoker

      I want to introduce *in the future* the notion of ComponentInvoker in the architecture.

      The main reason is for WSRP for the consumer and the producer.

      1/ The producer today has to care of the instance registry and the web app registry in order to make a proper invocation to the portlet.

      2/ The consumer has to lookup a remote portlet in the remote wsrp registry, and then possibly perform association with a local instance.

      The ComponentInvoker would be responsible to be a proxy in front of a component that would mask if it is local or remote.

      1/ In the case of the producer

      a/ The ComponentInvoker contains a reference to the instance that points itself to the component. In the case of developping and testing the WSRP module, the ComponentInvoker can bypass the notion of instance.

      b/ The clone operation would create a new component invoker. When it is instance based then that would create a new instance pointing to the same Component.

      2/ In the case of the consumer

      The consumer would only have to deal with a unified view of what a component is.

      a/ if it is a remote portlet then the ComponentInvoker implementation use the SOAP transport layer to perform the invocation.

      b/ if the component is local then it does what it does today.

      At the end I just want to discuss about it right now because this change will require significant changes although it does not change the global architecture. I see it more as an improvement (I hope everyone agrees :-) ).

      The scope would be for portal 3.0, maybe 2.6 if it is justified.

      So just want to discuss it here about that topic.