Subject Re: [Firebird-Architect] Re: Vulcan services engine info. was (engine information (nr. of attachments, da
Author Jim Starkey
Roman Rokytskyy wrote:

>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.
>
>
Dispatch doesn't know the difference between an engine, a remote
interface, a services module, or a gateway. Furthermore, it shouldn't.

>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).
>
>
Does it really make sense for dispatch to call other providers? How is
the service supposed to work remotely, for example? The remote
interface doesn't keep statistics, and without a context, can hardly
forward a request.

Even with aggregation in dispatch, getting any meaningful information
that way is tough, particularly if rigorous security is imposed. Maybe
you would be happier just asking whatever provider you're connected to
and leaving it at that.

>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.
>
>
Sorry, that wasn't my idea. Since the dispatch module doesn't know what
a services provider is, it is going to be difficult to implement. Maybe
worse, it would require taking to a provider without first establishing
an attachment with credentials validation with either create or attach.

--

Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376