Scenarios

The scamPortfolio application and/or another application built on the SCAM framework, denoted Application can be built with respect to exisiting Applications. This section identifies different deployment scenarios and what impact theese has on the Application setup.

Single application

There is only one Application deployed.

This is a trivial scenario since it does not interact with any another installation. No special consideration has to be taken in acount.

Multiple applications, each with separate repository

Each Application has a unique repository, ie metadata is not shared between the Applications. This requires a dedicated datasource and dedicated EJB's, ie requires unique datasource JNDI-names and unique EJB JNDI-name prefix. Each web-application must also define a unique context value.

Multiple applications, sharing a repository

The Applications shares a repository, ie metadata is shared between the Applications. One of the Applications is deployed with a repository, defining the datasource JNDI-name and a EJB JNDI-name prefix. Other Applications are deployed, without repository (skip.repository), using the same JNDI-name prefix as previuos Application. Each web-application must also define a unique context value.

Remote client application

This type of applications accesss a remote, or locally, SCAM Repository and requires only the SCAM Repository API. No special setup consideration is needed to build the API.

SCAM Drutten provides utility methods when working with RDF modelling. The distribution of SCAM Drutten is deliverd in two flawors; ${lib}/scamDrutten.jar includes the Jena implementation and all dependencies needed to work on a JBoss server, ${lib}/client/scamDruttenLite.jar only includes the Jena implementation (all dependencies needs to be provided elsewhere).

SCAM Repository server

A "pure" server installation requires that SCAM Repository dependencies are available in the classpath, ie in some library directory. If needed provide a JNDI-name prefix.