RE: [ebxml-msg] Pull Module

Title: RE: [ebxml-msg] Pull Module

Jeff:

-----Original Message-----

From: Jeff Turpin [mailto:]

Sent: Monday, November 29, 2004 3:16 PM

To: 

Subject: [ebxml-msg] Pull Module

Sorry I missed the call last week. You may have already discussed this on

last weeks call, but I have some questions on the Pull Module document. From

my initial reading, the Pull Module document describes "pulling" a single

ebXML Message with multiple payloads. However, some of the Pull Module

elements such as MaxMessages and NumOfMessages refer to "Messages". Do these

elements actually refer to the number of payloads/attachments or the number

of ebXML Messages? In the F-2-F in London, we initially defined the Pull

Module as a single business message MEP. 

<JD> I believe Iwasa meant number of messages (not payloads) so this would be a form of asynchronous Pull. But see my previous in-line comments on the doc from Iwasa: I believe our last f-2-f decisions override (and satisfy) Iwasa requirement. I believe that we do NOT need an "asynchronous" Pull that would not really be a pull but an OK signal to send, after say a temporary unavailability of the receiver. What Iwasa had in mind (please confirm Iwasa!) was not really a Pull in the sense we defined it, but another signal handling occasional connectivity issues (e.g. "ready to receive"). The Pull itself should be always synchronous, 1 per message, and be useful when the pulled messages cannot make it as separate requests to teh receiver.

This meaning that the PullResponse

would be a single ebXML Message containing one or more payloads/attachments,

which all belong to a single business process identified by the Service and

Action element values. All the payloads in this message are identified by

the single MessageId value in the PullResponse message. It is unclear to me

if this is Iwasa's intention in his document. One reason I ask is that in

his PullAcknowledgment example he has included a WS-Reliablility response

which appears to be replying for all the payloads in the PullResponse

message??? 

<JD> We had also decided to have a PullAcknowledgement (with grouping capability) in our model, but as I suggested in my comments on Iwasa doc, it would not be a good idea to reuse WS-Rel header elements in this pure ebMS signal - even if we have to use similar elements.

So overall I think Iwasa requiremetns are addressed in our design, the way we had it in mind at f-2-f.

The only aspect where we may differ with Iwasa proposal, is that Iwasa seemed to consider the Pull as an application level feature (as suggested by the "per sequence" use), while we see it as a lower level feature, transparent to the application layer, and with no need to distinguish per sequence. The fact is, even with our current design, it is implementation decision to allow an app to control somehow the signaling to pull messages or to notify of readiness to receive (out of scope of spec). But that I believe does not need to be controlled at sequence level, as the problems addressed are not sequence-specific but at server level (lack of connectivity, firewall restrictions) 

I guess I just want to be clear on what he is defining as a

Message and what he is defining as a Payload. Cheers!

Jeff Turpin

Cyclone Commerce, Inc.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.