Subject Re: [Firebird-Architect] Vulcan services part II
Author Arno Brinkman

> No roundtrips. All services handling is done locally. If
> application is connecting to remote services
> ("remote_host:service_mgr") whole request is redirected to remote
> provider.
> Something like this:

First call is to service attach:

firebird module isc_service_attach (remote_host:service_mgr) ->
remote module serviceAttach (remote_host:service_mgr) ->
server module serviceAttach (service_mgr) ->
firebird module isc_service_attach (service_mgr) ->
services module SVC_attach (service_mgr)

Next call is to service start:

firebird module isc_service_start (handle X) ->
remote module serviceStart (handle Y) ->
server module serviceStart (handle Y) ->
firebird module isc_service_start (handle Y) ->
services module SVC_start (handle Z)

Next calls are to service query:

firebird module isc_service_query (handle X) ->
remote module serviceQuery (handle Y) ->
server module serviceQuery (handle Y) ->
firebird module isc_service_query (handle Y) ->
services module SVC_query (handle Z)

Finally service_detach .....

At service_query you've only service handle and re-directing to other services (that may be need to started or whatever)
depending on request items doesn't belong into dispatcher. Remember that this re-directing would take place on client

What an option _could_ be is that the engine implements a totally new service with the name "engineservice" and the
services provider try to attach to the "engineservice" and get it's information there. Not sure if this covers
everything, but it would meant that the API methods doesn't have to be extended.

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: