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

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

Sorry for late response again.

> 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.
>
Good point. Using JMS, or other reliable service, is the ultimate 
solution. Currently, the argument to use HTTP is that the Hermes 
server/Hermes client communication is within a relatively stable network 
environment, e.g. inside a corporate. In this case, the demand for a 
error-tolerant channel is lower.

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

> 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 ?
>
The problem is: is Postoffice trust worthy? I don't think so. The 
database can only be read by authorized persons through DB access control.

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

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

We have some negative experience when using JMS, and other J2EE 
technologies: although the spirit of J2EE technologies is to decouple 
the abstract programming model and the implementation, it's still not 
very easy to make easy replacement of actual implementations. That is, 
when I build a system using J2EE technologies, it's easy for me to fall 
into the "trap" of the vendors and become locked in. :-)

Do you have any experience to share on this part?

Regards, -Patrick


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