Hasta la vista Mandantenfähigkeit?

Vorstellung Referent

I Prof. Informatik (Ostfalia, HS Braunschweig/Wolfenbuttel)

I Buchautor (JSF, JPA, Seam, . . . )

I Mitglied EGs JSR 344 (JSF 2.2) und JSR 338 (JPA 2.1)

I Geschaftsfuhrer PMST GmbH

I . . .

,Bernd Muller, 5.11.2013 2/62

Auszug aus JSR 342: Java EE 7

Section 2: Request. . .As a result, Java EE 7 products will be able to more easily operateon private or public clouds and deliver their functionality as aservice with support for features such as multitenancy andelasticity (horizontal scaling). Applications written for Java EE 7will be better able to take advantage of the benefits of a cloudenvironment.. . .Similarly, a single application can be used by multiple tenants withthe same security, isolation, and quality of service guarantees.. . .

,Bernd Muller, 5.11.2013 3/62

Auszug aus JSR 342: Java EE 7 (cont’d)

Section 2: Request. . .This JSR may also establish a set of constraints that applicationsthat wish to take advantage of PaaS-specific features, such asmultitenancy, may have to obey and provide a way for applicationsto identify themselves as designed for cloud environments.. . .In particular, all resource manager-related APIs, such as JPA,JDBC and JMS, will be updated to enable multitenancy.. . .

,Bernd Muller, 5.11.2013 4/62

Auszug aus JSR 338: JPA 2.1

Section 2: Request

I . . .

I Support for multitenancy.

I . . .

,Bernd Muller, 5.11.2013 5/62

Hasta la vista Mandantenfahigkeit?

,Bernd Muller, 5.11.2013 6/62

Hasta la vista Mandantenfahigkeit?

,Bernd Muller, 5.11.2013 6/62

Was bedeutet Mandantenfahigkeit?

— Hier nur die Datensicht —

,Bernd Muller, 5.11.2013 7/62

Motivation

I Cloud-motiviert: XaaS (Iaas, PaaS, SaaS)

I Kontinuum: Isolated Data vs Shared Data

I Technische, kommerzielle und juristische Aspekte

,Bernd Muller, 5.11.2013 8/62

Motivation

,Bernd Muller, 5.11.2013 8/62

Motivation

,Bernd Muller, 5.11.2013 8/62

Die technische Sicht

I Daten eines Mandanten in . . .

Eigene DB EigenesSchema

GemeinsamesSchema

,Bernd Muller, 5.11.2013 9/62

Getrennte Datenbanken

I Einfachster Ansatz, um Daten zu isolierenI Gemeinsamer Anwendungs-Code, aber jeder Mandant hat

eigene DBI Metadaten verbinden Anwendung mit DB des MandantenI Java EE: Deployment-Frage, CDI-Erweiterung, . . .

Mandant0815

Mandant4711

Mandant1234

,Bernd Muller, 5.11.2013 10/62

Gemeinsame Datenbank, verschiedene Schemata

I Mehrere Mandanten in derselben DatenbankI Jeder Mandant eigene Menge von Tabellen in

Schema, getrennt vonanderen Schemata

Mandant0815

Mandant4711

Mandant1234

,Bernd Muller, 5.11.2013 11/62

Gemeinsame Datenbank, gemeinsames Schema

I Selbe Datenbank und selbes Schema, um Daten fur alleMandanten zu halten

I Spalte mit Mandanten-ID (Diskriminator) bindet Datensatzan Mandant

Mandant Produkt Anzahl

1234.....

Mandant Kunde Adresse

1234.....

Mandant Lieferung Datum

3826427

8327423

8832173

2013-07-04

2013-06-23

2013-01-01..... ..... .....

,Bernd Muller, 5.11.2013 12/62

Mandantenfahigkeit mit Hibernate

,Bernd Muller, 5.11.2013 13/62

Mandantenfahigkeit mit Hibernate – Die Alternativen

I Discriminator und Hibernate Filter

I Hibernate Shards

I Separate Schemata mit Multitenancy-APII Informationsquellen:

I http://relation.to/Bloggers/MultitenancyInHibernate

I https://community.jboss.org/wiki/Multi-tenancyDesign mitReferenz auf PDF, das im Folgenden verwendet wird

I Video http://vimeo.com/20296211I Hibernate Repository und Dokumentation

,Bernd Muller, 5.11.2013 14/62

