Despite believing that I have already addressed these issues,
I will try to respond in the way David B. prescribes
David Burdett writes:
"I would assert that with the current spec, the receiving MSH often will
not
have the information needed as it assumes the sender of a message knows
what
to put in there and sometimes they won't. I don't think it is acceptable
that before you send anyone a message you HAVE to pre-agree in a
separate
out-of-band conversation what data is to be used in the service and
action
for any response."
Dale Moberg>> You will have to "pre-agree" on what identifiers to
use for PartyIds in To and From. Why is an agreement on Service
and Action more of a burden?
If the idea here is support for totally
spontaneous B2B transactions, I was not
aware that was a 1.1
requirement. If the only pre-agreement
is for URL endpoint (and "tModel" WSDL),
see Web Services, UDDI, pull down your
endpoint and fire away. I hope
the other endpoint understands your
1. MIME,
2. Security requirements,
3. Namespaces for payloads,
4. Namespaces for expected Responses,
5. Range of Response Messages,
and so on...
The concern with spontaneous B2B
messaaging reflects new requirements
on Messaging, and I would think
you want to discuss them in more
detail before stuffing them into a 1.1 bug fix.
[ deleted some stuff here]
David B continues>>
"1. How does the recipient of a message know what to put in the Service
and
Action for the message they return in the absence of a CPA (Please read
the
Bank Payment example for more details)
Dale Moberg>>
There could be any number of ways, but since you
disallow any out of band way of conveying this information
to set up the configuration, and you apparently include
references to a BPSS in this category, I guess I have
a prior problem: What really are the constraints on
the values that can go in the action and value
fields? If there are no constraints, what information is
conveyed from one party to the other by including
service and action values? If there are constraints, then explain
them here and that explanation will tell us how the
recipient would know what value to put in the action
field for the Response message. Basically, the question
you are asking is ,
" If we are prohibited from using the
BPSS and CPA that include or point to
the values used for service
and action, then how do we get
these values? And don't
suggest that in this case
the parties will have to
bilaterally agree on the
values to be used beforehand! "
That is clearly a _rigged_ question, and
I don't find that it
makes a lot of sense. Are you
looking for some kind of convention:
Convention for Missing Service and
Action Values in Responses:
'When not using BPSS or CPA to obtain
or exchange values for "Action" and "Service,"
a receiving party should use the
incoming value for "Service" as its
service value for its Response, and
should append the suffix "-response"
to the string found in the request's
Action element.' The sending party
may make up any values it finds
amusing or otherwise of interest.
[An alternative would be to just
use the same service and action
values as in the Request.]
PS: I will refuse to acknowledge
having proposed the above convention.
It would, however, permit your
dynamic filling of fields that
you seem to hanker for. (I just
wonder what payload will get
stuffed into the Response.)
David B. Continues:
"2. To use RefToMessageId, the sender of a message, where a reply is
expected, would have no option but to save the data from the EVERY
message
even though the message was sent with deliverySemantics of BestEffort.
This
should not be necessary. How can it be avoided?"
I don't see why the data (payload)
needs to be saved for this
purpose. (Archiving is another story,
of course.) It would
be sufficient for a MSH to save the
MessageId used along
with whatever supporting information
it felt it needed to retain-- for example,
a directory for the incoming response, a JMS queue,
or whatever is used
for interprocess communication
of the Response payload
to the next processing component.
I think this concern is plain and
simply, a bogus one.
David B>>
"3. If you are using PartyId, Service and Action to route a message, how
do
you know which MSH at the Party should receive the message when Service
and
Action have fixed values (as in an error message)? With the current
spec, a
Party could only have one MSH ... even if it were IBM."
Dale>>
I will try to be responsive here, but I don't think
I see what is bothering you. No real crisp
problem is conveyed here.
First, remember that a MSH is not
required to use any particular
combination of fields in order
to lookup a routing table entry.
For your case, either the MSH
is a forwarding MSH or not.
If not, then the messages to
the MSH stop there and it has
handlers for the service/action
values "built-in". If it
forwards these, then, as with
all forwarding, it has to maintain its
routing table so it does the
desired thing. It will look at
To, From, and whatever else is
needed, find the next hop,
and forward away. [ To determine
whether a MSH is a forwarder
or not for a given message,
I assume that it would suffice
for the MSH to know "who" it
is; see later remark on MSH
identity.]
How you reach the conclusion
about having one MSH at
a company (and exactly what this means)
is unclear.
Service and action do not tie
processing to a particular
host machine, protocol, port number,
IDL entry point.
So scalability concerns--if that
is what is bothering
you--can be handled in any number
of ways. If scalability
is not what is bothering you,
then you can give parts
of BigCompany (departments)
different names or URL endpoints
and that could get to different MSHes.
I think MSH identity
is probably tied to the sending PartyIds
I generate (and their associated
signing keypairs),
but a given MSH piece
of software might handle many
different business identifiers.
Also, possibly some round robin
method could be used to load
balance a given business
identity over a cluster of
MSH software modules when the
traffic becomes high. (How
the views of the logs, statuses,
and so forth are maintainedacross the cluster is left as
an exercise for the implementer!)
Again, I do not find any problem
here that impacts the current
approach to "Service" and
"Action".
