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

[Ronald v. K. <rv...@ab...>]

Patrick Yee wrote:

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

A lightweight ebxml server like hermes provides almost the same 
functionality. A JMS server also has to persist it's messages and the 
only thing you have to do for it is configure a database or filesystem 
(just like in hermes). Just like CY said, a reliable webserivice is 
possible to and that is IMHO what ebxml is. At least the ebxml ms standard

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

But isn't this abstraction exactely what hermes does with you allowing 
to implement your own messagelisteners? The only difference is that 
registering takes place via a http call rather then a config file or a gui

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

So if you don't want to link the application to ebxml why do you want to 
link it to the postoffice? I'd like my client to link to a nice, clean 
and simple API. If JAXM was done right it would have fitted the ebxml 
messaging/transport layer quite well

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

Agreed to that extent that the application should not have to worry 
about ebxml headers directly. Values of some headers could be relevant 
to the application, or even provided by the application. Again, a simple 
API like the one for JMS would be enough. The only thing that to me we 
are proposing is shifting some  of the reliabilty issues of ebxml from 
the ebxml level to the transport level. It almost looks as if JMS could 
be the core of ebxml based systems. That is excately why I'd like to see 
the redelivery-timeout, maximum time to live etc be standardized in JMS.

>
>> 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 !
>>
Currently it is easier to have a ebxml infrastructure ready (hermes?) 
than a standards based webservices b2b system with reliability (oasis 
has another standard for this almost ready!)

>> 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 :-)
>
Why? you can imo not compare the differences in tibco/jms or tuxedo/jca 
standards to postoffice/ebxml. All these standards provide is some 
functionality and an api. So we want a standardized API right? Isn't 
this what they tried and failed to with JAXM? Again, Adapting the JMS 
standard so it fits perfectly with the ebxml functionality seems good to me

>>
>> 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.
>>
>
Agreed. Again, like IBM and others already said, there is a standard for 
messaging in J2EE. It's called JMS.

> 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?
>
The only vendor traps we (deliberately) fell in are redelivery-delay and 
time-to-live functionality in the JMS implementation of Bea. Which IBM, 
JBoss and probably others have also implemented in there JMS 
implementations but each with other parameters because there are not 
standardized (yet) :-(

> 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.
>>
Hmm...
- the ebxml *messaging standard* is soap w/Attachment + something (e.g. 
hidden reliable delivery), so a protocol
- It had a 'simple' way of persisting messages and have them redeliverd 
later (client could use this easily)
- jaxm itself was not 1-1, that was only the ebxml or rpc implementation 
that came with it (correct me if i'm wrong)

>> 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.
>>
We could go even further. It's not about a Business PostOffice, its 
about Business Processes. Let's give the J2EE specs a ebxml messaging 
protocol/api first and bother about the higher layers later.

Last comment:
I do not want to sound like I disagree with you all, because on a lot of 
points I don't (at all!) but I get the feeling the "PostOffice" is a 
nice, clean api to a messaging system? Without the client having 
knowledge about the underlaying protocols, right?

Ronald