activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bom.bom" <sebastien.fouca...@club-internet.fr>
Subject Re: ActiveMQ Exotic Clients
Date Thu, 06 Apr 2006 22:33:18 GMT

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.


Mime
View raw message