OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Messaging Service CPP/CPA [was: Ack Message Payload??]

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.

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.

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.

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC