[erlang-questions] Erlang and MSMQ

[Marcel Meyer]

Thank you for the pointers Tim, and the Erl->.Net->MSMQ path sound the
shortest.
I'll let you know when I've done it. We have parts of our app running on
NServiceBus and
it would be nice to interface to it.

Kind regards,
Marcel

On Wed, Feb 2, 2011 at 5:58 AM, Tim Watson <watson.timothy@REDACTED> wrote:

> On 2 February 2011 03:59, Marcel Meyer <marcel.meyer@REDACTED> wrote:
> > Hi there,
> >
> > I was wondering if anyone was ever successful in publishing to a MSMQ
> from
> > Erlang and how they did it.
> >
> > Regards,
> > Marcel
> >
>
> You might want to look at comet (the erl_com erlang <=> COM bridge
> component). I'm guessing you can access MSMQ using COM. It'll be a
> pretty low level interface, but there won't be much overhead as
> erl_com can run either as an external port program (using stdio to
> talk to the driver) or a linked-in driver running in the same process
> space as the emulator. Running  a linked-in driver is going to be the
> lowest overhead, but there are risks of course.
>
> Also if you're .NET inclined, then a guy on this list has been doing
> recent work on .NET/Erlang interoperability, so you could write a
> wrapper around MSMQ in C# (or whatever CLI language takes your fancy)
> and call it from Erlang. There will be some overhead with this because
> there will need to be I/O between the Erlang node(s) and the .NET
> *node* - but it might make for a clean interface and on the .NET side
> you should be able to expose the MSMQ endpoint very easily with WCF.
>
> A third option might be to write/configure the MQ client part in a
> .NET language, export a COM Callable Wrapper and consume that via
> erl_com, thereby getting your cake (i.e., to write the bulk of your
> code in something reasonable like F# or C#) and eat it - minimising
> hops and getting good performance. Doing that in linked-in driver mode
> is probably a very bad idea though - who knows how two runtime would
> interact in this scenario. Once you've gone to a port program (for the
> reason I mentioned), moving to a .NET node(s) might be worth the
> performance overhead.
>
> All my suggests are based on pure guesswork anyway - I've never tried
> to do this before. I have no idea the status of erl_com, although the
> other .NET integration I mentioned looks fairly active - it is called
> ExtendedVisualOtp IIRC.
>
> Anyway, good luck, and please do post back when you figure out what
> works! I've been thinking about the same issues for bridging to JMS
> providers (where currently I use AMQP and convert to JMS using apache
> camel) so it'll be interesting to see how the MS route turns out.
>