[OPEN-ILS-DEV] 2 important changes to opensrf_core.xml in OpenSRF trunk (changeset 1253 -- multi-domain mode)

[Bill Erickson]

The following configuration chunk:

<config>
   <opensrf>
     <domains>
       <domain>localhost</domain>
     </domain>
     ...

has been simplified to:

<config>
   <opensrf>
     <domain>localhost</domain>
   ...

(NOTE: The above change is necessary in ~/.srfsh.xml as well!)

Also, the router configuration near the bottom of the file has been 
given a <routers> wrapper element so that additional routers may be 
configured:

<config>
   ...
   <routers>
     <router>
       <!-- router configuration goes here -->
     </router>
   </routers>
</config>


I have updated the OpenSRF and ILS example files.  I've also added an 
additional multi-domain example file.

http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/examples/opensrf_core.xml.example
http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/examples/opensrf_core.xml.example.multidomain

-------------------------------------------------------------------------------

What is all of this?

OpenSRF now has the ability to run in multi-domain mode.  In 
multi-domain mode, different jabber domains handle different OpenSRF 
services.  One router per domain is launched to handle requests to that 
domain.  Certain clients are allowed access to certain domains only. 
With this, we can physically separate an untrusted client from sensitive 
resources.

This crudely drawn diagram might just confuse you more ;)

http://open-ils.org/documentation/opensrf-multi-domain.jpg

In this setup, the client and the open-ils.cstore service are logged in 
to 2 different jabber domains.  Additionally, open-ils.cstore is not 
registered with the router on the clients domain (public.domain).  In a 
nutshell, the client has no way to send requests directly to 
open-ils.cstore.  It's forced to go through a protected service first, 
which will enforce authentication/authorization, before it can access 
sensitive data.

The old approach, as seen in the HTTP gateway, was to define an explicit 
list of services that the gateway could communicate with.  With this 
change, the gateway will not need to manage its own access list, since 
it won't have access to private services anyway.


Doesn't this complicate things?

  -- These features are optional and they only require changes to 
opensrf_core.xml, plus the addition of a host in the Ejabberd config. 
Running with two domains will eventually be the default behavior, but 
the install process will need to be streamlined before we make that step.

Do I need to run 2 jabber servers for multi-domain mode?

  -- Not if you are using Ejabberd.  Ejabberd allows you to host 
multiple domains within a single Ejabberd instance.  Because of this, no 
additional Jabber processes or domain-to-domain network IO is required.

Do I need to manually launch more routers?

  -- No.  The router process will automatically launch as many routers 
as you have configured.




For those of you who have made it this far, I realize it's a lot to 
digest.  I've had my head in the code most of the afternoon and I'm sure 
I'm leaving out some crucial detail that will make all of this clear. 
If anyone has any questions about any of this, fire away...


-bill

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com