Hi Andreas, > There are modules representing features of an application. These modules > should be dynamic. And there are modules representing an architectural > layer of an feature. This modules should NOT be dynamic. They should share > the dynamic of the feature module.
I'm not 100% sure I understand what you are saying here, but if the second type of module is one whose lifecycle can be interpreted as applying to a whole aggregate of functionality then subsystems could be the way to go. > So I am wondering if this could be achieved with subsystems. So far I have > no experience with subystems and I try to figure out if it is worth using > them for my case. The language of the specification is not very encouraging with respect to the "timing problem". Take this paragraph (from <https://osgi.org/javadoc/r5/enterprise/org/osgi/service/subsystem/Subsystem.html#stop()>): "Implementations should be sensitive to the potential for long running operations and periodically check the current thread for interruption, in which case a SubsystemException with an InterruptedException as the cause should be thrown. If an interruption occurs while waiting, this method should terminate immediately. Once the transition to the STOPPING state has occurred, however, this method must not terminate due to an interruption until the stop process has completed." So the subsystem can spend a long time in the STOPPING state, and the operation to stop it may have already encountered difficulties which it has not yet been able to report. In effect you replace many small areas of uncertainty by one large one - which may be easier to handle, but at the micro level the timing uncertainty is still there. I don't believe this uncertainty *can* be removed by some magic of synchronisation, n-phase commits, or whatever. The most you could hope to achieve would be to prevent an unchecked exception from being thrown by delaying recognition of the underlying problem. If I write SMBusService s = smBusRef.get(); if (s != null) { s.write(addr,val) } else { mumble() } and the wire comes un-soldered somewhere between the get() and the write() then the latter is going to fail. And as this is a rare(*) and unpredictable event an exception is the right way to deal with it. Best regards Chris (*) Not so rare if I did the soldering - but that's why they call me a software engineer. > -----Ursprüngliche Nachricht----- > Von:Peter Kriens <peter.kri...@aqute.biz> > Gesendet:Do 19.03.2015 18:19 > Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic > An:OSGi Developer Mail List <osgi-dev@mail.osgi.org>; > Very nicely said. In the real world shit happens and you need to deal with > it. The worst applications are the ones that pretend shit does not happen, > they are the most fragile. Since shit can always happen (like a power > failure) any application that relies on no-shit happening is bound to fail > one day. So you need to recover from NPE in any complex application, power > outages, network failures, etc. Get over it, and handle them. > > As Chris said, it is part of modularity that you're calling an unknown > party. The authors could throw an NPE as well, a ServiceException is just > one of this unpreventable things. > > That said. The OSGi dynamics are 'slow' dynamics. They are not intended to > be used in the mainline of the application and cycle hundreds of times per > second. I've been programming with this model a long time and never had > the urge to do something special to prevent this small window. You might > see some wrong data on the GUI for a fraction of a second but good code > will handle the subsequent shutdown event and grey out or remove the > culprit. > > Trust me, this is the LEAST of your worries in today's software :-) > > Kind regards, > > Peter Kriens > > > > >> On 19 mrt. 2015, at 15:05, chris.g...@kiffer.be wrote: >> >> Hi Andreas, >> >>> So I think with some unlucky timing there allways remains a small risk >>> of >>> failure when calling a service due to service dynamic. >> >> Yes. >> >>> My question is, if it is possible to avoid this small risk? >> >> No. Or to put it another way: when you invoke a service you are always >> (in >> principle) invoking "unknown" code which may not behave the way you >> expect, so you should program defensively. Be prepared for the service >> to >> fail, and take the time to think what you should do if it does - >> propagate >> the failure? or try to carry on? >> >> To me this is a part of modularity, independent of dynamics - within >> your >> service you should not need to perform many checks, but you should >> check >> the parameters with which you are invoked and if you call another >> service >> you should treat it as fallible. >> >> Chris >> >> >>> -----Ursprüngliche Nachricht----- >>> Von:David Bosschaert <david.bosscha...@gmail.com> >>> Gesendet:Mi 18.03.2015 21:45 >>> Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic >>> An:OSGi Developer Mail List <osgi-dev@mail.osgi.org>; >>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
