If you're not familiar with the Remoting 3 API, none of this will make sense or it
will not mean what you think. Fair warning given! :)
One-way requests need to move off of Client on to their own thing or be dropped. They
don't fit on Client - which has type parameters for the request and reply type for one
thing. What kind of single request listener would support both two-way and one-way
requests? What if there's confusion between the client and server as to whether
it's a one-way or two-way request? The client might end up just hanging there waiting
for a response which will never come, or the server might try to send a response to a
one-way request, which will result in an exception, and the operation will never succeed
(the server would abort the operation, though the client would never directly discover
this).
Yeah most of this stuff can be worked around. But I think it's a big red flag.
There's a significant difference in semantics between one-way and two-way requests -
the lightweight nature of one-way requests, relaxed delivery guarantees, the kinds of
services invoked, etc. I think this merits its own division.
I'd rather see one of two things happen: (1) one-way message clients split off into
their own interface, with a corresponding split in the various intermediate request
transmission types, all the way up to the final RequestListener; or (2) one-way requests
ditched altogether until a later version.
What do you think?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183703#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...