Hi all, I have an use case where I want the dynamic of a service to be bound on 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 -- phone: +49 221 222896 - 24 fax: +49 221 222896 - 11 email: andreas.kl...@n-design.de <mailto:andreas.kl...@n-design.de> -------------------------------- n - d e s i g n G m b H www.n-design.de Alpenerstr. 16 D-50825 Köln Amtsgericht Köln HRB 33766 B Geschäftsführer Andy Kohl <http://ea.sendcockpit.net/_s.php?&fid=19878&fpw=d44e1b06d576c366a1b94b9bf8218761> Verpassen Sie zukünftig keine wichtigen Neuigkeiten mehr zum Thema Softwareentwicklung, moderne Technologien und eHealth sowie zu unserem Unternehmen n-design! Der kostenlose vierteljährliche n-design Newsletter informiert Sie! Zum Anmeldeformular <http://ea.sendcockpit.net/_s.php?&fid=19878&fpw=d44e1b06d576c366a1b94b9bf8218761> <http://www.n-design.de/index.php/blog.html> Wie wäre es mit ,,n-design zum Mitmachen"? Besuchen Sie unseren spannenden Blog <http://www.n-design.de/index.php/blog.html> . Wir freuen uns auf Ihre Kommentare! Vernetzen Sie sich noch heute mit uns auf XING <http://www.xing.com/companies/n-designgmbh> !
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
