[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Messaging Service CPP/CPA [was: Ack Message Payload??]
<Krishna> But this shouldn't be, a standard should avoid any implied assumptions and all implications should be explicit ! Hence the logic for a new control message type. </Krishna> My thinking here is more along the lines of TR&P's "MessageBag" concept / pattern. I can imagine that instead of expanding the concept of MessageType one could use ServiceInterface/Action (TPAInfo child elements) header entities in a "MessageBag" fashion to do the same job. <Krishna> On further thought, may be the error and ack messages are sub-types of control messages. So may be the classification should be normal and control, with the control having a type attribute which can take multiple values (ack, error, RMControl, SecurityControl) et al. Of course, we can have the control messages as headers (like the RMHeader and SecurityHeader) and then embed the control directives in those tags. Reading your e-mail, I also realize that we might need a control message type for BP as well. </Krishna> As I said, I am not sure that we have to add Control as a MessageType, but I aggree that this as an issue that needs to be resolved. There were so many discussions about MessageType and "Message Service Layer" vs. "Business/Application Layer" already, but I realize that there are still differences in / confusion about operational semantics of some of these "Kinds". Maybe the only way to solve this would be to wait for Messaging Service "API"s or to agree on some explicit narative in the MS spec. Regards, Nikola
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC