[zeromq-dev] NYSE OpenMAMA

Ciprian Dorin Craciun ciprian.craciun at gmail.com
Wed Nov 2 22:11:56 CET 2011


2011/11/2 Daniel Cegiełka <daniel.cegielka at gmail.com>:
> [reordered]
>
> If MAMA will be (in the future) some standard in finance, it's worth
> to prepare a bridge for zeromq.

    Certainly it's suitable to prepare a "bridge" for the most
important "frameworks" (OpenMAMA included, and maybe also a JMS one),
thus allowing either interoperation, or easily swapping over.


> MAMA is yet another layer between the messaging and user apps. Whats
> interesting in this is the connection between messaging and MAMA
> formed by bridges. With this solution your application can be
> consistent only with a MAMA API - and TIBCO RV or ZeroMQ API are
> separated by MAMA.
>
> I do not know if this is a good solution. MAMA API isn't clean as
> zeromq APIs, so it's only complication (for developer). You might as
> well hide other data sources bihind zeromq (+topic filtering) and the
> effect will be similar to MAMA.
>
> [moved to top]
>
> regards,
> Daniel

    I'm just wondering if this is not "yet another passing trend",
like ESB (Enterprise Service Buses) was a few years ago... (Actually
they've promised exactly the same, but I think the frontend library
was presented as a SOAP based web service.)

    Ciprian.


> 2011/11/2 Ciprian Dorin Craciun <ciprian.craciun at gmail.com>
>>
>> 2011/11/2 Daniel Cegiełka <daniel.cegielka at gmail.com>:
>> >
>> > How OpenMAMA Works
>> >
>> > OpenMama uses a common publish/subscribe idiom (pub/sub). In this messaging
>> > pattern the messages are not sent directly to the receivers, but published
>> > to a topic. Subscribers express interest in one or more topic, and receive
>> > only messages that concern them. This decoupling of publishers and
>> > subscribers allows for greater scalability.
>> >
>> > [...]
>>
>>
>>    Now maybe this is a little off-topic -- although the initial
>> developers of ZeroMQ also developed the first version of AMQP (if I
>> recall correctly???) -- but here it goes... :)
>>
>>    Now when I've first seen AMQP I've said: "finally a protocol which
>> is both simple, flexible and implementable"... (Unfortunately each
>> broker is still compatible only with the "sanctioned" libraries...)
>> But still, AMQP was born from the shortcomings of existing solutions,
>> especially JMS, which was API based, not protocol based, and I had
>> high hopes... (Currently I use both RabbitMQ and ZeroMQ for different
>> purposes.)
>>
>>    So from what I've seen on OpenMAMA page, they go back to an API
>> based standard, thus allowing API "extensions" to cripple any window
>> of portability... Why??? (It's just like instead of having HTTP, IETF
>> would have defined an API and made it "pluggable"...)
>>
>>    (I would love to hear the opinion of other ZeroMQ developers and
>> users on this topic.)
>>
>>    Thanks,
>>    Ciprian.
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list