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.
