Hi JB, please tell me more - I'm targeting local dynamic services in a single framework. What overhead would DOSGi bring to the game?
cheers --thomas On Sep 10, 2013, at 1:57 PM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Thomas, > > what's the core differences with DOSGi ? > > I know Fabric, and I work on Karaf Cellar (which also provide DOSGi). It > sounds like a good addition, and it sounds more or less related to DOSGi. > > Regards > JB > > On 09/10/2013 01:50 PM, Thomas Diesler wrote: >> 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] >> <mailto:[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_ <http://www.osgi.org/>_ >>> [email protected]_ <mailto:[email protected]> >>> >>> office: +1 386 848 1781 >>> mobile: +1 386 848 3788 >>> >>> >>> >>> >>> >>> From: Thomas Diesler <[email protected] >>> <mailto:[email protected]>> >>> To: OSGi Developer Mail List <[email protected] >>> <mailto:[email protected]>> >>> Date: 2013/09/10 07:01 >>> Subject: [osgi-dev] Fabric Service Model - Request for feedback >>> Sent by: [email protected] >>> <mailto:[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] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[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 >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > _______________________________________________ > 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
