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 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
