river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: Service Wrapper Example
Date Tue, 16 Feb 2010 11:08:33 GMT
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

View raw message