[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Message Header Spec
Folks I know this is coming very late, but I though it would be useful to respond to Chris's points which we should definitely discuss during our meetings this week. David -----Original Message----- From: Christopher Ferris [mailto:firstname.lastname@example.org] Sent: Thursday, April 27, 2000 2:13 PM To: ebXML-Transport@lists.oasis-open.org Subject: Re: Message Header Spec All, My comments on the 0.3 Message Header spec below. Cheers, Chris Sect 2.1 Header Parts Message Routing Info - this is confusing. "... or has been taken by a message..." should be omitted. This is covered by the Message Routing History. IMO, it should not be both. <DavidB> I know what you're getting at, but: 1. Before the message is sent we need to use the future tense 2. After it has been received (but not processed) we should use the past tense as the Message Routing Info has not yet been put into the Message Routing History (and might never be if no routing history is kept). ... or perhaps I'm trying to be to precised (or perhaps pedantic) ... </DavidB> Message Routing History - should be required even if there is only one hop. IMO, the TR&P message handling s/w should afix a "postmark" whenever it processes a message, regardless if it is to be forwarded on elsewhere. This preserves the audit trail/traceability of a message and provides a consistent handling of messages. <DavidB> This is something we need to discuss. The idea behind "levels" that was in earlier documents was that you should be able to use the same elements with the same semantics in either a basic way, or an alternative way that offers greater functionality. I don't see audit trails as a "must always have" since I don't think that all interactions between parties will need to be traceable. </DavidB> Message Type Dependent Headers - should we really have any of these? Why wouldn't/couldn't we express status/error information in the payload? I'd much prefer that the header be processed consistently, regardless of the "type" of message. <DavidB> I think there's trade off here. Having a standard header is a good idea. But it's also a good idea to have standard ways of reporting errors or the status of a process. If we put the errors and status information in the payload then we might also need to have another document that reports an error/status in an application specific way. As a result we might have two documents in the payload where one might do. Let's discuss this tomorrow. </DavidB> Sect 2.1.1 It isn't clear that we need to have separate header parts. If we use XMLDSig to sign documents (header or otherwise) then the requirement to have separate header sections is eliminated because a signature applies to a reproducable c14n'ed XML fragment. We're going to have to consider the organization of the header document to make it easy to sign parts which would likely be signed together (eg. separate out routing history to a top-level element, etc.) <DavidB> I agree with you and I think I've taken this into account by having separate sections. In practice I see each of these sections being a separate element with an ID attribute as children of a ebxmlheader element. </DavidB> If we must support S/MIME or PGP/MIME, then this may be a requirement. However, I would like us to make every effort to have as few separate parts as possible. One would be ideal. <DavidB>I agree</DavidB>I could see as many as three being the maximum partitioning before it gets completely out of hand, making the header processing more complex than it needs to be. <DavidB>In the short term I think that you have a single element as described above and then sign the whole element using S/MIME or PGP until Dsig comes along.</DavidB> Secure Timestamp - Again, using XMLDSig, this is a no brainer IMO. We can explicitly sign any element(s) of a given document. <DavidB>Totally agree.</DavidB> Sect 2.2 Message Header, Header Part 1. Message Header Version I've been having a good discussion here regarding use of a namespace to identify version. I would propose that we not use a namespace to identify a version, but rather an explicit version element or attribute. eg. <ebXMLMessageHeader xmlns="http://www.ebxml.org/ns/MessageHeader" version="1.0"> ... </ebXMLMessageHeader> or <ebXMLMessageHeader xmlns="http://www.ebxml.org/ns/MessageHeader"> <Version>1.0</Version> ... </ebXMLMessageHeader> This way, we can support version specific processing without having to parse a complicated name which implies a version. See the XSLT specification for how they handled versioning. Ideally, we should be able to support the same sort of version specific processing if necessary (and it will be!) <DavidB> I don't have strong views on this and think we should adopt whatever ebXML as a whole agrees to </DavidB> 2. Message Type Again, I have significant reservations for characterizing message types and encoding these into the header. <DavidB> The short answer is that by encoding message types into the header, makes it possible for middleware to handle all reliable messaging on behalf of the application. Otherwise the application has to do it. We should discuss this. </DavidB> 3. Service Type "...be private to a company or organization..." I would like to avoid this if at all possible. It will only lead to a fragile environment and it exposes internals unnecessarily. I could agree that it would be allowed, but it should be discouraged. It would be preferable if there were only standardized service "names" which had a specific meaning/understanding within or across verticals. <DavidB> I agree with your sentiment, but not the reality. If we say to people that you can only use ebXML if you are part of some industry consortia that is setting standards, then we're just creating a barrier to adoption. On the other hand, I think market forces will tend to make companies want to use definitions that are in widespread use (i.e. so that they can interoperate) rather than invent their own. Let''s discuss. </DavidB> 5. Message Set Data If all the data in this element is identical for all messages in a message set, then why include it in the header. Couldn't this be externalized (such as encoded in a TPA) and referenced? RosettaNet only identifies and references the PIP, it doesn't include the entire PIP in each message instance. <DavidB>I don't think so since: 1. I don't think we can insist on negotiating a TPA in every instance before you can use ebXML, and 2. By including it in the header and separately creating a digest of it that you digitally sign you can assert that one message/document is part of a set of related messages without having to make all the messages available to everyone. We found this idea very useful in IOTP so that you could prove you made a payment to a bank for a purchase without actually telling the bank what you bought. </DavidB> In section 3, Service Type is equated to PIP identifier. If that's the case, then what need is there for Message Set Data other than the unique ID which binds all of the related messages together in a single process instance? <DavidB> You need to Message Sets to support services that are made up of other services. You might have a simple service that can be used in many contexts, for example payment. The Service and Intent might tell you that you're doing a Payment, but unless you have some other identifier that shows the context in which a Service is being used, then you might not get the full picture. This is much easier to explain using a white board. </DavidB> 9. Quality of Service QoS means lots of things to many people. I think that we need to think carefully about this. Certainly, it could be externalized into the TPA (or equivalent). It would certainly need to be negotiated or it won't work. You can't expect an ack from a handler which cannot do acks. <DavidB> I don't think we can insist on negotiated TPAs. It is quite reasonable for a service to simple state it's operating parameters on a "take it or leave it" basis, or even, for a service to rely on a default if they don't even do that. I honestly don't think that there is so much variability that making TPA negotiation mandatory makes sense. </DavidB> 10. Message Manifest Again, I think that this should be required, not optional. It should include a reference to itself, or its container document part, IMO. <DavidB> If, as previously discussed, you have a error/status data in the header, then you can quite easily have a message that only consists of a header. In this case I think that a manifest is redundant. </DavidB> Sect 2.3 Message Routing Information, Header Part 12. Part Message Data I don't believe that the ebXML TR&P message handling layer should be responsible for carving up and reassembling arbitrarily large messages. This would seem to me to belong to the transport protocol handler. <DavidB> In theory I agree, but some transport protocols don't do this *reliably*. This means you need to layer reliable messaging on top of any transport protocol. The other thing to consider is that there are hard limits on the size of message you can send using some protocols. In this case it might mean that you can't necessarily send a message unless the application knows the transport protocol that will be used. I don't like the idea of the application having to know the transport protocol that will be used before sending a message. </DavidB> Sect 2.5 Message Type Dependent Header Parts I think that we should try to avoid, at all costs, having different forms of header dependent upon the type of message. This will only complicate message processing unnecessarily. I think that we should try to keep transport processing consistent for ALL messages. Again, what I think this points to is that we haven't come to terms w/r/t the responsibilities of TR&P in the overall model of ebXML. <DavidB>I agree with this statement</DavidB> Monitoring of message choreographies should be (IMO) the domain of the Business Process layer and should probably be optional. <DavidB>Why? It is quite possible for the ebXML layer to do this. In which case it takes an unnecessary burden off the application. Why force the application to do things it doesn't *have* to do? This doesn't mean we're stopping the application from doing it. The application can still check choreographies if that's what you want to do.</DavidB> It is also not clear (to me, anyway) why the status, error and ack information isn't (or rather c/shouldn't be) carried in the payload. <DavidB>This has been discussed earlier.</DavidB> Again, what business is it of the transport to handle an error? Error handling requires business logic unless the error is specific to TR&P processing and something which can be resolved by the TR&P layer. <DavidB>If the messaging layer is handling reliable messaging, then it needs to know about all the errors otherwise it might resend a message because a reply was not received when no reply will ever come because of the error.</DavidB> Maybe, the real question should be, does TR&P now extend to TRP&C (transport routing, packaging and choreography). <DavidB>I would say yes, in so far as it is required to support reliable messaging.</DavidB> IMO, the C should be left to the "application". The "application" could be: - a workflow engine - a mailbox/queue (eg. ECXpert, MQSeries, JMQ, JMS, etc.) - a topic for pub/sub - a direct mapping to an application API wrapper (JSP/Servlet, EJB, CGI, whatever) I don't think that we can, nor should we, suggest/dictate how these "applications" will perform their role. <DavidB> I'm not suggesting we dictate how these things should work. On the other hand, I don't think we should force everyone to develop their own way of doing these things, when it is quite easy IMHO to develop solutions that are generally applicable. How many different ways of doing pub/sub do we need, for example? </DavidB> Sect 4.1 Message Types I still have reservations regarding the explicit classification of message type (request, response, exchange, cancel, error, status, ack, oneway, whatever). I honestly don't see any value in this. <DavidB>I don't see how we can do reliable messaging, audit trails at the ebXML layer without them. We would end up not meeting some of our requirements.</DavidB> I am also concerned that this really belongs in the domain of the BP WG, if anywhere, to characterize the messages involved in the execution of a business process. It certainly isn't clear what the TR&P layer would do with this information since it shouldn't be concerned with choreography. <DavidB>What we're really doing is developing building blocks from which the BP layer can build applications knowing that they don't have to worry about retries for reliable messaging purposes.</DavidB> Sect 220.127.116.11 Cancel Message Since this is clearly a business/application level message (because it is/must be processed by the "applicaton"), we have no business specifying it's schema or even suggesting its semantics. Let's leave this to the Core and/or BP WGs. <DavidB> I agree that it needs to be processed by the application layer. However the messaging layer also needs to know about the cancel so that it does not need to retry to send messages. We are not stopping a Cancel message from also including a document in the payload that is application specific - we aren't defining the application schema. </DavidB> Chris I appreciate your comment. Let's see if we can come to some agreement this coming week.
Powered by eList eXpress LLC