Ignacio,
Thank you for the response. I have a couple more questions and comments
that I'll put inline.
Ignacio Silva-Lepe wrote:
FWIW, I'll try to respond to both Scott and Matt. Say we have a bi-
directional interface consisting of FI.cf and BI.cb, where FI is the
forward half and BI is the backward half. We agree that both the
call forward method cf and the callback method cb return void.
I think you made a couple of leaps that I didn't when I was reading the
specs. In my case both FI.cf and BI.cb have non-void return types on
the defined operations and they may be defined to raise exceptions. I
didn't see in the spec where the operations were required to have void
types and no exceptions.
The client that calls FI.cf is expecting the target service to provide a
result from the operation that is not going to be delivered to it via
the callback but synchronously when the service operation completes. In
this case the callback is used for some other purpose.
I'm not saying that this example isn't a bit contrived but I can't see
where it is disallowed in the spec. Further, the notion of non-blocking
calls seems orthogonal to bidirectional interfaces.
If the
call to FI.cf blocked, the question then would be until when and what
for?
The client would block until the service returned the result so the
client could get the result of the service.
Since the result to cf will be coming in the invocation to cb, there
seems to be no purpose in blocking cf, and unblocking it would require
some coordination, e.g. with the call to cb, by the system.
Here's where you've made another leap that I didn't. In your use-case,
the client is basically dropping a piece of work on the service and
expecting the service to "call back" with the "response" when the work
is complete. I believe that's the most likely pattern for this model
but I don't believe it's the only one.
Based on my interpretation of what exists in the specs today, if this
was the desired behavior, FI.cf should have adhered to the requirements
of a non-blocking operation and been annotated with @OneWay to indicate
it was non-blocking.
As for the call to cb (by the service that implements cf) the local
implementation is actually blocking, it does not seem to be necessary
to spawn another thread for this.
Does this address what you were trying to get at?
Not really. I think what I'm really trying to find out is if the specs
need to be more explicit such that they mandate bidirectional interfaces
must adhere to the non-blocking signature pattern where the return types
must be void and no exceptions can be thrown. If, however, the
information in the 0.95 assembly spec is worded correctly, I don't
believe the current Tuscany implementation adheres to it.
Given the above, the connector assumes that a bi-directional interface
is non-blocking an inserts a NonBlockingBridgingInterceptor, which in
turn assumes that the return type of the forward call is void and thus
returns a message with a null body, which is probably the cause of
your NPE.
Agreed. My point is that I don't think the
NonBlockingBridgingInterceptor should have been used in my example as
the client is expecting a synchronous result from FI.cf.
Thanks again.
--
Matthew Sykes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
