Tom Hobbs wrote:
I think that it's possible my terminology is letting me down. If I appear
to be getting defensive over my example, then I apologise and it's not
intended, I just haven't experienced the problems that you describe.
No. Please. It's me. If i cannot find a word quickly enough, i tend to
reinvent one. Most of the time it works out fine! :-)
For instance in the transport layer. A server can detect that an ack/nack
is overdue and start a
retransmission.
But will this not only be appropriate if the remote service remains
discoverable and in a (business context) working state? The following is a
question that I genuinely do not know the answer to; if there is a
transmission problem, what is quicker? To "start a retransmission" and
possibly have to wait for another timeout to occur, or drop the remote
reference and discover a new service with the assumption that there wouldn't
be any transmission problems between the client and the new service?
Obviously this might be problematic if you are relying on your business
services to be having a certain amount of state.
I was a bit aspecific here. I used transport layer in an abstract way,
but in this paragraph one could replace it with TCP/IP.
I haven't seen any self healing behaviour in the jeri transports, or the
layers between the actual
java.lang.Proxy of the service and its transport
Neither have I, which is why when outside of low level transport layers,
recovery and self-healing are all down to the client.
Indeed, thats an option. No problem with that.
retrieves a new RemoteReference for every transport error
Actually, the service could throw a business-context exception (as long as
it extends RemoteException) and that would prompt the retrieval of a new
Remote Reference also.
Indeed, the beauty of jini is, that one has several intercept points to
choose from.
(not registered, bu exported) remote reference gets serialized as for
instance a return value from a call to
the service, and this reference is passed through the system, it will
still experience transport errors.
Can you explain this for me, please? If I have wrapped a remote proxy and
call the "sayHello()" method on, it returns a String which gets deserialised
on the client side, i.e. in the Wrapper, into a "normal" Java String which
can be read and have all the wonderful String methods called on it without
risking a RemoteException. Right? Or have I got the wrong end of the
stick?
Also, can you point me to somewhere that I can read up on the differences
between "not registered, but exported", please? That bit went over my head.
If a exported service returns a exported service, this returned service
reference does not need to be registered (in reggie for instance) but it
still is exported. When a service is exported it is turned into a
serializable reference for use outside the JVM it exists in, and it can
be passed to another JVM. (see the javadoc of java.rmi.Remote).
You can view this process by setting a breakpoint on the first line of
the ObjectOutputStream.writeSerialData method, and inspect the passed
'obj' parameter.
Assuming we agree, if you have a wrapped service (with error recovery)
but the wrapper is allowed to return a Remote reference which is passed
through the program (without beeing wrapped) a transport (or remote)
error will cause effects outside the control of the wrapper. (So you
basically need a recursive wrapper to counter this.)
Am i on the right track here?
I'm trying to understand exactly what you and Peter are trying to solve (and
if this example helps any). Then maybe I can start contributing more to
helping you guys.
I wasn't specifically solving a problem. Saw your wiki entry, recognized
the underlying problem as one i also have on my mind, became inspired
and started freewheeling beyond the horizon.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
