[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Message Pipe Confusion
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).
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
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.