Subject | Re: [Firebird-Architect] Re: Vulcan services engine info. was (engine information (nr. of attachments, da |
---|---|
Author | Jim Starkey |
Post date | 2006-05-10T14:42Z |
Roman Rokytskyy wrote:
interface, a services module, or a gateway. Furthermore, it shouldn't.
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.
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
>My idea was that client Y-valve loops through all affected providersDispatch doesn't know the difference between an engine, a remote
>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.
>
>
interface, a services module, or a gateway. Furthermore, it shouldn't.
>If that is what you are talking about, then we were talking about theDoes it really make sense for dispatch to call other providers? How is
>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).
>
>
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-valveSorry, that wasn't my idea. Since the dispatch module doesn't know what
>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.
>
>
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