[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: T2 The answer isn't always "you need a CPA"
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".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC