ActiveMQ Exotic Clients

["bom.bom" <se...@club-internet.fr>]

1- Has anybody tried and succeeded in using ActiveMQ from COBOL programs (for
example using the STOMP protocol) especially in EBCDIC environments (my
intended use is a message producer rather than a message consumer) ?

2- In such situations how to cope with encoding issues (EBCDIC / JMS) ?

3- Does the STOMP protocol allow to use the "failover" mode. AFAIK, the
"failover" mode   is handled on the JMS client side. Does it mean that if
want to reproduce that failover mechanism using the STOMP protocol, i have
to implement it myself ?
--
View this message in context: http://www.nabble.com/ActiveMQ-Exotic-Clients-t1408322.html#a3792527
Sent from the ActiveMQ - User forum at Nabble.com.

Re: ActiveMQ Exotic Clients

["bom.bom" <se...@club-internet.fr>]

Hello James,

First of all, I'd like to thank you for your interest about that subject.
You probably know that finding people interested in speaking mainframe,
COBOL and ebcdic becomes harder and harder !!!


James.Strachan wrote:
> 
> I'd love a pure COBOL client for ActiveMQ. 
> 

What do you mean by pure ? Something different than Stomp ? My initial idea
was to embed a Stomp "client" within the COBOL source code.


James.Strachan wrote:
> 
> So far Stomp assumes by
> default that the commands are encoded in UTF-8 AFAIK so we might have
> to use a special EBCDIC flavour of the stomp connector (we could maybe
> auto-detect based on the CONNECT string like XML parsers often do).
> 

I just had a look at the Stomp connector source code to check what is the
encoding expected on the socket byte stream... You are definitely right.
java.io.DataInputStream  instances referenced as DataInput are used implying
an UTF-8 encoding.

To my opinions, there would be three alternatives :
- The first one (your suggestion) consisting in "auto-detecting" the
encoding based on the CONNECT string (unfortunately not enough to manage
several EBCDIC code pages for which the "CONNECT" string would be translated
identically but having slight differences on other characters).

- The second one consisting in "modifying" the stomp protocol with a kind of
optional handshake step allowing the client to specify the encoding it is
going to use (as the xml declaration including the encoding attribute).

- The last one consisting in using "server side filters" (broker side) which
could be located in front of the Stomp connector and which could transcode
the byte stream depending on a parameter (unfortunately static transcoding
making the use of heterogenous clients using different encodings
impossible).


James.Strachan wrote:
> 
> We'd need on the broker to parse all strings correctly as EBCDIC and
> convert to their usual UTF format in Java so that they can be
> exchanged with regular OpenWire/Stomp clients and other brokers.
> 






James.Strachan wrote:
> 
> Failover mode is purely a client side thing where it auto-reconnects
> its socket to another broker on failure, often taking a list of URLs
> to choose from etc. Unfortunately this piece does have to be ported to
> a client.
> 
> An alternative though is to run an ActiveMQ broker process on the
> local machine acting purely as a gateway to the other brokers; such
> that the Java process deals with all the different transports and
> failover modes with other brokers - then the Stomp/OpenWire client
> just always connects on localhost:61613/61616 and lets the Java code
> deal with failover on its behalf.
> 

Indeed, managing the failover at the stomp client level does not sound not
really good idea.
The "gateway mode" is exactly the alternative I was thinking about !


Regards
--
Seb
--
View this message in context: http://www.nabble.com/ActiveMQ-Exotic-Clients-t1408322.html#a3794462
Sent from the ActiveMQ - User forum at Nabble.com.

Re: ActiveMQ Exotic Clients

[James Strachan <ja...@gmail.com>]

On 4/6/06, bom.bom <se...@club-internet.fr> wrote:
>
> 1- Has anybody tried and succeeded in using ActiveMQ from COBOL programs (for
> example using the STOMP protocol) especially in EBCDIC environments (my
> intended use is a message producer rather than a message consumer) ?

I'd love a pure COBOL client for ActiveMQ. So far Stomp assumes by
default that the commands are encoded in UTF-8 AFAIK so we might have
to use a special EBCDIC flavour of the stomp connector (we could maybe
auto-detect based on the CONNECT string like XML parsers often do).


> 2- In such situations how to cope with encoding issues (EBCDIC / JMS) ?

We'd need on the broker to parse all strings correctly as EBCDIC and
convert to their usual UTF format in Java so that they can be
exchanged with regular OpenWire/Stomp clients and other brokers.

> 3- Does the STOMP protocol allow to use the "failover" mode. AFAIK, the
> "failover" mode   is handled on the JMS client side. Does it mean that if
> want to reproduce that failover mechanism using the STOMP protocol, i have
> to implement it myself ?

Failover mode is purely a client side thing where it auto-reconnects
its socket to another broker on failure, often taking a list of URLs
to choose from etc. Unfortunately this piece does have to be ported to
a client.

An alternative though is to run an ActiveMQ broker process on the
local machine acting purely as a gateway to the other brokers; such
that the Java process deals with all the different transports and
failover modes with other brokers - then the Stomp/OpenWire client
just always connects on localhost:61613/61616 and lets the Java code
deal with failover on its behalf.


--

James
-------
http://radio.weblogs.com/0112098/