Hi all,
I am on vacation this week so just a short replay to this very
interesting discussion.
## RESTful API
To make the RESTful API Multi Tenancy one needs to teach a new trick
that allows to publish OSGI services such as Enhancement Chains,
Referenced Sites ... on different RESTful Endpoints. This could be
different HTTP services (e.g. different ports, HTTPs ...) or just
different root paths.
Configurations of services that are bound to the RESTful API (e.g.
EnhancementChains) could than provide additional metadata that tell
the RESTful service implementation on what RESTful Endpoints it should
be published.
Such a design would allow to use a single DBPedia instance for all
clients while client specific configurations would be only published
on the client specific RESTful Endpoint.
## Configuration
Adding those features would make the Stanbol configuration even more
complex, so we would definitely look into a way to make this easy to
configure. With the Linked Media Framework / Stanbol integration we
used the HTTP endpoint of the Felix Web Console to directly create
EnhancementEngine and EnhancementChain instances. This allowed to have
the configuration UI for Stanbol to be integrated within the LMF.
A similar approach could be also used for providing a Configuration
Interface for Apache Stanbol. However for those we would need to
decide if we want to base it on
* Configuration Admin Service
* Sling Installer [1]
So one possibility would be that each client gets its own
configuration interface. All configuration changes would also apply
the metadata needed to bind its configurations to his RESTful
endpoint. Global and multi client configurations/services would be
only possible via a admin-level configuration (e.g. direct access to
the Felix Webconsole, or by copying configurations to the directory of
the Sling File Installer).
## Components
I am sure that there are also Multi Tenancy related issues in the
design and implementation of specific components. E.g. some
assumptions of the Entityhub are not optimal for such an environment.
But AFAIK there are no blocking one
##Storage
The Stanbol Entityhub uses usually embedded Apache SolrCores for
storage. This is done by the ManagedSolrServer component. Multiple
ManagedSolrServer are supported. If you do not want to use the default
ManagedSolrServer instance you will need to explicitly specify the
server name in the configuration ( {server-name}:{core-name}). In
addition it is also possible to use ReferencedSolrServer - an external
manages SolrServer that does not run in the same JVM as Apache
Stanbol.
For Triple related storage Apache Clerezza is used. The default
Stanbol Launcher includes Apache Jena. So yes you will end-up storing
your RDF data in a Apache Jena TDB store. However this can be changed
by using different bundles in the Stanbol Launchers. There are other
peoples on this mailing list that know much more than I do about how
to change/control the Storage used by Apache Clerezza.
## Transactions
AFAIK there is no need/use for transactions in Apache Stanbol. However
there is a RESTful API for asynchronous Jobs - currently only used for
Reasoning. As this is a RESTful service this could hopefully be solved
as suggested for the RESTful API.
best
Rupert
[1] http://sling.apache.org/site/osgi-installer.html
The addition of Multi Tenancy could be a good
With the recent LMF version we have implemented
On Thu, Jul 19, 2012 at 1:56 PM, Fabian Christ
<[email protected]> wrote:
> Hi,
>
> 2012/7/19 Adrian Gschwend <[email protected]>:
>> What would be the way to go for extending the current
>> components to introduce our requirements? Should we fork it first or do
>> you prefer other ways of working on it?
>
> All discussions regarding fundamental code changes should happen on
> this dev list. At Apache we follow the credo that if something was not
> discussed on the list, then it did not happen ;) So start the
> discussion threads that you need on this list.
>
> Then you should open separated JIRA issues for the things discussed on
> the list. Having a JIRA issue, you are able to attach patch files with
> your code changes to that issue. Do not send the patches to this list
> as large attachments are not supported. A committer will take that
> patch and apply it after a review to the code base. This is a rather
> time consuming process. So after several patches and when the
> community believes that you contribute good patches, you may be
> invited to become a committer. That is not so hard as it may sound.
> This is just a small barrier to see if people are really interested in
> contributing to the project. Committer are always individual persons
> and never organisations or a group of people.
>
> Best,
> - Fabian
>
> --
> Fabian
> http://twitter.com/fctwitt
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
