[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Message Pipe Confusion
|
Ric, Here is my answer to your questions. First, I am sorry I did not read
yet draft 11 to review it (I am very busy with some implementations and did not
find time yet). If I had read draft 11, I would have most likely caught the
inconsistency you are talking about. Ok, here we go: The line that says a particular pipe may be defined to
report errors is simply a mistake (it should not be there at all). You are
right, only UserMessages can be assigned to pipes, not signal messages. Concerning your second question about whether signal messages go back
on the default pipe, the answer is simply a big NO. Signal messages do not go
on the default pipe (if they were going on the default pipe, this would mean
that they are assigned to a pipe, which would contradict the fact that only
UserMessages can be assigned to a pipe). The confusion here comes from the term “pipe” itself. I
suggested the term “mbox” or “box” for such a concept,
but then the term was very confusing for Ian, and Jacques renamed it back to “pipe”
which is not yet the best terminology. The word “pipe” suggests a
tunnel or channel and saying that a certain message is assigned to a pipe would
suggest that the message is indeed traveling (going back on) on the assigned
pipe. This is not the case. Messages all travel within the same wire/network
(they use the same transport protocols that an MSH can provide). There is no
such “pipe” or “traveling on a pipe” concept because
the transport is the same for all messages (UserMessages as well as
SignalMessages). A pipe is just a parameter that can be present or absent from
the ebMS SOAP headers. When the parameter pipe is present in the SOAP headers,
we say that the given message is assigned to a pipe (not that the message is
traveling on the given pipe, which would be a mistake), and if the parameter is
not present, it does not necessarily mean that the message is assigned to a
default pipe. When the pipe parameter is absent, it simply mean that a message
is not assigned to any pipe. Messages do not always need to be assigned to
pipes (you assign pipes to messages only when you have some particular business
semantic that you would like to associate to a pipe and therefore would like to
distinguish which messages fall within you business semantics). The other confusion is about UserMessages that do not have a pipe
parameter in their SOAP headers. Normally, these UserMessages should not be
associated to any pipe (since the pipe parameter is absent), but it was somehow
said in the spec that when the pipe parameter is absent from a UserMessage,
that UserMessage is assumed to be assigned to a default pipe. I am not very
happy with such a saying although I did not make noise about it. A UserMessage
is free to not be associated to any pipe. Pipes are not mandatory; they are
used only when you have business semantics (could be inflow partitioning,
association with queues, assigning priorities, or anything you can imagine, etc...)
and want to distinguish those messages to which you want to apply your business
semantics. Normally when a UserMessage does not have a pipe parameter, it should
simply mean that the UseMessage is not associated to any pipe (not that it is
associated to a default pipe, as the spec is currently stating). So, when we
use the expression “traveling on a pipe”, it gives us the
impression that a message would always need to travel on something and
therefore a pipe is necessary, even if it a default one. This is not the case (“traveling
on a pipe” is bad expression). Hamid. -----Original Message----- Jacques/Hamid: There is an inconsistency in WD-11 of the ebms_core spec. Lines 648 to
652 discuss the P-Mode.errorHandling. Line 650 states - "It may also
define a particular message pipe for reporting errors." Seems ok. Except
back on line 558 of 2.3.3 - the spec states - "Only user messages may be
assigned to pipes, not signal messages" So, how can an error message be assigned to a pipe, if the spec
specifically says that signals (which errors are a type of signal) cannot be
assigned to a pipe? Also, I am confused about Signals not being assigned to a pipe. Do
signals go back on the default pipe? Excuse me if this question is addressed in
the spec, and I didn't see the answer. Thanks, Ric |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]