Re: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz)
Hi Hervé, thank you for your comprehensive response. My conclusion concerning service dynamic is to deal with it in two different ways: 1. Case: The service represents a feature of an application and is on the top level of my layered architecture. If I stop the service, I want my GUI to disable the feature so that Users are aware that the service is not available. I want my application to handle service dynamic as “switch on / switch of” off features. 2. Case: The service represents a lower architectural layer (e.g. persistence layer as part of a feature). If this service is stopped without stopping the layers above an unsuccessful call is treated as a runtime failure (e.g. database not reachable). So as Chris an Peter said, in any of these cases I expect that a service call can fail and the software has to deal with it. Additionally I want my application to react actively on disabling certain features. To achieve this I try to group all bundles belonging to a feature in a subsystem. Best Regards, Andreas Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von hervé vivien Gesendet: Dienstag, 24. März 2015 16:00 An: osgi-dev@mail.osgi.org Betreff: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz) Sent: Sunday, March 15, 2015 at 5:00 PM From: osgi-dev-requ...@mail.osgi.org mailto:osgi-dev-requ...@mail.osgi.org To: osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org Subject: osgi-dev Digest, Vol 101, Issue 24 Send osgi-dev mailing list submissions to osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body 'help' to osgi-dev-requ...@mail.osgi.org mailto:osgi-dev-requ...@mail.osgi.org You can reach the person managing the list at osgi-dev-ow...@mail.osgi.org mailto:osgi-dev-ow...@mail.osgi.org When replying, please edit your Subject line so it is more specific than Re: Contents of osgi-dev digest... Today's Topics: 1. persistence, lazy loading and service dynamic (Andreas Klotz) -- Message: 1 Date: Sat, 14 Mar 2015 17:41:33 +0100 From: Andreas Klotz andreas.kl...@n-design.de mailto:andreas.kl...@n-design.de To: osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org Subject: [osgi-dev] persistence, lazy loading and service dynamic Message-ID: zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info mailto:zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info Content-Type: text/plain; charset=utf-8 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
Re: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz)
Hi Ray, I guess you are right! I used Blueprint in our last software projects because I prefer constructor injection and I was attracted by the convenience of its dynamic proxies. This overshadowed the beauty of DS J. But obviously DS enables more control over service dynamic. Thanks for your advice. Best regards, Andreas -Ursprüngliche Nachricht- Von: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Gesendet: Mi 25.03.2015 15:44 Betreff: Re: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz) Anlage: inline.txt An: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org ; Would you really need a subsystem though? For instance, if you have a service graph based on DS where the outermost component is reachable to the user, and the lowest level is something that could go away, with properly defined relationships (i.e. the most basic being all static references) the outer most would technically go away before the lowest level actually does. This is the beautiful nature of DS. It's not like you're tearing away layers from the inside... it's kind of like peeling an onion! Am I mistaken? - Ray On Wed, Mar 25, 2015 at 9:58 AM, Andreas Klotz andreas.kl...@n-design.de mailto:andreas.kl...@n-design.de wrote: Hi Hervé, thank you for your comprehensive response. My conclusion concerning service dynamic is to deal with it in two different ways: 1. Case: The service represents a feature of an application and is on the top level of my layered architecture. If I stop the service, I want my GUI to disable the feature so that Users are aware that the service is not available. I want my application to handle service dynamic as “switch on / switch of” off features. 2. Case: The service represents a lower architectural layer (e.g. persistence layer as part of a feature). If this service is stopped without stopping the layers above an unsuccessful call is treated as a runtime failure (e.g. database not reachable). So as Chris an Peter said, in any of these cases I expect that a service call can fail and the software has to deal with it. Additionally I want my application to react actively on disabling certain features. To achieve this I try to group all bundles belonging to a feature in a subsystem. Best Regards, Andreas Von: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org ] Im Auftrag von hervé vivien Gesendet: Dienstag, 24. März 2015 16:00 An: osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org Betreff: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz) Sent: Sunday, March 15, 2015 at 5:00 PM From: osgi-dev-requ...@mail.osgi.org mailto:osgi-dev-requ...@mail.osgi.org To: osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org Subject: osgi-dev Digest, Vol 101, Issue 24 Send osgi-dev mailing list submissions to osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body 'help' to osgi-dev-requ...@mail.osgi.org mailto:osgi-dev-requ...@mail.osgi.org You can reach the person managing the list at osgi-dev-ow...@mail.osgi.org mailto:osgi-dev-ow...@mail.osgi.org When replying, please edit your Subject line so it is more specific than Re: Contents of osgi-dev digest... Today's Topics: 1. persistence, lazy loading and service dynamic (Andreas Klotz) -- Message: 1 Date: Sat, 14 Mar 2015 17:41:33 +0100 From: Andreas Klotz andreas.kl...@n-design.de mailto:andreas.kl...@n-design.de To: osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org Subject: [osgi-dev] persistence, lazy loading and service dynamic Message-ID: zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info mailto:zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info Content-Type: text/plain; charset=utf-8 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
[osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz)
Sent:Sunday, March 15, 2015 at 5:00 PM From:osgi-dev-requ...@mail.osgi.org To:osgi-dev@mail.osgi.org Subject:osgi-dev Digest, Vol 101, Issue 24 Send osgi-dev mailing list submissions to osgi-dev@mail.osgi.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body help to osgi-dev-requ...@mail.osgi.org You can reach the person managing the list at osgi-dev-ow...@mail.osgi.org When replying, please edit your Subject line so it is more specific than Re: Contents of osgi-dev digest... Todays Topics: 1. persistence, lazy loading and service dynamic (Andreas Klotz) -- Message: 1 Date: Sat, 14 Mar 2015 17:41:33 +0100 From: Andreas Klotz andreas.kl...@n-design.de To: osgi-dev@mail.osgi.org osgi-dev@mail.osgi.org Subject: [osgi-dev] persistence, lazy loading and service dynamic Message-ID: zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info Content-Type: text/plain; charset=utf-8 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 cant 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 -- next part -- An HTML attachment was scrubbed... URL: http://mail.osgi.org/pipermail/osgi-dev/attachments/20150314/a7b2eca1/attachment-0001.html -- ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev End of osgi-dev Digest, Vol 101, Issue 24 * Hi dear Andreas, sorry for responding to you so late on this topic persistence, lazy loading and service dynamic. hint: please do enumerate your problems or your questions, so as to simplify,clarify them to us readers. Lets Try to summarize your requests if possible, to relevantly meet your needs. 1- I want the dynamic of a service to be bound to another higher level service 2- provides data in contrast to provide objects on which an operation can be performed 3- I cant deliver just data by a service. I think of lazy loading when dealing with persistence. 3.1-So the DAO-Service delivered an object that tries to perform an operation on its delivering service 4- What options do I have to safely load the entities? 5- This will not work if I have different
Re: [osgi-dev] persistence, lazy loading and service dynamic
Hi Chris,
you have understood my case correctly. Thank you for your clarifying
explanations!
Although there might be a small risk for the timing problem, I think
subsystems could help. At least a subystem expresses clearly what belongs
together and avoids unintentionally stopping of modules that belong to the
subsystem.
So I think I give it a try.
Thank you and all others for your contributions.
Best regards, Andreas
-Ursprüngliche Nachricht-
Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im
Auftrag von chris.g...@kiffer.be
Gesendet: Samstag, 21. März 2015 10:26
An: OSGi Developer Mail List
Betreff: Re: [osgi-dev] persistence, lazy loading and service dynamic
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
Re: [osgi-dev] persistence, lazy loading and service dynamic
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
Re: [osgi-dev] persistence, lazy loading and service dynamic
Hi David, I agree that DS allows good control over service dependencies. Although I prefer Blueprint. Anyway I think there remains a small gap. Supposed I pass the entity object to another bundle e.g. a GUI-Implementation. While the GUI does some rendering of the entity the DaoService and DomainService might dissapear and the GUI tries to load the not yet loaded proptery of the entity. Maybe my example is to complicated. In fact my problem is more general: Anytime I get a reference to a service from a ServiceReference the service might be unregistered before I call a method on it. Although then I still have of course a valid reference to something in the memory the service might be in an invalid state. So I think with some unlucky timing there allways remains a small risk of failure when calling a service due to service dynamic. My question is, if it is possible to avoid this small risk? Or is there something I have missed Best regards, Andreas -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
Re: [osgi-dev] persistence, lazy loading and service dynamic
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
Re: [osgi-dev] persistence, lazy loading and service dynamic
If you don’t want to deal with the dynamics of services at all, I would recommend using something like PojoSR, which provides an environment where services cannot disappear (once your application has started). But in general, I would also recommend taking the extra effort to deal with possible failure of services you call. Most of the time this will help you evolve your code better over time. Greetings, Marcel On 19 Mar 2015 at 15:41:01, Andreas Klotz (andreas.kl...@n-design.de) wrote: Hi Chris, I agree with your statements! But I think the assumptions about service reliability can differ in various contextes. If a service represents a device like a sensor in an embedded environment the clients of the service must of course deal with its unreliability. But in an enterprise application I think a service is just something that encapsulates business logic (like the definition of a service in the domain driven design community). So the dynamic of the services adds unwanted risk of failure. Unwanted because the clients won't work at all without their required services. So I asked myself if there is a possibility to differentiate between modularity (mainly encapsulation) and dynamic services. I thought subystems could be a solution. Because I would like to have dynamic for features of an application but not for layers. Best regards, Andreas -Ursprüngliche Nachricht- Von: chris.g...@kiffer.be Gesendet: Do 19.03.2015 15:08 Betreff: Re: [osgi-dev] persistence, lazy loading and service dynamic An: OSGi Developer Mail List osgi-dev@mail.osgi.org; 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
Re: [osgi-dev] persistence, lazy loading and service dynamic
Hi Chris, I agree with your statements! But I think the assumptions about service reliability can differ in various contextes. If a service represents a device like a sensor in an embedded environment the clients of the service must of course deal with its unreliability. But in an enterprise application I think a service is just something that encapsulates business logic (like the definition of a service in the domain driven design community). So the dynamic of the services adds unwanted risk of failure. Unwanted because the clients won't work at all without their required services. So I asked myself if there is a possibility to differentiate between modularity (mainly encapsulation) and dynamic services. I thought subystems could be a solution. Because I would like to have dynamic for features of an application but not for layers. Best regards, Andreas -Ursprüngliche Nachricht- Von:chris.g...@kiffer.be Gesendet:Do 19.03.2015 15:08 Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic An:OSGi Developer Mail List osgi-dev@mail.osgi.org; 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
[osgi-dev] persistence, lazy loading and service dynamic
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
