|Subject||Re: Vulcan services engine info. was (engine information (nr. of attachments, da|
> Dispatch doesn't know the difference between an engine, a remoteTrue and so should it remain. The Dispatcher uses configuration to
> interface, a services module, or a gateway. Furthermore, it
determine the provider the same way you do this for the databases,
only that we need one more entry
provider engine11 engine8
The first entry will provide a list of local providers to which
Dispatcher can talk to, the second entry provides a way to handle
attachments to the remote service calls.
> Does it really make sense for dispatch to call other providers? HowThe remote interface come in play only if on service attachment the
> 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.
host name was specified. In our current world services provider can
either collect data from local providers or from the remote provider,
but not from both.
> Even with aggregation in dispatch, getting any meaningfulBut we are not connected to some specific provider, are we? With each
> 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.
> 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.
call we pass a piece of information that allows dispatcher to
determine the provider to which the information is forwarded to.
As to the security, the "number of attachments" call at present time
has to go without authentication anyway, since there is no database
from which we can determine what security database to use...
We should add default security database for provider-specific calls:
This would however require that admin creates the same account in
security.fdb and security2.fdb. But I guess we can't avoit it, can we?