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

[Christophe Hartwig-P. <chr...@re...>]

Patrick Yee wrote:

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

It's a matter of simplicity too : I think Hermes would be simpler to 
implement...

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

Is the application server trust worthy ? it does have DB access 
control... So the postoffice is not less trust worthy than an 
application server... And in most cases, communication between client 
and postoffice would be inter-process... otherwise, JSM over SSL 
implementations are available.

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

My experience is a J2EE app I worked on, which we ported from Orion to 
Weblogic to Websphere... quite smoothly. It used EJBs, servlets, JMS, 
XSLT, etc... The porting effort was not 0, but was not unacceptable 
(except for Websphere 3.x).

JMS, JDBC, J2EE, implementations for all these always offer slight 
variations. However, nobody questions the interest of a standard. The 
same approach would probably apply for the postoffice : a standard which 
does not cover everything is better than no standard when it comes to 
porting to another implementation. In the Java world, the protocol has 
never been the standard (even it it inspires standards): the API sets 
the standard.

The point is : would the J2EE JCP comittee accept an implementation 
(ebXML) which would not rely on a standard (J2EE postoffice ?) to remain 
abstract ? I don't think so, and I would not either. The second question 
is: if ebXML is not part of J2EE, does it mean it's not an Enterprise 
feature ? The answer is definitely no, so a solution must be found ! 
Abstract API is the Java-way solution...

Regards,
Chris