RE: How do I poll for messages?

["Morin, Paul" <prm@scinteract.com>]

Comments in-line...

 - Paul

Paul R. Morin
Co-Chairman, AIAG Message Routing Workgroup


-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Sunday, March 11, 2001 11:20 AM
To: Morin, Paul
Cc: ebXML Transport
Subject: Re: How do I poll for messages?


Paul,

How does use of SMTP and one of the other (POP, IMAP)
client protocols "force" a TP to use HTTP to send?

<response>
I said "its likely to force the TP to use two different protocols" because I
assume most implementations will use an HTTP listener as the "primary"
inbound methodology.  I didn't say this is the case across the board...
</response>

It seems reasonable to me that email could be used
effectively for both send/receive. I also don't perceive
this as "widely inefficient" even if both SMTP and HTTP
were being used. People have browsers (with which they
do HTTP query/response stuff) and they use MUAs to do
asynchronous messaging. Some of the tools available
handle both (Netscape for one) Most of the environments
available support both in some shape or form.

<response>
I'm not a big fan of EDI over mail.  I agree that it can work, but I prefer
the request/response aspect of HTTP.  I'm even less a fan of separating the
process across multiple protocols.  I believe that it adds un-necessary
confusion to the process by creating separate audit trails and by increasing
the number of processes to monitor.  And again, I said "depending on who's
tools the TP is using." I was not lumping everyone into the same bin.
</response>

I agree that no one standard will make everyone happy
if by happy, you mean "will do things exactly the way that they are
doing them today using the software that has been written to
date."

<response>
No, what I'm saying is, I'd rather have 4 different rigidly defined
standards that serve different purposes than one monolithic, option filled
protocol that tried to please everyone.  Its easier to implement and has a
far greater chance of vendor wide interoperability.  It also has a larger
cost/benefit value to the customer.
</response>

Note also that there is nothing in the TR&P protocol that
prevents, or in any way impedes, one from designing a message 
exchange such as you and Cameron have described (a poll-based
message exchange) using the headers, packaging and everything
else that the TR&P specification defines. Nor does the
ebXML TR&P Message Service (IMO) make this type of 
exchange any more or less efficient than had we designed
the "polling" service.

I can easily envisage a service that was comprised of
a "nextMessage" action (XML message payload) that 
returned/responded with the next message in the "queue" for 
the party sending the "nextMessage" message. It would be an 
application of the Message Service that only those which 
desired this manner of functionality need implement/deploy. 

This service could also be implemented as a transport-level service, 
where the outbound (and/or inbound) message spool were implemented
as SMTP/IMAP or POP, or it could be implemented as HTTP
with synchronous responses, or it could be implemented
via some other, possibly proprietary, protocol.

I have always believed the ebXML Message Service
to be a foundation upon which one can build
whatever they might desire, not an implementation of
everything there is.

<response>
This is my point.  Everything is "possible" if you just implement/deploy it
that way...  Getting a group of vendors to all do it the same way is another
trick.  Remember, this thing only works if a customer can buy something that
interoperates with what his trading partner has.
</response>

My $0.02,

Chris

"Morin, Paul" wrote:
> 
> I agree SMTP could be used as an outbound alternative for TPs who do not
> have an "always on" connection, but its likely to force the TP to use two
> different protocols.  HTTP to send, POP or IMAP to receive.  Now its a
> software implementation issue that may be
> "widely inefficient" depending on who's tools the TP is using...
> 
> I've never pushed this issue because the process is available in the
AIAG's
> E-5 Guideline for TCP/IP Message Routing.  We call it "obtain" and it
works
> great.  The smaller TP sends an XML query to the remote server that
bundles
> like documents into a multipart response.  The client then issues an XML
Ack
> for each document they correctly receive and process.  I agree that its
not
> as efficient as PUSH, but in the automotive industry we have a large
number
> of very small trading partners that need a "dialup" solution...
> 
> <editorial>
> We'll never create a single message routing standard to make everyone
> (individuals and industries alike) happy.  I'd much rather deal with
several
> "simple" standards than one hugely complex beast that's impossible to
build
> and distribute at a reasonable cost.
> </editorial>
> 
>  - Paul
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Sunday, March 11, 2001 9:07 AM
> To: Cameron Young
> Cc: ebXML Transport
> Subject: Re: How do I poll for messages?
> 
> Cameron,
> 
> Typically, this would be handled via use of SMTP as a
> (sending) transport and IMAP or POP as the "polling" mechanism
> with the queue being your mail spool.
> 
> The "polling" of messages via HTTP would be widely inefficient,
> especially if there are many prospective parties that might have
> queued messages for you! It would also impose a costly
> requirement on the part of your partners to have to persistently
> store your (and others like you) messages.
> 
> HTH,
> 
> Chris
> 
> Cameron Young wrote:
> >
> > Sending messages is OK.
> >
> > But, if I'm a simple MSH that doesn't have a permanent connection, how
> > do I check (poll) for messages?
> >
> > I'd like a "Message Request" added to Section 9. That will cause the MSH
> > to respond with any queued messages for which the To Party matches my
> > sent MessageRequest:From Party.
> >
> > There would have to be an error message indicating no messages pending.
> >
> > It can be really simple and only return one message at a time.
> >
> > Or is this going to go in another spec?
> >
> > Regards,
> > Cameron Young