The proposal is targeted for a specific project (fuse-fabric) - remote services are not involved in the consideration at the moment. The problem however seems to be general enough that I wanted to present it to this audience. I'm wondering how other folks deal with the issues of service dynamicity and configuration change in the duration of a single call to a complex graph of interconnected services.
cheers --thomas On Sep 10, 2013, at 1:35 PM, BJ Hargrave <[email protected]> wrote: > You still have the issue that services are transient. You cannot "pin" a set > of them for some time duration. A service can represent a remote service, > access to which is subject to failure of the network or remote withdrawal of > the service. > > But I am not totally sure I understood your proposal. > -- > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: Thomas Diesler <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 2013/09/10 07:01 > Subject: [osgi-dev] Fabric Service Model - Request for feedback > Sent by: [email protected] > > > > Hi Folks, > > in Fabric we have a service model whereby services have interdependencies, > are configurable and dynamic by nature - all of which is managed in OSGi with > the help of Declarative Services. To illustrate I use a simple example > > ServiceT { > > @Reference > ServiceA serviceA; > > @Reference > ServiceB serviceB; > > public doStuff() { > // that uses serviceA & serviceB > } > } > > The injection is handled by the DS framework - there are various callbacks > involved. > > Lets assume the system is fully configured and a client makes a call on > ServiceT > > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > > Due to the dynamic nature of OSGi services and their respective configuration > ServiceT must deal with the following possible/likely situations > > #1 An instance of a referenced service is not available at the point of > access (i.e. serviceA is null) > #2 In the context of a single call the service instance may change (i.e. call > may span multiple instances of serviceA) > #3 In the context of a single call the configuration of a service instance > may change (i.e. serviceA is not immutable, sequential operations on A may > access different configurations) > > In OSGi there is no notion of global lock for service/configurations nor a > notion of lock of a given set of services/configurations - I cannot do > > lock(T, A, B); > try { > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > } finally { > unlock(T, A, B); > } > > This code is also flawed because it assumes that the caller of doStuff() is > aware of the transitive set of services involved in the call and that this > set will not change. > > As a conclusion we can say that the behaviour of doStuff() is only defined > when we assume stability in service availability and their respective > configuration, which happens to be true most of the time - nevertheless, > there are no guarantees for defined behaviour. > > How about this … > > The functionality of A and B and its respective configuration is decoupled > from OSGi and its dynamicity > > A { > final Map config; > public doStuffInA() { > } > } > > B { > final Map config; > public doStuffInB() { > } > } > > ServiceA and ServiceB are providers of immutable instances of A and B > respectively. There is a notion of CallContext that provides an idempotent > set of instances involved in the call. > > CallContext { > public T get(Class<T> type); > } > > This guarantees that throughout the duration of a call we always access the > same instance, which itself is immutable. CallContext also takes care of > instance availability and may have appropriate timeouts if a given instance > type cannot be provided. It would still be the responsibility of A/B to > decide wether an operation is permissible on stale configuration. > > Changes to the system would be non-trival and before I do any prototyping I'd > like to hear what you think. > > cheers > --thomas > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
