RE: [ebxml-msg-comment] Public Comment

Gait,

 

Thanks for the comments.  I've cc:d the main list so others can
comment here.

 

The one item I'm familiar with is the "stage delivery" support for
push/pull.

 

I agree that you can do this today with v2 - but its not directly
supported - so implementations are not consistent.  Therefore the
need is to provide a formal mechanism in v3 here.

 

Again - application practice has shown we do need this - particularly
for large payloads - or to avoid peak surges overwhleming central
systems - so non-time-critical deliveries can be picked up at times
when the receiver has slack capacity.  As you note it does require
longer message persistence by the sender - but again - this can be an
essential part of the process - e.g. the sender has fulfilled legal
requirement to submit by a deadline - and locked their submission
package - but the actual payload delivery can be deferred. 
Clearly you have to have agreement on the CPA for the staged delivery
responsibilities and timings.  I believe there is
enough parameters here to accomplish those settings between two
partners so timings and delivery responsiblity is not an
issue.  As always - probably some example would help clarify the
exact details.

 

That is just one use case from my experience - I know others have
more too.

 

Anyway - the bottom line is that real world applications have shown
us the need to have support in v3 for this formal push/pull
mechanism.

Hope that is enough clarification on the
rationale behind it.  

 

Thanks, DW

-------- Original Message
--------
Subject: [ebxml-msg-comment] Public Comment
From: Gait
Boxman <>
Date: Mon, July 10, 2006 5:13
am
To: 

Please find
below some concerns on the draft ebMS 3
specification.

Unfortunately I was not able to go into detail,
and can only comment on 
some high-level issues based on a feature
list from Jacques.

- Section 3 introduces a 'message pulling'
feature on the SOAP level to 
overcome limitations such as
availibility of static IP
I find it strange that one would need such
a feature, since ebMS 2 
already provides SMTP/POP3 based transport
which already covers such a 
need. The main issue with this is
shifting responsibilities. A sender is 
now required to keep the
message available for the recipient on his 
server, rather than
dropping it in the realm of the recipient when 
ready. This blurs
the division of responsibility and leads to issues 
with message
turnaround times.
- Section 2.2 introduces 'message exchange
patterns', which attempt to 
tightly couple business process with a
particular message exchange. This 
shouldn't be part of ebMS as it
introduces too much dependency between 
process and messaging. The
problems with sync and async messaging 
modules wrt to MEP already
indicate you're not on the right path here. 
Please stick to the
reftomessageid for linking messages and allow 
business process to
design the message patterns for the process. All we 
need to do here
is making sure people 'can' relate messages if they need to.

-
Section 5,7,8 - changing the header formats to comply with WS*.
The
main issue is backwards compatiblity. While I learned from Jacques

that SwA is still the way to go, moving critical information about
in 
the SOAP Envelope will require recoding at the core. This will
hamper 
migration from ebMS 2 to ebMS 3 environments, if not block
them 
completely, leaving the communities on an island and requiring

implementers to maintain two versions.

- Processing
Modes.
Having a concise set of data for processing modes is a good
idea. In the 
past, we've seen people struggle with CPA's to
configure their MSH's. 
Whether or not we need a 'formal' PM
document is another issue, I 
believe the content is already inside
the ebMS2 spec, it just needs to 
be elevated into a concise
document essentially detailing the various 
parameters that one may
set.

- Conformance Profiles.
Using a conformance profiles
document seperate from the main spec or 
embedding it doesn't make a
lot of difference. However, allowing choice 
on things like the
version of SOAP or WSS introduces options that may 
hamper
interoperability on the larger scale. IMO, It would be in the

interest of the market (both developers and users) to fix versions
of 
underlying protocols as much as possible in order to avoid
flexibilities 
that may divide the market. Even when e.g. SOAP 1.2
is backwards 
compatible with SOAP 1.1, it is better to decide on
SOAP 1.1 or SOAP 
1.2, rather than leaving it open. It simply
reduces the number of 
*possible* interoperability issues and the
amount of test sets we need 
to add for interoperability.
If ebMS
3 doesn't decide on SOAP 1.1 or 1.2, it probably also doesn't 
decide
pro or against SOAP 1.3, which may be not so backwards 
compatible.
This extends to all the underlying protocols, and the 
combinatorial
exponent of them..

HTH, kind regards.
Gait
Boxman.

---------------------------------------------------------------------
To
unsubscribe, e-mail:

For additional
commands, e-mail: