Re: How do I poll for messages?

[christopher ferris <chris.ferris@east.sun.com>]

Paul,

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

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.

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

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.

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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard