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
