Menu
▾
▴
RE: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Ronald v. K. <rv...@ab...> - 2003-11-16 23:03:04
|
-----Oorspronkelijk bericht----- Van: Patrick Yee [mailto:kc...@ce...] Verzonden: zaterdag 15 november 2003 15:35 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS 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? [Ronald van Kuijk] Not much I think, other than that it could be a (defacto?) standard to connect JMS servers of different origin 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? [Ronald van Kuijk] probably a lot like is done now in hermes.. after sending out a message by putting it in a jms queue, you register a listener on the incomming queue with a filter. This could be a filter which looks for a 'RefToMessageId' identical to the MessageId used when sending out the message (jms has a messageid). Or a more complex one where ebxml message header fields (or service, action, conversationid) are mapped to extended jms header properties. 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? [Ronald van Kuijk] Hmm.. depends on who creates the envelope. If the client that puts the message in a queue generates the envelope, it could not be fully encrypted, at least not the relevant fields. otoh, these could also be put in jms header fields that can be used by the postoffice without looking into the envelope. just my 0.018 Ronald Thanks. Regards, -Patrick ----- Original Message ----- From: Christophe Hartwig-Peillon <mailto:chr...@re...> To: ebx...@li... <mailto:ebx...@li...> 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 to the problem: There is no specification in J2EE concerning messages that should get out of the system. JMS only concerns sending messages reliably to a queue. Even JMS bridges 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 messages out ! What we need is a JMS postoffice ! That's why the match between JMS and ebXML is not easy : ebXML is a distribution (in the sense of mail distribution) protocol. What would be cool is to think in terms of an ebXML postoffice. When you want to send snail mail, you post your letter in a mailbox, except this 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 be delivered, should a receipt be expected, should the message be signed, should the message use the HTTP or SMTP path (remember the AirMail stickers on letters ?), should a return address be used for 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 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 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 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 related to it!), is not about reliable messaging, but about inter-system reliable routing and sending of messages... This is a functional area not yet covered by other Java specifications, so there should be some 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... <mailto:cha...@re...> 17, avenue Andre Roussin http://www.reservit.com <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 --------------------------------------------------------------------- ------------------------------------------------------- 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/ <http://sourceforge.net/donate/> _______________________________________________ ebxmlms-general mailing list ebx...@li... <mailto:ebx...@li...> https://lists.sourceforge.net/lists/listinfo/ebxmlms-general <https://lists.sourceforge.net/lists/listinfo/ebxmlms-general> |
