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: [EMAIL PROTECTED]
| web: http://esilibrary.com
