Without getting into real intracacies, these are my requirements.
 
1. To Process isolate components from each other
2. Components must be able to resolve other components from other Processes 
(implying some form of 'central registry process', probably the startup process)
3. Components must be able to be written using .net CLR features such as events 
(that rules out WCF, but leaves Remoting).
 
Eventually, one of the components will be startable, at which times all 
dependencies will be resolved, whether they exist in-process, or cross-process.
 
Because of this, whatever 'registry' mechanism there is, the registry must be 
full before any of the components attempt to resolve their dependencies.

________________________________

From: castle-project-users@googlegroups.com on behalf of Krzysztof Kozmic
Sent: Mon 25/04/2011 6:24 p.m.
To: castle-project-users@googlegroups.com
Subject: Re: Last change to register kernel dependencies



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: castle-project-users@googlegroups.com on behalf of Krzysztof Kozmic
> Sent: Mon 25/04/2011 5:48 p.m.
> To: castle-project-users@googlegroups.com
> 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 castle-project-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> castle-project-users+unsubscr...@googlegroups.com.
> 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 castle-project-users@googlegroups.com.
To unsubscribe from this group, send email to 
castle-project-users+unsubscr...@googlegroups.com.
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 castle-project-users@googlegroups.com.
To unsubscribe from this group, send email to 
castle-project-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en.

<<winmail.dat>>

Reply via email to