I'm obviously not seeing the whole picture but I get the feeling that an
asynchronous publish/subscribe architecture with message passing might
work better than synchronous RPC via remoting.
Are there any particular reasons why you want to do it this way?
How autonomous the child processes are? Do they have each their own
container? I'm not sure I can see how that all works together in your
planned architecture and how the deferred registration might be
required, as from my understanding you are making all services available
at some point before resolve so why you might need to register things
lazily?
Overall, it does have a unusual feel to it.
Krzysztof
On 25/04/2011 4:02 PM, Adam Langley wrote:
Hi Krzysztof,
I have a design goal - I want to run a set of components, each component
resides within a dedicated process (what I want to achieve cant be done with
the RemotingFacility).
So, for examples sake, I have 3 processes.
One process behaves as the 'orchestrating' process, and maintains a registry of
the component available in each of the other processes.
The component in each process MAY depent in a service from a peer process. As
such, the entire system needs to 'initialize' before any components can be
resolved.
So, what I was intending, is
1. the 'orchestrating process' starts up, and begins each child process, and
instructs each one to register their primary component.
2. when a child process registers its component, it calls back to the
orchestrating component to register the remoting address of the component.
3. when the orchestrating component has 'initialized' each child process, it
can then share all of the registered component addresses with each child
process.
- this results in each child process having all the other child processes
registered, so if there ARE any depedencies, they will be resolved as remote
proxies.
4. The system is now initialized, and the child processes can be 'started' -
(whatever that entails... perhaps they are 'startable').
I dont know the best way to approach this, but if I know that I will not cause
any components to be 'resolved' until the entire system is initialized, then I
can happily defer the 'shared registering of all child components, within each
child container' until JUST before a component is resolved....
Does this make sense?
Thanks
________________________________
From: [email protected] on behalf of Krzysztof Kozmic
Sent: Mon 25/04/2011 5:48 p.m.
To: [email protected]
Subject: Re: Last change to register kernel dependencies
I looked at IlazyComponentLoader, but that only kicks in if nothing is
registered...
Well isn't that what you need? It seems to be the case from what you said in "just
before resolution, it's dependencies are registered"
Can you elaborate a bit more why you need that behaviour and what problem
you're trying to solve?
cheers,
Krzysztof
On 25/04/2011 3:45 PM, Adam Langley wrote:
I require a way to get a "last chance" to register a components dependencies
before resolution occurs.
I am writing a custom facility, but I need to first register a component which
has missing dependencies, then just before resolution, it's dependencies are
registered.
What extension points are available for this?
I looked at IlazyComponentLoader, but that only kicks in if nothing is
registered...
Thanks
Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