Multi-tenancy in Hibernate | Steve Ebersole

Discriminator Entity@Entity@FilterDef( name=”tenantFilter”, parameters=@ParamDef( name="tenantId", type="string" ) )@Filters( @Filter( name=”tenantFilter”, condition=”tenant_id = :tenantId” ))public class Customer { @Id private Long id; @Column( name=”tenant_id”, nullable=false, updateable=false ) private String tenantId; ...}

@Entity@FilterDef( name=”tenantFilter”, parameters=@ParamDef( name="tenantId", type="string" ) )@Filters( @Filter( name=”tenantFilter”, condition=”tenant_id = :tenantId” ))public class Customer { @Id private Long id; @Column( name=”tenant_id”, nullable=false, updateable=false ) private String tenantId; ...}

Discriminator Usagepublic void demonstrateUsageInDiscriminatorScenario() { // One thing that must be done on all sessions is to enable the tenantbased Hibernate filter // we defined before on the entity. This is usually best handled by some form of “request // interceptor” (HttpServletRequestFilter, etc) to make sure it is done uniformly

// Creating an entity Session session = openSession(); session.enableFilter( “tenantFilter” ).setParameter( “tenantId”, “sometenantidentifier” ); session.beginTransaction(); Customer customer = new Customer(); ... customer.setTenantId( “sometenantidentifier” ); session.persist( customer ); session.getTransaction().commit(); session.close();

// Querying Customers session = openSession(); session.enableFilter( “tenantFilter” ).setParameter( “tenantId”, “sometenantidentifier” ); session.beginTransaction(); Customer customer = (Customer) session.createQuery( “from Customer” ).uniqueResult(); session.getTransaction().commit(); session.close();}

public void demonstrateUsageInDiscriminatorScenario() { // One thing that must be done on all sessions is to enable the tenantbased Hibernate filter // we defined before on the entity. This is usually best handled by some form of “request // interceptor” (HttpServletRequestFilter, etc) to make sure it is done uniformly

// Creating an entity Session session = openSession(); session.enableFilter( “tenantFilter” ).setParameter( “tenantId”, “sometenantidentifier” ); session.beginTransaction(); Customer customer = new Customer(); ... customer.setTenantId( “sometenantidentifier” ); session.persist( customer ); session.getTransaction().commit(); session.close();

// Querying Customers session = openSession(); session.enableFilter( “tenantFilter” ).setParameter( “tenantId”, “sometenantidentifier” ); session.beginTransaction(); Customer customer = (Customer) session.createQuery( “from Customer” ).uniqueResult(); session.getTransaction().commit(); session.close();}

Beispiel: Entity Kunde mit Filterdefinition

@Entity

@FilterDef(name = "kundeMandantFilter",

parameters = @ParamDef(name = "mandant",

type = "string"))

@Filter(name = "kundeMandantFilter",

condition = "mandant = :mandant")

public class Kunde implements Serializable {

@Id @GeneratedValue

private Integer id;

private String mandant;

,Bernd Muller, 5.11.2013 17/62

Verwendung des Filters

session.enableFilter("kundeMandantFilter")

.setParameter("mandant", MANDANT_1 );

Query query = session.createQuery(

"FROM " + Kunde.class.getSimpleName ());

Assert.assertEquals (2,

((List <Kunde >) query.list ()). size ());

session.enableFilter("kundeMandantFilter")

.setParameter("mandant", MANDANT_2 );

Assert.assertEquals (1,

((List <Kunde >) query.list ()). size ());

,Bernd Muller, 5.11.2013 18/62

Fazit Diskriminator und Filter

I Scheint aufwendig (verglichen mit Alternativen)

I Definition aus Handbuch:”A filter criteria allows you to define

a restriction clause similar to the existing where attribute ...“

I Verwendung in Where-Clause, nicht bei Schreibvorgangen

I Ahnlich DB-Views

I Wird von JBoss nicht weiter als Mandantenfahigkeitpropagiert

I Evtl. Missbrauch der Filter-Idee?

,Bernd Muller, 5.11.2013 19/62

Hibernate Shards

I Eigenes Hibernate-Unterprojekt Shards

I Erlaubt”Horizontal Partitioning“ d.h. Verteilung von

Datensatzen auf mehrere Datenbanken

I Siehe http://www.hibernate.org/subprojects/shards.html

I Scheinbar nicht mehr weiterentwickelt

I Kein GA-Release, Beta datiert von 2007

I Also: besser nicht verwenden

,Bernd Muller, 5.11.2013 20/62

Separate Schema ConnectionProviderpublic class MyTenantAwareConnectionProvider implements ConnectionProvider { public static final String BASE_JNDI_NAME = "java:/comp/env/jdbc/";

public Connection getConnection() throws SQLException { final String tenantId = TenantContext.getTenantId() final String tenantDataSourceName = BASE_JNDI_NAME + tenantId; DataSource tenantDataSource = JndiHelper.lookupDataSource( tenantDataSourceName ); return tenantDataSource.getConnection(); }

public void closeConnection(Connection conn) throws SQLException { conn.close(); }

public boolean supportsAggressiveRelease() { // so long as the tenant identifier remains available in TenantContext throughout, we can // reacquire later return true; }

public void configure(Properties props) { // currently nothing to do here }

public close() { // currently nothing to do here }}

public class MyTenantAwareConnectionProvider implements ConnectionProvider { public static final String BASE_JNDI_NAME = "java:/comp/env/jdbc/";

public Connection getConnection() throws SQLException { final String tenantId = TenantContext.getTenantId() final String tenantDataSourceName = BASE_JNDI_NAME + tenantId; DataSource tenantDataSource = JndiHelper.lookupDataSource( tenantDataSourceName ); return tenantDataSource.getConnection(); }

public void closeConnection(Connection conn) throws SQLException { conn.close(); }

public boolean supportsAggressiveRelease() { // so long as the tenant identifier remains available in TenantContext throughout, we can // reacquire later return true; }

public void configure(Properties props) { // currently nothing to do here }

public close() { // currently nothing to do here }}

Separate Schema Usagepublic void demonstrateUsageInSeparateSchemaScenario() { // The ConnectionProvider we saw earlier is registered with the SessionFactory as the means // for Hibernate to acquire Connections as needed for the Session. Here we must push the // tenantid to the TenantContext so it is available to the ConnectionProvider. This is usually // best handled by some form of “request interceptor” (HttpServletRequestFilter, etc) to make // sure it is done uniformly

TenantContext.setTenantId( “sometenantidentifier” );

// Creating an entity Session session = openSession(); session.beginTransaction(); Customer customer = new Customer(); ... session.persist( customer ); session.getTransaction().commit(); session.close();

// Querying Customers session = openSession(); session.beginTransaction(); Customer customer = (Customer) session.createQuery( “from Customer” ).uniqueResult(); session.getTransaction().commit(); session.close();}

public void demonstrateUsageInSeparateSchemaScenario() { // The ConnectionProvider we saw earlier is registered with the SessionFactory as the means // for Hibernate to acquire Connections as needed for the Session. Here we must push the // tenantid to the TenantContext so it is available to the ConnectionProvider. This is usually // best handled by some form of “request interceptor” (HttpServletRequestFilter, etc) to make // sure it is done uniformly

TenantContext.setTenantId( “sometenantidentifier” );

// Creating an entity Session session = openSession(); session.beginTransaction(); Customer customer = new Customer(); ... session.persist( customer ); session.getTransaction().commit(); session.close();

// Querying Customers session = openSession(); session.beginTransaction(); Customer customer = (Customer) session.createQuery( “from Customer” ).uniqueResult(); session.getTransaction().commit(); session.close();}

Support in Hibernate 4● Exact API still under discussion[1]● Public API options:

– Session.setTenantId(String tenantId)

– Passed as part of opening a Session

● Transparently handled by Hibernate

[1] http://opensource.atlassian.com/projects/hibernate/browse/HHH5697

Manual (4.2): 16.3. Multi-tenancy in Hibernate

I Konfiguration mit Property hibernate.multiTenancy

I org.hibernate.MultiTenancyStrategy ist Enum mit

I NONE

(the default) No multi-tenancy is expected. . . .I SCHEMA

Correlates to the separate schema approach. . . . Additionally, a...MultiTenantConnectionProvider must be specified.

I DATABASE

Correlates to the separate database approach. . . . Additionally,a ...MultiTenantConnectionProvider must be specified.

I DISCRIMINATOR

Correlates to the partitioned (discriminator) approach. . . . Thisstrategy is not yet implemented in Hibernate as of 4.0 and 4.1.Its support is planned for 5.0.