Perhaps a use case for an ebXML intermediary. Have some address that your
partners can always HTTP push ebMS 3.0 messages to, even when you're not
online. Then you can ebMS3 HTTP Pull messages from that
intermediary.
Sacha's hint is that the SMTP/POP3 combination has offered this model for
email for many years, so that using SMTP/POP3 as message transport would
allow any ISP to become an ebMS3 intermediary ..
Pim van der
Eijk
Sacha,
Nothing to stop you using ebMS v2.0 SMTP support then here - for generic
use.
In your model the little guys will all be v2.0 clients and the SMTP server
takes the place of the ebMS v3 server.
Now - if you have a big partner with an ebMS v3 server - then no need for
those messy gmail accounts!
In fact the ideal would be to have the ebMS client "call home" on say a 2
or 3 times daily schedule - same way as you can check email too.
I think a more realistic model is one where people are involved in a
marketplace with partners - and they are therefore going to have available a
central ebMS server.
However - for those that don't then the central SMTP server provides that
equivalent work - and the big partner can interchange those
emails from their ebMS server.
DW
"The way to be is to do" - Confucius (551-472 B.C.)
Original Message --------
Subject: RE: [ebxml-msg] SMTP support in ebMS
3.0?
From: Sacha Schlegel <sacha@schlegel.li>
Date: Fri, March 30,
2007 12:45 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc:
ebXML Messaging TC <ebxml-msg@lists.oasis-open.org>
Hi David
Am Freitag, den 30.03.2007, 09:07 -0700 schrieb David RR Webber (XML):
> Sacha,
>
> In your scenario - the SMEs only have issues receiving ebXML msgs
-
> not sending.
also sending if you want to send but the receiver is down.
>
> Also - now with the new staged delivery "pull" mode - remote
clients
> could defer delivery until they announce their presence and
"pull"
> queued messages waiting for them.
I understand but if I want to send a message to you and so my server
puts it into its queue for you, so that you can pull and then my server
sends it to you. BUT I do not want to have my server up and running
until you please to come and "pull" for the message ... I may have a
very limited time (short window) that I can be online.
so I think the pull mode is no big help if both parties are small and
not online all the time. I think the pull mode is excellent when there
is a big party which has an always on http server and lots of small
parties that come and go online.
But for two small parties that come and go online the SMTP protocol is
nice. Also because SMTP services are available everywhere (eg simply
open up a gmail account)
I would say that there is no pull mode required for SMTP transport
protocol as Dale said the POP is the equivalent for the PULL.
>
> Seems to me that the v3.0 features actually significantly reduce
the
> need for SMTP at all here.
>
> In fact we could probably create a pMode for this and template
of
> CPA + "pull" message sample - so the v3.0 server would place
messages
> in a queue and then await a request to deliver them.
>
> Now if an SME is sending a message to another SME - then those
should
> be routed thru an intermediary ebMS that guarantees service
> availability to act as the delivery server.
Well you would need such a provider ... and its right now unlikely that
if you a are a small organisation that your ISP, or web-page provider
will provide such an "ebXML" service.
Sacha
>
> DW
>
> "The way to be is to do" - Confucius (551-472 B.C.)
>
>
>
>