Im ersten Blogpost dieser Reihe habe ich die Fachkomponentenarchitektur vorgestellt und beschrieben, welche Unterprojekte benötigt werden und welche Funktion sie haben. Für die Konfiguration greife ich dabei auf die Java-basierte Konfiguration von Spring 3 zurück.
Eine Fachkomponente benötigt natürlich in aller Regel Zugriff auf Ressourcen, sei es eine Datenbank oder eine Messaging Middleware, und in aller Regel unterscheiden sich diese Ressourcen je nach Umgebung. In diesem Blogpost geht es um die umgebungsabhängige Einbindung dieser Ressourcen.
In den meisten Unternehmen greifen viele Komponenten auf dieselben Ressourcen zu. Bei Datenbanken beispielsweise hat das den Vorteil eines vereinfachten Transaktionsmanagements, wenn nur auf eine DataSource zugegriffen wird. Auch bei Messaging Middleware gibt es meist einen Provider, der die Queues bereitstellt.
Es ist also sinnvoll, wenn ein übergreifendes (Architektur-)Team diese Ressourcen so bereitstellt, dass sie direkt verwendet, aber ebenso leicht erweitert und ausgetauscht werden können. Diese Komponenten sind im Gegensatz zu den Fachkomponenten reine Infrastrukturkomponenten. Ich unterscheide hier Low-Level-Data-Access-Komponenten und High-Level-Data-Access-Komponenten.
Low-Level-Data-Access-Komponenten und Spring’s Bean Definition Profiles
Für die Einfachheit des Beispiels betrachte ich nur den Datenbankzugriff, aber es sollte kein Problem sein, die Konzepte auf andere Ressourcen zu erweitern.
Es wird ein Interface für den Datenzugriff bereitgestellt:
1public interface LowLevelDataAccessConfig {
2
3 public DataSource dataSource() throws Exception;
4
5 public PlatformTransactionManager transactionManager();
6
7}
Das verantwortliche Architekturteam liefert Default-Implementierungen zu diesem Interface wie die folgende:
1@Profile("websphere")
2@Configuration
3public class JndiDataAccessConfig implements LowLevelDataAccessConfig {
4
5 @Bean
6 public DataSource dataSource() throws Exception {
7 InitialContext initialContext = new InitialContext();
8 return (DataSource) initialContext
9 .lookup("java:comp/env/jdbc/datasource");
10 }
11
12 @Bean
13 public PlatformTransactionManager transactionManager() {
14 return new WebSphereUowTransactionManager();
15 }
16
17}
Wenn man sich die Bean-Definitionen ansieht, so wird schnell klar, dass diese Konfiguration für die Verwendung in einem Websphere-Applicationserver erstellt wurde. Das mag in unserem Beispielunternehmen der definierte Standard für die Produktionsumgebung sein.
Interessant ist diese Zeile:
1@Profile("websphere")
Hier kommen die in Spring 3.1 neu eingeführten Bean Definition Profiles ins Spiel, für mehr Informationen dazu siehe diesen Artikel . Durch die Annotation @Profile auf Klassenebene geben wir an, dass die Bean-Definitionen nur dann dem ApplicationContext hinzugefügt werden sollen, wenn das Profil websphere aktiviert ist. Dieses Profil ist ein unternehmensweit definiertes Default-Profil. Eine Aktivierung kann beispielsweise über das Setzen einer JVM-Property mit dem Namen spring.profiles.active erfolgen.
Eine weitere Implementierung, die bereitgestellt wird, ist die folgende:
1@Profile("standalone")
2@Configuration
3public class StandaloneDataAccessConfig implements LowLevelDataAccessConfig {
4
5 @Bean
6 public DataSource dataSource() {
7 BasicDataSource dataSource = new BasicDataSource();
8 dataSource.setUrl("someURL");
9 dataSource.setUsername("username");
10 dataSource.setPassword("password");
11 return dataSource;
12 }
13
14 @Bean
15 public PlatformTransactionManager transactionManager() {
16 return new DataSourceTransactionManager(dataSource());
17 }
18
19}
Diese Konfiguration stellt die Ressourcen auch außerhalb eines Application-Servers zur Verfügung, wenn das Profil standalone aktiviert ist. Anmerkung: URL, Username und Passwort sollten natürlich in eine Properties-Datei ausgelagert werden, das betrachte ich im nächsten Blogpost dieser Reihe.
High-Level-Data-Access-Komponenten
Low-Level-Data-Access-Komponenten wie eine DataSource sollten nicht direkt von Fachkomponenten verwendet werden. Hier kommen die High-Level-Data-Access-Komponenten ins Spiel, die die Low-Level-Data-Access-Komponenten verwenden. Im folgenden Beispiel wird ein JdbcTemplate als High-Level-Komponente definiert, allerdings könnten hier auch andere, selbst geschriebene Komponenten stehen, die spezielle Anforderungen erfüllen.
1@EnableTransactionManagement
2@Import({ JndiDataAccessConfig.class, StandaloneDataAccessConfig.class })
3@Configuration
4public class HighLevelDataAccessConfig {
5
6 @Autowired
7 private LowLevelDataAccessConfig dataConfig;
8
9 @Bean
10 public JdbcTemplate jdbcTemplate() throws Exception {
11 return new JdbcTemplate(dataConfig.dataSource());
12 }
13}
Was passiert hier? Gehen wir die einzelnen Elemente einmal durch.
1@EnableTransactionManagement
@EnableTransactionManagement sorgt dafür, dass @Transactional – Annotationen in Komponenten für das Transaktionsmanagement ausgewertet werden.
1@Import({ JndiDataAccessConfig.class, StandaloneDataAccessConfig.class })
@Import sorgt dafür, dass die beiden angegebenen Konfigurationsklassen importiert werden. Das geschieht allerdings nur, wenn eines der in den Klassen angegebenen Profile aktiviert ist.
1@Autowired 2 private LowLevelDataAccessConfig dataConfig;
Aus dem ApplicationContext wird eine Konfiguration per Autowiring in die Instanzvariable geladen, die das Interface LowLevelDataAccessConfig implementiert. Es muss genau ein solches Konfigurationsobjekt geben, ansonsten kann der ApplicationContext nicht erzeugt werden. In unserem Fall ist es also entweder die JndiDataAccessConfig bei Aktivierung des Profils websphere, die StandaloneDataAccessConfig bei Aktivierung des Profils standalone oder eine beliebige andere Konfiguration, die LowLevelDataAccessConfig implementiert und dem ApplicationContext hinzugefügt wurde.
Verwendung der High-Level-Data-Access-Komponenten in Fachkomponenten
Im ersten Teil der Reihe habe ich eine Partner-Fachkomponente zum Laden von Partnern definiert, den Datenzugriff aber ausgespart. Schauen wir uns die Implementierung dieser Komponente mit Datenzugriff an:
1public class PartnerServiceImpl implements PartnerService {
2
3 private JdbcTemplate jdbcTemplate;
4
5 public PartnerServiceImpl(JdbcTemplate jdbcTemplate) {
6 this.jdbcTemplate = jdbcTemplate;
7 }
8
9 @Override
10 public Partner getPartner(long id) {
11 return this.jdbcTemplate.queryForObject("SELECT ....",
12 new PartnerRowMapper(), id);
13 }
14
15}
Die Konfigurationsklasse sieht dann so aus:
1@Import(HighLevelDataAccessConfig.class)
2@Configuration
3public class PartnerConfig {
4
5 @Autowired
6 private HighLevelDataAccessConfig dataAccessConfig;
7
8 @Bean
9 public PartnerService partnerService() throws Exception {
10 return new PartnerServiceImpl(dataAccessConfig.jdbcTemplate());
11 }
12
13}
Navigation in Konfigurationen
Ohne Probleme können wir uns von der InkassoConfig
in die PartnerConfig und von dort in die HighLevelDataAccessConfig begeben.
In der HighLevelDataAccessConfig können wir nicht mehr direkt weiter navigieren, da es nun einige Auswahlmöglichkeiten gibt.
Diese einfache Art der Navigation durch Konfigurationen ist mit XML nicht möglich.
Fazit
Fachkomponenten benötigen Ressourcen. Die bekommen sie, indem sie allgemein definierte Infrastrukturkomponenten einbinden und benutzen. Einstiegspunkt dazu ist eine high level Konfiguration, die je nach aktiviertem Profil automatisch die passenden low level Ressourcen injiziert bekommt. Für alle Standardfälle sind die low level Ressourcen klar definiert, so dass sie out-of-the-box verwendet werden können. Für Nicht-Standardfälle ist es aber sehr einfach, andere low level Ressourcen einzubinden. Wenn immer der Weg über das Interface LowLevelDataAccessConfig gegangen wird, wird sichergestellt, dass in einem ApplicationContext immer nur eine bestimmte low level Ressourcenkonfiguration enthalten ist.
Im folgenden Blogpost behandle ich das Thema Properties:
Eine Fachkomponentenarchitektur mit Spring 3.0/3.1 – Teil 3: Properties
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.