Glen Daniels wrote:
First of all, is "onComplete()" really the right name for the callback?
If you have an MEP with multiple response messages, mightn't this get
called a few times? Perhaps onMessage() is better, and then we can have
onComplete() be a separate callback to indicate that the MEP is done.
Second, what's the point of AsyncResult? It contains nothing except a
MessageContext right now. Recommend dropping this class.
Third, why is Callback an abstract class and not just an interface?
There doesn't seem to be enough going on there (really just setting the
"complete" flag) to warrant the limitations that you get when extending
instead of implementing.
Fourth, if you get an onError(), does that mean you a) received a fault
message, or b) something went wrong on our side? In other words, which
MessageContext would we even be receiving here? I think it would be
clearer and cleaner to have all received messages, including faults, be
handled by onMessage(), and then have onError() be explicitly for the
case where something went wrong while sending. Alternately I'd be ok
with separate onFault() and onError().
So I'd propose the following:
public interface Callback {
/**
* Received a message, info in the MessageContext. Might be a
* fault, so check msgContext.isFault()!
*/
void onMessage(MessageContext msgContext);
/**
* Operation is complete. (should we pass OperationContext?)
*/
void onComplete();
/**
* Something went wrong on our side! The MessageContext
* is the OUTGOING message. Incoming faults will trigger the
* onMessage() callback above.
*/
void onError(Exception e, MessageContext msgContext);
}
Thoughts?
Looks good to me, but I'm a bit skeptical about onComplete vs. onMessage.
While in theory I can see the need is this practically useful? If someone
wants to check whether the MEP is complete when a message has been
delivered, they can go up to the operation context and check the state.
So, do we really need onComplete?
An important point to put into the javadocs is that onError is not called
for fault messages- its only called when something has gone wrong.
Receiving a message that contains a fault is not an error; just business
as usual.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]