Subject | Re: Vulcan services engine info. was (engine information (nr. of attachments, da |
---|---|
Author | Roman Rokytskyy |
Post date | 2006-05-10T05:58:31Z |
> And it doesn't (directly). Remote provide simply sends requestSorry, I am confused now. Which provider is going to handle the info
> through the wire. It is just an coincidence that on the other and of
> the wire another Dispatcher is sitting and handling these requests.
>
> >So, unless you make dispatcher to be some kind of provider that can
> >handle some requests and delegate others, you can't solve this without
> >breaking the layering.
>
> I can. There is no breaking if these Dispatchers are different.
call request?
My idea was that client Y-valve loops through all affected providers
below it and collects the responses. If no server was specified in the
call, it will check only engine providers, if server is specified in
the call, it will send request only to remote provider. This remote
provider sends request through the wire, server handles it and simply
forwards to another Y-valve. That Y-valve loops through all local
providers, collects responses and sends them back.
If that is what you are talking about, then we were talking about the
same thing all the time. But this also means that Y-valve is handling
some requests (our info call) itself and the rest of the calls
delegates to the underlying provider (engine or remote).
Arno and Jim suggest different thing. The idea is that Y-valve
delegates the info request to services provider, which has the list of
local engines and this services provider calls the same Y-valve again
specifying to which provider request should be forwarded. After
calling all specified engines, services provider processes the
responses and returns the reply back to the Y-valve, which in turn
returns it to the user.
Roman