Re: Message Header Spec

[Christopher Ferris <chris.ferris@east.sun.com>]

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.

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.

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. 

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.)

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. 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.

Secure Timestamp - Again, using XMLDSig,
this is a no brainer IMO. We can explicitly sign
any element(s) of a given document.

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!)

2. Message Type

Again, I have significant reservations
for characterizing message types and encoding
these into the header.

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.

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.

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?

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.

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.

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.

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.

Monitoring of message choreographies should be
(IMO) the domain of the Business Process layer
and should probably be optional. 

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. 

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.

Maybe, the real question should be, does TR&P
now extend to TRP&C (transport routing, packaging
and choreography).

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.

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. 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.

Sect 4.1.3.7 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.