Hi, 2012/7/19 Adrian Gschwend <[email protected]>: > Hi group, > > As Stephan mentioned in a previous post we will most probably use > Stanbol as a platform base for our FP7 project "FusePool". Check out > http://www.fusepool.eu/ for more information (BTW we are looking for one > full time employee as well, see the job offering on the page :)
Nice to hear ;) > Right now we have a closer look at Stanbol to make sure we can do what > we want in the end, currently we have the following questions/remarks: > > Multi Tenancy: > As Stephane mentioned we need to be able to support multiple clients on > the same platform. Wikipedia has a pretty good explanation: > > "With a multitenant architecture, a software application is designed to > virtually partition its data and configuration, and each client > organization works with a customized virtual application instance." > > https://en.wikipedia.org/wiki/Multitenancy > > The alternative is a multi-instance architecture which makes it much > harder to "blend" between two partitions, which is in our case a very > likely scenario. Stanbol in its current stage is not multitenant. It is much more like a multi-instance architecture. Stanbol components are loosely coupled which means that there is no coherent architecture that connects them. At the moment Stanbol components just offer services but do not interact much, if at all, with each other. Maybe you should have a look at the components that you may need for your project and then we have to think about ways to make them multitenant. The service architecture is nice for cloud scenarios but for the multitenant aspect we have to think about the used storage solutions of different components. As I said - at the moment each component solves this on its own. For example, we do not have a central storage service or layer. > We definitely need this for FusePool so we would appreciate if we could > work together on this point to make Stanbol more valuable for cloud > based environments and large scale applications. If I get Rupert > correctly this could already be done for some components but probably > not for all. This is an open-source project and if you would like to become part of the community, everything is possible for Stanbol. Making Stanbol ready for cloud-based scenarios is definitely something that many people would be interested in. > So our proposal is to have something like a Tenancy module which: > - lets us define partitions > - allows us to enable/disable components in the partitions > - allows us to have individual configurations per component in the > partition (like individual chains in the enhancer or individual rules) > - will take care that the components store the data in their own partition > - ultimately we need to be able to plug some form of ACLs on top of that > but I don't think this part will be the show stopper once the rest is > working Sounds like a plan, but is not supported that way by Stanbol, yet. > Transaction Management: > - is there currently some form of transaction management in Stanbol? > Could not find much documentation about this. Not that I know. > Application Server: > - We will most probably want to run Stanbol in JBoss, this is more a FYI > right now. Did anyone do that already? Should we expect problems? :-D We have a WAR packaging for Stanbol that is in use by some people. > Jena Endpoint: > - It seems that Jena provides TDB or SDB for persistent storage. Anyone > knows if there are any SDB adaptors for Infinispan in the works? > Probably a question I should rather ask on the Jena list but I give it a > try :) Maybe Rupert knows about this? > So far, would be nice if we could start a discussion on our remarks. Discussion started ;) For the ongoing discussion, we should always keep in mind that Stanbol is not one single system. It is a composition of components and the user can select which components she would like to use. As a consequence of this, there is not much of an overall architecture in Stanbol. Each top level component, like Enhancer, Entityhub, Contenthub, etc. offers a RESTful API. That's what all have in common. So for your questions we have to look at each component separately. Best, - Fabian
