Languages bindings [moved]

[lvca]

This is Issue 129 moved from a Google Code project.
Added by 2010-10-03T01:52:41.000Z by CloudBe...@gmail.com.
Please review that bug for more context and additional comments, but update this bug.
Closed (Done).

Original labels: Type-Enhancement, Priority-Low

Original description

Basically, i were searching and asked here for a PHP native client for OrientDB instead of facing the performance barrier with REST.
Luca mentionned the OrientDB binary protocol. That's an interesting approach but if, in this domain things can't be straighforward, it's even non-trivial at all to say the least.
I also though that maybe an overall approach fitting different languages (so including php) could bring higher benefits.
That's why i started to find potential solutions in order OrientDB can be used with a range of non Java clients, and as my speech here is a quite long, i opened a new issue instead of feeding the "native php" thread.
Luca, i know you prefer to rely on your own protocol but please let me expose the scene setting/proposition and then you do whatever you want with it.

Until some people come for supporting and maintain different language bindings for OrientDB (even by being positive in supposing they will come, it will take very much time), a lot will come and face the no solution barrier for alternate languages regarding OrientDB inhouse protocol and finally many will go elsewhere to find something that fit their needs (as the competition is quite rude these days). My proposition is to avoid the "waiting situation" and to find a way to attract people staying here, that would be easier for OrientDB community to grow. Even if the OrientDB proprietary protocol is the ideal solution at the end, maybe what could be considered an alternate solution giving both a quick answer and more choices, so a quick OrientDB level adoption as much as representative as the one we can see for MongoDB http://www.mongodb.org/display/DOCS/PHP+Libraries%2C+Frameworks%2C+and+Tools

During my searching, my attempt were to find a lightweight middleware or library, well maintained and documented, supporting from several to many language clients (also still maintained) using a fast protocol (still maintained at its core and alternative language side) and so making the approach of OrientDB easier when coming from different languages. As a basis of exposition and discussion, three of them have quite some of the good researched qualities : STOMP, ICE and AMQP. They are focused on sending and receiving messages between disparate systems, and if possible in a standard way like is JMS for java. 

- AMQP is this emerging standard on a wide level. it provides flexible routing, including common messaging paradigms like point-to-point, fanout, publish/subscribe, and request-response. It also supports transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support. Implementations provide APIs for C#, C++, PHP, Python, Ruby, and other languages. It could be an innovative approach with a positive buzz for OrientDB. Unlike REST which is not ideal for message flows where real time order flows and market data, AMQP is middleware to provide a point of rendezvous between backend systems, such as data stores and services and front end systems such as end user applications. AMQP is nicely licensed. Besides, it's models and patterns are very interesting, it could also be an option for the replication mechanisms between OrientDB servers if it ever can help.
RabbitMQ is among the few that mention many language implementations here http://www.rabbitmq.com/how.html. A good example of AMQP for couchdb access http://www.listware.net/201008/couchdb-user/112450-ann-couchdb-access-via-amqp.html


- STOMP is a simple text based-protocol for which it's easy to implement language clients. Some of them exposed here http://stomp.codehaus.org/Clients. On  the other hand, it's less perfomant and less featured as AMQP, furthermore some 

of these clients are no more maintained (as it is the case for Hessian binary protocol clients). Several say STOMP is not evolving anymore, not maintained, and even not used by its author :)

- ICE is presented as the answer to slow performance of soap and rpc. From their site "The Internet Communications Engine (Ice) is a modern alternative to object middleware such as CORBA? or COM/DCOM/COM+. Ice is easy to learn, yet provides a powerful network infrastructure for demanding technical applications. Ice shines where technologies such as SOAP or XML-RPC are too slow, or do not provide sufficient scalability or security. Ice allows you to focus your efforts on your application logic, and it takes care of all interactions with low-level network programming interfaces. With Ice, there is no need to worry about details such as opening network connections, serializing and deserializing data for network transmission, or retrying failed connection attempts (to name but a few of dozens of such low-level details)". See language supprt here http://www.zeroc.com/languages.html. I always had good feedbacks on ICE but its GPL licence can be or become a problem at some levels.

As speed is a concern, i tried to avoid XML based messaging protocol in my researchs, like XMPP and Beep, i look at AMQP as a more promising & more featured approach but if you want to read an interesting comparison of AMQP and XMPP, here it is http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/

Now, i'm not an addict of AMQP, i'm just trying to expose the approach of a message queuing protocol, what could be our options, their benefits for OrientDB. In fact, on a more specific and personal level, i may be the advocate for a more or less AMQP competitor : ZeroMQ which i look more adapted for the purpose of OrientDB proposition, particulary for less drawbacks, less pain, more performance, lightweigh among the few. ZeroMQ uses ZPL which exists because alternatives were inadequate as they expose this way :

    * XML cannot be read or written as a stream.
    * JSON cannot be read or written as a stream and is clumsy to edit due to delimiters between item lists.
    * YAML is relatively complex to parse.
    * UNIX-style configuration syntax does not support name hierarchies.

ZeroMQ => http://www.zeromq.org/, in particulary mentions comparison elements : 

    * TCP: message based, messaging patterns rather than stream of bytes.
    * XMPP: simpler, faster, and more low-level. Jabber could be built on ØMQ.
    * AMQP: 100x faster to do the same work (and 278 pages less spec).
    * IPC: we abstract across boxes not only a single machine.
    * CORBA: we do not enforce horrible complex message formats on you.
    * RPC: ØMQ is totally asynchronous (so, like jms, each client is intended to develop its own custom wire protocol for talking to the broker) , and lets you add/remove participants at any time.
    * RFC 1149: a lot faster!
    * 29west LBM: we're free software!
    * IBM Low-latency: we're free software!
    * Tibco: we're still free software!

(Note : in fact, ZeroMQ has a little wire protocol, see http://www.zeromq.org/blog:road / http://www.zeromq.org/whitepapers:design-v05)

On the comparison side between AMQP and ZeroMQ, it is mentionned they cover some of the same ground but they take very different approaches. ZeroMQ acts more like low-latency products while AMQP acts more like JMS.
For more information, i invite you to read these two articles : 
Welcome to ØMQ for AMQP users http://www.zeromq.org/docs:welcome-from-amqp
ZeroMQ introduction http://nichol.as/zeromq-an-introduction

I conclude by mentionning Second life which did an overall approach on this subject of message queue for their need, so if you have time and interests to read, it's exposed here 

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes