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

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

Patrick Yee wrote:

>
>> 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?
>>
> Isn't it proprietary?

Depends on the appserver... JBoss gives you several options, including 
http(s)

>
>>>>
>>> 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
>>
>
> We don't want to exclusively use Java. By the same token we don't want 
> to exclusively use .NET. The philosophy of web service is the 
> separation of dependency between the client and server platform, which 
> I think is a good idea.

I know, I don't want exclusivity for Java as well, but imo the 
postoffice calls are kind of local. If things have to be transported to 
a remote location, ebxml is used isn't it? The thing is, if you want 
real reliability and be not dependend on including specific jms 
libraries to access the specific jms server, you get into reliable 
webservices and how small is the step then to ebxml. Kind of like a 
lightweigt client (your ebxml smtp client, but then with some http calls)

>
>>>
>>> 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) ;-)
>>
> Can you wait till next version? ;-)
>
You mean the things I'm checking out now? ;-)

Happy New Year

Ronald