CODEWITHSUNDEEP
schemapersistenceosgimodularity
Eric T.
Eric T.

Reputation: 65

OSGi and the Modularity of Persistence: The Effect of Relationships

Most questions revolving around the title of this post ask about making Hibernate, or some other access layer, run in an OSGi container. Or they ask about making the data source run in an OSGi container.

My questions concern the effect of OSGi modularity on the structure of the database itself. Specifically:

  1. How do we make the structure of a database itself modular, so that when we load a module--say, Contact Management--the schema is updated to include tables specifically associated with that module?
  2. What is the effect of the foregoing approach on relationships?

I think the second question is the more interesting. Let's say that Contact Management and Project Management are two distinct OSGi modules. Each would have its own set of tables in the schema. But what if, at the database level, we need to form cross-module relationships between two or more tables? Maybe we wish to see a list of projects that a certain contact is, or has been, working on.

Any solution seems to lead down the path of the various modules' having to know too much about each other. We could write into the Project Management specification that that module expects a source of contacts, and then abstract such an expectation through services, interfaces, pub-sub etc. Seems like a lot of work, though, to avoid a hard-wired relationship between the two modules' underlying tables.

What's the point of being modular up top and in the middle if we may necessarily need to break that modularity with relationships between tables down below? Are denormalization and a service bus really a healthy solution?

Any thoughts?

Thank you.

Upvotes: 2

Views: 316

Answers (4)

Balazs Zsoldos
Balazs Zsoldos

Reputation: 6046

After 5 years of JPA, I decided to leave it and after months of investigation I found Querydsl+Liquibase combo the best.

I worked a lot on developing helper OSGi components and a maven-plugin. The functionality of maven-plugin (code generation) can be easily integrated into other build tools as the maven plugin is only a wrapper around a standalone library.

You can find a detailed article about the solution here: http://bzsoldos.wordpress.com/2014/06/18/modularized-persistence/

Upvotes: 1

andbi
andbi

Reputation: 4454

Maybe I misread the question, but in my opinion OSGI modularity has absolutely no impact on database structure. It's a data storage level, it can be modular of course, but for it's very own reasons - performance, data volumes, load, etc and with it's very own solutions - clusters, olap, partitioning and replication.

If you need data integrity between cm and pm, it should be provided by means which were initially designed for such sort of task - RDBMS. If you need software modularity - you select OSGI solution and your modules are communicating on much more higher logical/business level. They can be absolutely unaware of how persistence is provided - plain text file or 100-node Oracle RAC cluster.

Upvotes: 0

Mohammad Salehe
Mohammad Salehe

Reputation: 351

Regarding first question, LiquiBase can be used. You can update and rollback changesets on bundle activation and deactivation.

Regarding second question, I think it is something that should be considered while designing your architecture. There is no help from some tool. If PM module depends on CM module, it is safe for PM module to assume CM tables currently exist and make foreign relations to them, but not in the opposite direction. You should make it clear in your architecture that what modules depends on what modules and prevent dependency cycles.

Upvotes: 1

Daniel Yokomizo
Daniel Yokomizo

Reputation: 178

In this kind of situation it is important to evaluate how independent are these modules/contexts. In DDD terms these two seem to be independent bounded contexts, so a contact in the pm module is a distinct entity (and also another class) than contact in the cm module. If you keep this distinction you then have some denormalization wrt the contact entity (e.g. you copy the id and name of the contact when adding it to a project, later changes to the contact in the cm module will require some pubsub to keep consistency) but each module will be very independent. I would keep the ui as a separate module, depending on both and providing the necessary glue (i.e. passing the ids and required info between them).

Upvotes: 0

Related Questions