Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

[Patrick Y. <kc...@ce...>]

Christophe,

Thank you for your cool idea. That makes me excited too. To further the =
discusison, I have the following questions:

1. What is the difference of your proposed ebXML post office and a ebXML =
MSH with a pair of JMS queues, one for accepting message to be sent out, =
and one for the messages to be delivered back to the client?

2. In an ebXML post office, how can different applications to get their =
own messages back? I mean, how the post office partition the messages =
for different clients?

3. How about encryption? If the post office should examine the messages =
before to send it out, does that imply we have to sacrifice end to end =
security?

Thanks.

Regards, -Patrick

  ----- Original Message -----=20
  From: Christophe Hartwig-Peillon=20
  To: ebx...@li...=20
  Sent: Monday, November 03, 2003 4:59 PM
  Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, =
through JMS


  Hi all,

  I've been thinking more about it this week end... Here is a new =
approach=20
  to the problem:
  There is no specification in J2EE concerning messages that should get=20
  out of the system.
  JMS only concerns sending messages reliably to a queue. Even JMS =
bridges=20
  simply allow sending messages to a queue and forwarding to an external =

  queue (JSM to Tibco bridge for instance)... There is no way to take =
JSM=20
  messages out !

  What we need is a JMS postoffice ! That's why the match between JMS =
and=20
  ebXML is not easy : ebXML is a distribution (in the sense of mail=20
  distribution) protocol.

  What would be cool is to think in terms of an ebXML postoffice. When =
you=20
  want to send snail mail, you post your letter in a mailbox, except =
this=20
  mailbox is then emptied by the postman, and the mail is dispatched.
  Internal mail (in a company) does not go through a postoffice, you put =

  the letter in you recepient's mailbox : that's JMS...

  ebXML actually determines the distribution : to whom should the =
messages=20
  be delivered, should a receipt be expected, should the message be=20
  signed, should the message use the HTTP or SMTP path (remember the=20
  AirMail stickers on letters ?), should a return address be used for=20
  replying, etc...
  I like this approach because :
  - everybody now understands the difference between JMS and ebXML goals
  - the need for ebXML is obvious
  - the lack of an existing standard is obvious too
  - the mismatch of JAXM and these goals is obvious (because JAXM does =
not=20
  try to play this postoffice role, does not have postoffice semantics)
  - the fact that JMS and ebXML are related is clear : JMS is for =
posting=20
  the letter, ebXML is sending it in the right place. ebXML is receiving =

  the mail from the postoffice, JSM is for opening and reading the =
letter...
  - CPAs are used to tell the postoffice what it should do, how the=20
  message can reach its recepient, etc...

  Do you like it this way ?

  I like the idea of a JSR... Because ebXML is now different than JMS =
(but=20
  related to it!), is not about reliable messaging, but about =
inter-system=20
  reliable routing and sending of messages... This is a functional area=20
  not yet covered by other Java specifications, so there should be some=20
  place for it... Note that there are JSRs related to CPPs/CPAs =
already...

  I'm eager to hear your opinion !
  Bye
  Chris

  ---------------------------------------------------------------------
   Christophe HARTWIG - Interface Technologies   cha...@re...
   17, avenue Andre Roussin                    http://www.reservit.com
   ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
   13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
  ---------------------------------------------------------------------=20




  -------------------------------------------------------
  This SF.net email is sponsored by: SF.net Giveback Program.
  Does SourceForge.net help you be more productive?  Does it
  help you create better code?   SHARE THE LOVE, and help us help
  YOU!  Click Here: http://sourceforge.net/donate/
  _______________________________________________
  ebxmlms-general mailing list
  ebx...@li...
  https://lists.sourceforge.net/lists/listinfo/ebxmlms-general