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

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

Patrick Yee wrote:

> Christophe Hartwig-Peillon wrote:
>
>> Hi all,
>>
>>>        What do you think if the interface between the client and Hermes
>>> is Web Service? (Maybe with reliability as well.) In this case, the 
>>> client
>>> side need not be JMS API call at all while Hermes server need not use
>>> a JMS provider and it already sits there to receive HTTP Web Service 
>>> call.
>>> So far, Hermes does not yet touch the J2EE, JMS features and can be 
>>> thus
>>> deployed in an app server as simple as Jetty that SMEs' may feel a 
>>> little
>>> bit light-weight.
>>>  
>>>
>> As far as I know, Hermes and the client already rely on an HTTP based 
>> protocol... The problem is reliability : when two processes 
>> cooperate, you take the risk of having one down (hermes in our case). 
>> In this case, the whole system is down...
>> Relying on JMS, in the context of an app server, suppresses this 
>> problem.
>
In the context of the appserver yes, but then you could also call some
other classes directly, just as is configurable now with hermes.

>> Another interest of JMS is load balancing/fault tolerance.
>> Maybe other free JMS implementations could be used... there are many 
>> of them !
>
Yes but not a lot of them support automatic loadbalancing AND failover
at the same time. e.g. JBoss > 3.2.2 and Bea >WL6.1 do loadbalancing but
no automatic failover
Hmm.. i wonder btw what transport protocol JMS is using if the client is
outside the appserver? HTTP? RMI? RMI over HTTP? Some proprietary protocol?

>>
> Another concern is exclusivity of Java world. A postoffice, by its 
> nature, does not imply Java. MQSeries does provide JMS interface, but 
> JMS is definitely not the only way to access MQ. Some demands we have 
> here is to make a postoffice neutual enough to let clients from other 
> worlds (e.g. .net) to use it.

OpenPostoffice ->JMS ->J2EE
MS-PostOffice -> MS-MQ -> MS

>
>> I must confess I have an app server in my system (jBoss, clustered 
>> for fault tolerance). Does it mean that the protocol between Hermes 
>> and the client should be made pluggable ? This suits the J2EE spirit...
>>
> Pluggable? Hmm.... do you mean allowing multiple ways for the client 
> to connect to Hermes? In the best case, we can find a standard and 
> everybody connect to Hermes (and others message servers) in the same 
> way. I believe that one day we will have it.
>
If there is a good api for application <-> msh connections the
underlying protocol is not relevant.. otoh... with JMS the same problem
exists. Yoou have to use Bea classes to connetct to the Bea JMS server,
the same is true for the JBoss, IBM-MQ etc... A real standardized
'wire-protocol' (so not like JMS) would be best I think.

>> Anyway, I tried to correlate the kind of architecture hermes could 
>> have with requirements for inclusion into J2EE...
>> ebXML, with JAXM is out of J2EE.
>
>
>
> Afterall, I must confess that it makes sense to include ebXML into 
> J2EE. It's enterprise thing.

I agree... will hermes start using all of the functionality that is
present in J2EE servers then? (connectionpooling, transactions) ;-)

Ronald