qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: .NET to Java JMS interoperability
Date Tue, 20 Dec 2011 21:53:21 GMT
The .NET Binding to C++ Messaging is not a swig binding. It is a full, C++/CLR interop package
that directly connects managed .NET languages with the C++ Messaging client. If a native C++
client can send a specific message then so can your .NET client.

-Chuck

----- Original Message -----
> From: "Carl Trieloff" <cctrieloff@redhat.com>
> To: users@qpid.apache.org
> Sent: Tuesday, December 20, 2011 1:02:32 PM
> Subject: Re: .NET to Java JMS interoperability
> 
> 
> 
> Here is the JMS example
> 
> http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s04.html
> 
> 
> 
> On 12/20/2011 12:55 PM, Carl Trieloff wrote:
> >
> > Take a look at this section of the doc
> >
> > http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s11.html
> >
> > examples for C++, .NET and JMS.
> >
> > Carl.
> >
> >
> > On 12/20/2011 12:46 PM, Fraser Adams wrote:
> >> Hi Jan,
> >> ISTR reading at one point that the .NET binding is a SWIG wrapper
> >> around the C++ qpid::messaging (though I could have just imagined
> >> reading that :-)).
> >>
> >> One thought if that is the case (totally an idle musing and I've
> >> no
> >> idea if it would work - I've definitely not tried it!!) is whether
> >> it
> >> would be possible to send a Variant string with an encoding set to
> >> utf8 as the message content. "just maybe" that'll get interpreted
> >> as a
> >> TextMessage. As I said previously variant strings with default
> >> encoding are treated as byte[] when sent as Map contents but if
> >> the
> >> encoding is set to utf8 they are treated as String when sent as
> >> Map
> >> contents.
> >>
> >> It's worth a punt, but I rather suspect that your most likely
> >> options
> >> are:
> >> a) Sent your data as an octet array and make an assumption based
> >> on a
> >> "bilateral agreement" that the octet array is a utf8 string and
> >> use
> >> that to construct a Java String.
> >> b) Sent the data as above but pass a content-type to explicitly
> >> tell
> >> the consumer that this is indeed a utf8 string (though as I
> >> mentioned
> >> before getting the content-type in Java is a bit of a faff).
> >> c) Write your text as a Variant string with utf8 encoding to be
> >> stored
> >> in a Map and sent the Map message. As I mentioned previously most
> >> of
> >> the documentation in programming in Apache Qpid at least alludes
> >> to
> >> the fact that Map messages are likely to be the way to go if you
> >> need
> >> to interoperate.
> >>
> >> As it happens QMF2 uses Map Messages extensively to interoperate
> >> (definitely works between Java/C++/Python) but as I mentioned
> >> previously it's not foolproof and I had to incorporate quite a bit
> >> of
> >> defensive programming to avoid a world of ClassCastException fun
> >> as
> >> what gets returned is far from consistent :-)
> >>
> >> There are inconsistencies even with quite important things, for
> >> example there was a bug with the qpid::messaging AddressParser
> >> that
> >> resulted in headers exchange bindings in Address Strings getting
> >> mapped as binary strings, which would never map headers created in
> >> say
> >> a Java application - Gordon Sim has fixed that recently, but I
> >> expect
> >> there are a few other edge cases floating around to trap the
> >> unwary.
> >>
> >> Still life would be boring if it was all easy :-D
> >>
> >> Frase
> >>
> >>
> >> Jan Bares wrote:
> >>> Thanks for your time and answer. I was just affraid that we
> >>> missed
> >>> something as the .NET API is not very well documented. I am
> >>> already
> >>> aware of the encoding and content-type methods on C++/.NET API
> >>> and I
> >>> was thinking that for instance specific content-type may trigger
> >>> JMS
> >>> to interpret data as TextMessage. Certainly looking into sources
> >>> will
> >>> help a lot.
> >>>
> >>> Thanks, Jan
> >>>
> >>>  
> >>>> -----Original Message-----
> >>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> >>>> Sent: Tuesday, December 20, 2011 12:46 PM
> >>>> To: users@qpid.apache.org
> >>>> Subject: Re: .NET to Java JMS interoperability
> >>>>
> >>>> Hmmm,
> >>>> That's an interesting in a more general sense with respect to
> >>>> interoperability.
> >>>>
> >>>> My suspicion is that there are only a few types that will safely
> >>>> interoperate. Octet arrays are clearly one and I believe that
> >>>> Map
> >>>> messages are another way to (fairly) safely interoperate. I say
> >>>> fairly
> >>>> because there are still issues, for example in C++ creating
> >>>> Variant
> >>>> stings defaults to a binary representation that is represented
> >>>> in Java
> >>>> as a byte[]  so you need to do setEncoding("utf8") to  have them
> >>>> encoded
> >>>> as strings that Java can safely interpret (I usually end up
> >>>> writing a
> >>>> fair bit of defensive code to interpret types).
> >>>>
> >>>> One approach might be to use the content-type header to inform
> >>>> your
> >>>> application how to interpret the bytes, but that's not trivial
> >>>> either
> >>>> as
> >>>> the content-type isn't visible in pure JMS I had to cast to the
> >>>> underlying implementation e.g.
> >>>>
> >>>>
> >>>> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
> >>>> Type("amqp/list");
> >>>>
> >>>> Which isn't ideal and isn't technically a supportable approach.
> >>>>
> >>>> Sorry I can't give a more direct answer to your specific
> >>>> question, but
> >>>> I
> >>>> hope it's of some help.
> >>>>
> >>>> Frase
> >>>>
> >>>> Jan Bares wrote:
> >>>>    
> >>>>> Hi,
> >>>>>
> >>>>> is it possible to pass messages from .NET to Java JMS that will
> >>>>>       
> >>>> appear as TextMessage in JMS? Currently messages appears in JMS
> >>>> as
> >>>> BytesMessage. We have not found any way how to control this from
> >>>> .NET
> >>>> API.
> >>>>    
> >>>>> Thank you, Jan
> >>>>>
> >>>>>
> >>>>>       
> >>>
> >>>
> >>>
> >>>
> >>> DISCLAIMER
> >>> WOOD & Company Financial Services, a.s. and its branches are
> >>> authorized and regulated by the CNB as Home State regulator and
> >>> in
> >>> Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS
> >>> and
> >>> in the UK by the FSA as Host State regulators.  For further
> >>> information about WOOD & Co., its investment services, financial
> >>> instruments and associated risks, safeguard client assets (incl.
> >>> compensation schemes) and contractual relationship please see our
> >>> website at www.wood.cz under section Corporate Governance.
> >>> Unless otherwise stated, this transmission is neither an offer
> >>> nor
> >>> the solicitation of an offer to sell or purchase any investment.
> >>> All
> >>> estimates, opinions and other information contained herein are
> >>> subject to change without notice and are provided in good faith
> >>> but
> >>> without legal responsibility or liability. Opinion may be
> >>> personal to
> >>> the author and may not reflect the opinions of WOOD & Co.
> >>> Communications from sales persons, sales traders or traders
> >>> should
> >>> not be regarded as investment research and may contain opinions
> >>> or
> >>> trading ideas which are different from WOOD & Co. investment
> >>> research opinions.
> >>> This e-mail and any attachments are confidential and may be
> >>> privileged or otherwise protected from disclosure. If you are not
> >>> a
> >>> named addressee you must not use, disclose, distribute, copy,
> >>> print
> >>> or rely on this e-mail and any of its attachments. Please notify
> >>> the
> >>> sender that you have received this email by mistake by replying
> >>> to
> >>> the email, and then delete the email and any copies of it.
> >>> Although
> >>> WOOD & Co. routinely screens e-mails for viruses, addressees
> >>> should
> >>> scan this e-mail and any attachments for viruses. WOOD & Co.
> >>> makes no
> >>> representation or warranty as to the absence of viruses in this
> >>> e-mail or any attachments. Please note that to ensure regulatory
> >>> compliance and for the protection of our clients and business, we
> >>> may
> >>> monitor and read e-mails sent to and from our server(s).
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> Apache Qpid - AMQP Messaging Implementation
> >>> Project:      http://qpid.apache.org
> >>> Use/Interact: mailto:users-subscribe@qpid.apache.org
> >>>
> >>>
> >>>   
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project:      http://qpid.apache.org
> >> Use/Interact: mailto:users-subscribe@qpid.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project:      http://qpid.apache.org
> > Use/Interact: mailto:users-subscribe@qpid.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message