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

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

> 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
>
The registration can still take place via a http call in JMS case. I 
think the use of http call or config file or gui is not a concern at all.

>
> 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
>
Post office can be profiled. That means, post office can support 
multiple underlying protocols, e.g. ebXML, RNIF, WS-Reliable Messaging, 
etc. All the client need to master is a single set of APIs.

> 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.
>
We agree with the vision about business process. It's long. Whether or 
not to make ebxml a part of J2EE specs is already a long way to go. I 
would say it's no longer technical, but rather political. :-)

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

Yup. We need this kind of discussions to fuel the requirement of our 
further development. Thank you.

Regards, -Patrick