Hi Andreas, If I understand your email correctly the following is your concern:
> So it may occur, that a call by the DomainsService on a property of an entity > happens when the DAO-Service is not available anymore. > ... > What options do I have to safely load the entities? AFAICS you really have two options: 1. If the service is gone, the call will fail. Maybe you can gracefully deal with the failure. 2. If the dependent service is gone then make sure the depending code does not run. This is really the approach taken by DS. If you declare a mandatory dependency on your DAO service for the DomainService code then if the DAO service disappears the DomainService will also not exist. In DS mandatory dependencies are the default model. Option 2. above is clearly the most elegant scenario. Does this cover your concern or is there something that I missed? Best regards, David On 14 March 2015 at 16:41, Andreas Klotz <andreas.kl...@n-design.de> wrote: > Hi all, > > > > I have an use case where I want the dynamic of a service to be bound to > another higher level service. Maybe I need Subsystems...? > > > > I think it is a good design of an OSGi-service if it just provides data in > contrast to provide objects on which an operation can be performed that is > using resources of the underlying bundle. Although the second variant would > be possible, I think that handling service/bundle dynamic becomes very > complex or even unmanageable. > > > > However there is a use case where I can't deliver just data by a service. I > think of lazy loading when dealing with persistence. > > I usually define interfaces for the data access layer. So I get a > Bundle-Setting like this: > > > > - Entity-Bundle (contains Entities) > > - DataAccessAPI-Bundle (contains DAO-Interfaces) > > - DataAccessImpl-Bundle (provides Services implementing DAO-Interfaces) > > - DomainService_A-Bundle (contains domain Logic for e.g. a GUI, uses > DAO-Services; would be separated in API and impl of course) > > - DomainService_B-Bundle (contains more domain Logic, uses same DAO-Services > as DomainsService_A) > > > > DomainServices A and B are clients of DAO-Services. A DAO-Service may > provide an entity with some lazy loading properties. The transactions of the > data accesses are defined by the DomainServices. So it may occur, that a > call by the DomainsService on a property of an entity happens when the > DAO-Service is not available anymore. That would lead to an unsuccessful > attempt to load the property lazily (assuming that connections to the > database are managed by the DAO-Bundle and not by a separate e.g. > EntityManager-Service). So the DAO-Service delivered an object that tries to > perform an operation on its delivering service. > > > > What options do I have to safely load the entities? > > - Do not use lazy Loading? I know cases where this would load the whole DB > in to the RAM... > > - Make assumptions about certain properties a client might need and load > them explicitly in the DAO-Layer? This will not work if I have different > clients for one DAO-Service. > > - Is there a possibility to package DomainServices A and B as different > Subsystems with the DAO-Service as a shared capability? Would this have the > effect that the bundle providing the DAO-Service will only be stoppable, if > both DomainServices are stopped? > > > > To be more general: In our OSGi-projects we use micro-services intensely to > loosely couple not only domain logic (vertical) but also the architectural > layers (horizontal). And I often feel that I only want dynamic for the > vertical bundles/services. > > > > I am very interested in your opinion and how you deal with lazy loading or > equivalent cases. > > > > Thanks and best regards, > > Andreas > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
