Menu
▾
▴
Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Christophe Hartwig-P. <chr...@re...> - 2003-11-27 13:03:12
|
Hi, Sorry for taking so long to answer... > 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? 1. I believe there is a need for a postoffice in J2EE. Whether one implementation of this postoffice uses ebXML is another question :-) However, using JMS queues to link Hermes and the Hermes client would be cool (as a first step maybe) : IMHO, one weak point of Hermes is the HTTP transport between the client and the MSH, because when there is a need for guaranteed delivery, the application has to persist its own messages before attempting to send them to Hermes, just in case the delivery is not possible immediately (Hermes down for instance)... Using JMS, you could simply use JMS reliable messaging to make sure the message WILL be sent by Hermes. > 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? 2. I believe there would be a need for configurability of the postoffice (read XML deployment descriptors) like all other J2EE technologies. Its goal is to redirect incoming message to different JMS queues depending on... it depends on the protocol, so must be abstracted :-) ... in the case of ebXML, depending on CPAid, or fromParty, or toParty, or Service, or Service/Action or a combination... > 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? 3. I believe the important point is that encryption must appear somewhere within the system boundaries where security is OK. Is security OK between Postoffice and JMS clients ? Well, its tough to hack inside an application server (the client could now stand in the same process as Hermes) ! However, I think I would rather use JMS headers (instead of ebXML headers) to tell the Postoffice what to do with messages, because I would not want to link my client application to ebXML but to the PostOffice... so as to use another protocol if needed. Regarding end to end security... think of it: is your database encrypted too ? And... whether encryption is required or not depends on the CPA, which IMHO would be better handled by the postOffice itself... Let's talk about it. There would be a good match between the CPA (in terms of agreement) and the tasks of the PostOffice... I mean if I had to implement this postOffice, I would handle CPAs (and what is related to communication, encryption, sync-replies or not, reliable messaging or not, etc...) at the postOffice (well, its ebXML implementation), not at the "JMS client" level. The JMS client would then need to know nothing about ebXML (or other protocols !) : just tell the postOffice where you want the message to go (in abstract terms) and what message it is (in abstract terms), and the postOffice knows how/where to send the message... ebXML headers are filled-in at the very last minute, the application needs not care about ebXML headers anymore... I believe abstracting ebXML is important... I like ebXML, but I believe web services have (or will soon have) extensions to make them appropriate for reliable messaging, ordered delivery, etc... ebXML is not the only protocol we can think of in terms of B2B communication... IBM has Reliable Messaging specs available for comments... and business process orchestration... etc... And when your trading partners don't have an ebXML infrastructure ready, you need to rely on something else ! The J2EE community would better accept ebXML if the specs for integrating ebXML to J2EE are open to other technologies... Look at J2EE technologies : they always make abstraction of the actual implementation... You don't have Tibco support, but you have JMS. You don't have Tuxedo support, but JCA. You must have PostOffice to have ebXML support :-) IBM and BEA just announced their work on SDO : an API to work with data, from XML to RDBMSes, etc... The need for abstraction is everywhere. We first abstracted the implementations (JMS, JDBC, JCA), now we abstract the actual nature of things... I'm afraid we can't have ebXML support in J2EE if we don't have a good abstract spec... which JAXM is not. I think JAXM is a bad match for ebXML because it treats ebXML as SOAP w/Attachment+something, as a protocol and nothing more. ebXML is more than that, it's about B2B communication, 1-n relatioships, not a 1-1 relationship. Don't you think there is a lack in the J2EE specs : there is no spec yet for "get business messages out of the app server, to my business partners, and receive messages from them". It's not about a protocol, it's about a Business PostOffice. My 2 cents Chris Patrick Yee wrote: > 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 ----- > *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 > 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/ > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > <mailto:ebx...@li...> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > -- --------------------------------------------------------------------- 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 --------------------------------------------------------------------- |
