Hello!
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other modules like db_auth. For access to external data it must use HTTPS-server and use REST-style data access (http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 = 'somevalue'" it must call HTTPS-server like this: GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=some...
Server must return delimiter-separated data. Similarly (using POST) it must implement support for insert, update and so on.
Of course we would like to see this module inside the main project repository.
If you are interested please contact me for details (requirements, $$).
Wouldn't it be simpler to write your own middleware daemon / service that plumbs the manager interface (FIFO or UDP datagram) to a REST service exposure in an embedded or peripheral HTTP server, instead of hooking this straight into the Kamailio core?
Konstantin Cherkasov wrote:
Hello!
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other modules like db_auth. For access to external data it must use HTTPS-server and use REST-style data access (http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 = 'somevalue'" it must call HTTPS-server like this: GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=some...
Server must return delimiter-separated data. Similarly (using POST) it must implement support for insert, update and so on.
Of course we would like to see this module inside the main project repository.
If you are interested please contact me for details (requirements, $$).
Or MI_XMLRPC, if you can make it compile with that damn old library version it needs.
Alex Balashov wrote:
Wouldn't it be simpler to write your own middleware daemon / service that plumbs the manager interface (FIFO or UDP datagram) to a REST service exposure in an embedded or peripheral HTTP server, instead of hooking this straight into the Kamailio core?
Konstantin Cherkasov wrote:
Hello!
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other modules like db_auth. For access to external data it must use HTTPS-server and use REST-style data access (http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 = 'somevalue'" it must call HTTPS-server like this: GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=some...
Server must return delimiter-separated data. Similarly (using POST) it must implement support for insert, update and so on.
Of course we would like to see this module inside the main project repository.
If you are interested please contact me for details (requirements, $$).
Hello, Alex!
Wouldn't it be simpler to write your own middleware daemon / service that plumbs the manager interface (FIFO or UDP datagram) to a REST service exposure in an embedded or peripheral HTTP server, instead of hooking this straight into the Kamailio core?
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Konstantin Cherkasov wrote:
Hello, Alex!
Wouldn't it be simpler to write your own middleware daemon / service that plumbs the manager interface (FIFO or UDP datagram) to a REST service exposure in an embedded or peripheral HTTP server, instead of hooking this straight into the Kamailio core?
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Why not just provide an HTTP/REST interface to the database, then?
Perhaps I am missing something about what you are trying to accomplish, but it is not entirely clear to me why it is necessary to have an HTTP/REST layer that specifically utilises the database API in the exact manner it itself is in turn utilised by those modules, as opposed to some other manner.
Hello, Alex!
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Why not just provide an HTTP/REST interface to the database, then?
What if I have database, but it is not Mysql/Postgres/Oracle ? What if one have more complex setup than plain tables (subscriber/aliases and so on)? What if one have some CRM or ERP system without direct data access but with some API instead?
With REST/HTTP layer we can adapt any complex API to SER database API.
In our project we use distributed database without plain tables and plain select/update access.
On Tuesday 23 June 2009 10:06:25 Konstantin Cherkasov wrote:
Hello, Alex!
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Why not just provide an HTTP/REST interface to the database, then?
What if I have database, but it is not Mysql/Postgres/Oracle ?
Well, an ODBC connector could be created insted of HTTP/REST one, that will have a very high performance penalty.
What if one have more complex setup than plain tables (subscriber/aliases and so on)? What if one have some CRM or ERP system without direct data access but with some API instead?
If you have such "complex" scenario, you should develop a way to dump your CRM/ERP data into Kamailio structures and not viceversa.
With REST/HTTP layer we can adapt any complex API to SER database API.
NO, what you do is to add another layer, with a very high performance penalty and also with it owns weakness.
In our project we use distributed database without plain tables and plain select/update access.
Think about what Kamailio/Sip-Router needs and if it's better to develop an interface between Kamailio -> YourSystem or it's better to develop an interface between YourSystem -> Kamailio. I think that the second approach would be better.
On Dienstag, 23. Juni 2009, Raúl Alexis Betancor Santana wrote:
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Why not just provide an HTTP/REST interface to the database, then?
What if I have database, but it is not Mysql/Postgres/Oracle ?
Well, an ODBC connector could be created insted of HTTP/REST one, that will have a very high performance penalty.
Hi Raúl,
there is already a module that connects to ODBC drivers, "db_unixodbc".
What if one have more complex setup than plain tables (subscriber/aliases and so on)? What if one have some CRM or ERP system without direct data access but with some API instead?
If you have such "complex" scenario, you should develop a way to dump your CRM/ERP data into Kamailio structures and not viceversa.
With REST/HTTP layer we can adapt any complex API to SER database API.
NO, what you do is to add another layer, with a very high performance penalty and also with it owns weakness.
In our project we use distributed database without plain tables and plain select/update access.
Think about what Kamailio/Sip-Router needs and if it's better to develop an interface between Kamailio -> YourSystem or it's better to develop an interface between YourSystem -> Kamailio. I think that the second approach would be better.
I can't really comment if its make sense to use such a translation layer as i don't know the system and the exact requirements of the original poster, even if i also like to keep it simple. But if such a translation module is useful to some group, the created code is understandable, documented and maintainable then i don't see a real reason that we this should not be accepted in our repository [1]. Of course it should be implemented in a general way, that it can be changed with some configuration to adapt to different URL schemes, for example, like the SER ldap module.
Henning
On Tuesday 23 June 2009 09:45:03 Konstantin Cherkasov wrote:
Hello, Alex!
Wouldn't it be simpler to write your own middleware daemon / service that plumbs the manager interface (FIFO or UDP datagram) to a REST service exposure in an embedded or peripheral HTTP server, instead of hooking this straight into the Kamailio core?
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
This is a very, very, very, very, very bad idea from performance point of view
Hello, Raúl!
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
This is a very, very, very, very, very bad idea from performance point of view
Do you realy think that LDAP or ODBC layers is better than HTTP?
On Tuesday 23 June 2009 10:53:07 Konstantin Cherkasov wrote:
Hello, Raúl!
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
This is a very, very, very, very, very bad idea from performance point of view
Do you realy think that LDAP or ODBC layers is better than HTTP?
Yes, are better, because are protocols with direct access/map to data, HTTP it's a transport protocol, and you are requesting to use REST on top, so ...
Kamailio <-> REST client <-> XML <-> HTTP <-> XML <-> REST server <-> DB
instead of:
Kamailio <-> LDAP <-> DB or Kamailio <-> ODBC <-> DB
You will have a very high performance penalty, moreover on register/location ops. Think about DB ops that ocurs on timer fires, like location cleaning ops, nat-pinging ops, etc. buff ...
Добрый день, Raúl.
On Tuesday 23 June 2009 10:53:07 Konstantin Cherkasov wrote:
Hello, Raúl!
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
This is a very, very, very, very, very bad idea from performance point of view
Do you realy think that LDAP or ODBC layers is better than HTTP?
Yes, are better, because are protocols with direct access/map to data, HTTP it's a transport protocol, and you are requesting to use REST on top, so ...
Kamailio <-> REST client <-> XML <-> HTTP <-> XML <-> REST server <-> DB
Kamailio is a "REST client" and REST is not requires XML. I think it will be like this: Kamailio <-> (TXT/CSV) <-> HTTP <-> REST server <-> ANY EXTERNAL DB
So, which part is _realy_ slow in this setup? HTTP-server can be very fast. HTTP-server can be load-balanced and distributed. REST layer can be fast and use something like memcached for caching and call distributed database.
I think the database is the real bottleneck in any setup. Can Kamailio connect to several databases? No.
So, we use distributed database cluster (postgres + pl/proxy) and solve this bottleneck in our applications. Now I have headache and have to replicate data from fast distributed cluster to plain tables and FROM(!!!) plain tables to cluster.
instead of: Kamailio <-> LDAP <-> DB or Kamailio <-> ODBC <-> DB
Yes, but what if I don't have plain DB?
OK, do you ever hear about AUTH_RADIUS ? :-)
I just don't want make another stupid auth_SOME, alias_SOME and so on. I think it's better to make db_SOME and use database abstraction layer instead.
Yes, I realize performance challenges. Yes, we must pay for any abstraction.
On Tuesday 23 June 2009 12:41:22 Konstantin Cherkasov wrote:
Kamailio is a "REST client" and REST is not requires XML. I think it will be like this: Kamailio <-> (TXT/CSV) <-> HTTP <-> REST server <-> ANY EXTERNAL DB
So, which part is _realy_ slow in this setup? HTTP-server can be very fast. HTTP-server can be load-balanced and distributed. REST layer can be fast and use something like memcached for caching and call distributed database.
IMHO, you are facing the problem from the wrong side.
What is your final target? a high-end SIP infraestructure or a simple-medium SIP system liked with a high-end CRM/ERP infraestructure ?
I think the database is the real bottleneck in any setup.
Yes, that's true, but there are other way of facing that problem.
Can Kamailio connect to several databases? No.
It can, not as you whant .. but it can.
So, we use distributed database cluster (postgres + pl/proxy) and solve this bottleneck in our applications.
Similar to that, we use Kamailio+pgpool to archive HA-DB access
instead of: Kamailio <-> LDAP <-> DB or Kamailio <-> ODBC <-> DB
Yes, but what if I don't have plain DB?
But it's required for Kamailio to run, you could use whatever you want to archive this, DB VIEWS, external proc's, etc.
OK, do you ever hear about AUTH_RADIUS ? :-)
Yes, we know, at the end it's other DB ;-)
I just don't want make another stupid auth_SOME, alias_SOME and so on. I think it's better to make db_SOME and use database abstraction layer instead.
Yes, I realize performance challenges. Yes, we must pay for any abstraction.
Hello, Raúl!
OK, do you ever hear about AUTH_RADIUS ? :-)
Yes, we know, at the end it's other DB ;-)
OK. Can you imagine auth_http in place of auth_radius or auth_diameter ? I don't think that http with some encapsulated text data is worth then than RADIUS. But I think auth_http is bad idea. db_rest + auth_db is better.
We can make all db-aware modules work with this "database".
On Tuesday 23 June 2009 13:54:01 Konstantin Cherkasov wrote:
Hello, Raúl!
OK, do you ever hear about AUTH_RADIUS ? :-)
Yes, we know, at the end it's other DB ;-)
OK. Can you imagine auth_http in place of auth_radius or auth_diameter ?
Yes I can, when I talk about high performance penalty I'm mainly talking about registrar/location (save() and lookup()) and the related timers fires.
I don't think that http with some encapsulated text data is worth then than RADIUS. But I think auth_http is bad idea. db_rest + auth_db is better.
We can make all db-aware modules work with this "database".
On Dienstag, 23. Juni 2009, Konstantin Cherkasov wrote:
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other modules like db_auth. For access to external data it must use HTTPS-server and use REST-style data access (http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 = 'somevalue'" it must call HTTPS-server like this: GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=some...
Hello Constantin,
you probably already investigated this, but are you aware of the http_query function in the utils module?
http://www.kamailio.org/docs/modules/1.5.x/utils.html#id2454145
If this don't meet your requirements yet, perhaps it can be extended?
Henning
Hello, Henning!
you probably already investigated this, but are you aware of the http_query function in the utils module?
http://www.kamailio.org/docs/modules/1.5.x/utils.html#id2454145
If this don't meet your requirements yet, perhaps it can be extended?
Yes I know about http_query(). But I would like to call save() or locate() or alias_db_lookup() instead of scripting.
On Dienstag, 23. Juni 2009, Konstantin Cherkasov wrote:
you probably already investigated this, but are you aware of the http_query function in the utils module?
http://www.kamailio.org/docs/modules/1.5.x/utils.html#id2454145
If this don't meet your requirements yet, perhaps it can be extended?
Yes I know about http_query(). But I would like to call save() or locate() or alias_db_lookup() instead of scripting.
Hello Konstantin,
understand, you'd like to use the normal DB API to do http queries. There is the "perlvdb" module in kamailio, and the "ldap" module in ser that implement something like a virtual DB interface with interfaces with non-SQL sources. Perhaps you can take a look to them to get some ideas. It would be also probably possible to implement this sort of REST-DB translation in perl with help of the perlvdb module, but don't used this module yet.
Henning
-
Alex Balashov -
Henning Westerholt -
Konstantin Cherkasov -
Raúl Alexis Betancor Santana