Subject | Re: [Firebird-Architect] Vulcan services part II |
---|---|
Author | Alex Peshkov |
Post date | 2006-05-11T13:42:17Z |
Arno Brinkman wrote:
design. And I don't think it's a good idea to fix one, leaving all the
rest "as is". We have at least one more serious problem with services
design: badly designed (to be more precise - illegally designed) formats
in SPB. To decide, where particular clumplet ends, it's not enough to
take into account it's tag (even this is not needed in DPB), one must
take into account previous clumplets in that SPB. And if we plan to add
new version of services manager, it will be good idea to fix all known
problems in services, not only some of them. Moreover, not to fix only
one specific service.
> Hi,But that is how all services work since IB times, according to initial
>
>
>> 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
> also!
>
>
> 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.
>
design. And I don't think it's a good idea to fix one, leaving all the
rest "as is". We have at least one more serious problem with services
design: badly designed (to be more precise - illegally designed) formats
in SPB. To decide, where particular clumplet ends, it's not enough to
take into account it's tag (even this is not needed in DPB), one must
take into account previous clumplets in that SPB. And if we plan to add
new version of services manager, it will be good idea to fix all known
problems in services, not only some of them. Moreover, not to fix only
one specific service.