[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Re: gw_svc_call (was Re: [DotGNU]Goldwater Documentati
[Vrs-development] Re: gw_svc_call (was Re: [DotGNU]Goldwater Documentation)
Tue, 22 Oct 2002 00:33:35 +0100
On Monday 21 October 2002 18:57, Stephen Compall wrote:
> On gw_svc_call:
> 1. you mean explicitly freed, not implicitly. If it was implicitly, the
> user wouldn't have to do anything :)
Quite right too. Will amend.
> 2. You provide a way to avoid blocking calls with GW_NOREPLY, but this
> method of returning "immediately" provides no reply from the service,
> obviously. I suggest a way to receive a reply asynchronously with a
> callback mechanism. That way, users can avoid the overhead (and clutter)
> of new threads.
Yep. There is (half) a feature for asynchronous requests and replies.
Basically you specify a GW_ASYNC flag when doing the request. Later you can
do a gw_get_reply() call to see if your reply is ready and to get it if it is.
However I never really got it to perform very well, so I put it on a back
burner.... [suddenly recalls trying to work out how to do reply tracking
properly last year sitting on a beach in Goa... must find those notes!]
The architecture is a lot more mature now, so I should probably resurrect
> 3. I don't like the idea of limiting oneself to servers and clients:
> once a connection is established, the server and client should be able
> to make "calls" to each other. Perhaps a GWService might keep a client
> object around, and use this to make those calls. Even better, the
> connected client could be described with a path (local to the service),
> just as the "services" are.
There isn't a connection as such, the communicating processes should be
viewed as being connected to a opaque cloud within which 'magic' message
routing is performed.
That said, don't forget (or you may have missed it) that a GWServer may
call GWServices in other GWServers. Whilst doing so the 'calling' GWServer
is acting as a client.... the upshot being there is no real concept of what
is a client and what is a server other than what the process is currently
doing. It's all down to terminology. What we call a GWClient is merely a
process that is a temporary part of or is external to the Goldwater
application (and thus does not provide GWServices but can only call them).
If you need two or more processes to be able to inter-call each other, make
However there is another messaging mechanism on the TODO list (again on the
back burner as it proves to be less useful initially than peer-2-peer) and
that is publish-and-subscribe. Using this all processes, including real
GWClients (which cannot normally receive unsolicited messages) may subscribe
to subjects and receive messages published to them. The great thing about
this mechanism is that you can subscribe and publish to wildcarded subjects
Thanks for the comments Steven.
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk