---
title: "Apache Aries, Blueprint, transactions, and persistence"
chapter: "15"
---

# Apache Aries, Blueprint, transactions, and persistence

Apache Aries provides enterprise OSGi implementations and integration modules.

## Blueprint

Blueprint is a standardized dependency-injection container designed for dynamic
services. XML declares beans, service publications, references, and lifecycle.
An extender discovers `OSGI-INF/blueprint/*.xml`.

```xml
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <reference id="ledger" interface="com.acme.api.Ledger"/>
  <bean id="reconciler" class="com.acme.impl.Reconciler">
    <property name="ledger" ref="ledger"/>
  </bean>
  <service ref="reconciler" interface="com.acme.api.Reconciler"/>
</blueprint>
```

For new annotation-friendly services, DS is usually simpler and more directly
tooled. Blueprint remains important in Karaf, Camel, CXF, and established
enterprise systems.

## Transactions

Aries transaction control coordinates local or XA resource work through OSGi
services. Define transaction boundaries in application services. XA can solve
specific atomicity needs but adds recovery, heuristic, and operational cost.
Outbox/idempotency patterns may be a better distributed boundary.

## JPA and JDBC

OSGi persistence must handle provider, entity, datasource, weaving, class
loading, and lifecycle. Use the current Data Service/JDBC and transaction
contracts where suitable. Test against the exact framework and provider set.

## CDI

OSGi CDI integrates CDI component models with the service registry. Do not mix
DS, Blueprint, and CDI in one module without a clear ownership and lifecycle
model.

## Feynman check

The registry connects services. DS, Blueprint, or CDI decides how objects are
created and connected to that registry. Choose one primary component model per
area.