1

I think I'm on the right track using OSGi services + DS together, however, I really feel like abusing it. Either that, or it's just pure awesome. (Both is still possible).

So let's imagine the following application: it's a house database. I have two interfaces, House and Window. Let's say I have at least one implementation for each available, configured as a ...well, as a component which requires a configuration to instantiate, and in order to create new instances I just supply this configuration to the right pid. (It's not a factory component, nor a service factory either - what's the official name? Here's an excellent post about it by Neil).

So far so good, this works like a charm.

Houses are just that, houses. Have their own address, each one is different, easy to identify by their street property. However, windows instances are sharable between houses; their configuration is basically width and height.

Now, these component can also bind to each other in a 0..n cardinality configuration (even if you wouldn't want to live in a house with no windows). So each house has a list of windows, and for each window type, we know which house has it (a Many-to-Many relationship).

My problem is, let's say two houses share the same three windows. How can I describe this? I feel like property based filtering is not expressive enough. I also feel like maybe this is not the right way to get the framework to instantiate my objects, but it's just so handy.

Thoughts? Am I abusing, or using it as intended?

(I could also use DS to just get the half of the job done: bind either a list of Houses to a Window instance references by it, or vica versa, and then the component instance could call a registerWhatever() function on the target instances - but then I still need to describe at least this half somehow.)

Zoltán
  • 121
  • 10

1 Answers1

2

It's difficult to work out what you're asking here, possibly because the House/Window abstraction doesn't work. Clearly that isn't what you're really doing... are you just trying to obscure or simplify the real model? I understand there are valid reasons for that, but House/Window sound more like domain classes than services or components. If you're really creating a service per row of the database then I think you're abusing the concept of a service.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • I'm trying to simplify the real model here, but this is pretty close to what I'm actually trying to do. You're right that it's kinda like mixing domain objects with services, and possible I could be abusing it. So let's say you'd like to create the above house application using OSGi - how would you build up that architecture? – Zoltán Mar 12 '12 at 13:11
  • @Zoltan: Again it's difficult to say without knowing more about the requirements. If it's a simple CRUD app then you might have some kind of HousePersister component that loads/saves house domain objects from a DataSource service. – Neil Bartlett Mar 12 '12 at 22:34