On Wed, 2009-09-09 at 16:42 -0400, M. Ranganathan wrote: > > > On Wed, Sep 9, 2009 at 12:45 PM, Scott Lawrence > <[email protected]> wrote: > > On Wed, 2009-09-09 at 01:30 -0400, M. Ranganathan wrote: > > > > Hello! > > > > Here is the description of the sipx rest service container > that > > Raymond and I worked on and that I just checked into SVN. > The > > description is a bit sketchy at the moment but I would value > your > > thoughts and ideas on the following: > > > > > http://sipx-wiki.calivia.com/index.php/SIPXRest_Service_container > > > > The third party call controller now runs as a sipXrest > service plugin. > > For those who are using it, here is what you have to do : > > > > make all install in the following directories (in that > order ) : > > > > sipXrest > > > > sipXcallController > > > > Then edit sipXrest/sipxrest.xml > > > > Copy it over to etc/sipxpbx > > > > Star the SipXrest container using > > > > sh sipxrest.sh from the build directory. SipXconfig support > for all of > > this has been requested in a JIRA issue. > > > > In addition to the third party call controller, a call > watcher service > > and a CDR service ( written by Raymond ) will be running in > this > > service container. > > > > I encourage you to think of light weight services that can > be housed > > in this container and that can play a part in integration of > sipx with > > the world at large. > > > The part I'm struggling with is why we would want to put REST > interfaces > into a process that doesn't have the data the interface > needs. > > For example, why put a REST interface for CDR data into > anything but the > call resolver? > > > One argument for a central point of integration could be ease of > administration. Thus we would have a single process to manage / > administer (i.e. the REST server and the ports that it uses ) that > external processes (outside the sipx domain) need to interact with. > Thus far it has been sipxconfig that served this purpose for both > signaling and administration. We can now have one more process - > sipXrest that performs this function for signaling services.
But CDR access is not a signaling service. I have no objection to bundling related services together - my concern is with bundling _unrelated_ services together just because they happen to be REST services. Bundling unrelated service interfaces into containers couples the interface implementations to each other rather than to the data or service that the interface is part of. This will often mean that there needs to be a second internal interface between the REST service and the underlying data or service to which it provides an API. This is exactly the mistake that we made (and have not fixed yet) in the implementation of message waiting indication: we have a process (which was conceived as a plugable container that managed subscriptions for other services, but which in fact has only one service now) that implements the SIP interface to the mailbox, which then requires a bidirectional HTTP backend interface to the mail store. Far simpler would be just integrating the SIP interface into the mailstore directly. This has implications for when we distribute services over many systems. We want to allow administrators flexibility to assign services to different hosts to optimize locality (especially in multi-branch deployments) and manage load. If our implementations of REST APIs are a separate service, then that service may need to be instantiated and configured differently on multiple systems within a single deployment to work correctly. Rather than simplifying administration, we've complicated it. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
