Hi Peter,
Totally agreed with your point - if the bundle is self-contained - i.e.
the implementation does not depend on importing packages from other
bundles.
This is a good example where prudence comes in on this issue. You are
advocating the point that a good architect should really consider who is
the client of the bundle and what they would expect which I agree with.
I think the problem comes in when we get into complex applications with
tiers where one tier depends on packages exported from another tier, in
this case it is useful to carve out boundaries which limit the spread of
import requirements.
This really becomes important when you work with distributed
applications (as we do in newton) or equally (taking from Mirkos
response) a dynamic or constrained environment. Here you want to load
the smallest set of bundles to achieve the job in the JVM at any given
moment.
Consider if you have a distributed application implemented in OSGi here
the client and server code share an API packaged in some bundle. But the
client does not want or indeed need to load the entire server
implementation graph just to use the API.
I think the real art in bundle packaging is in limiting the bundle graph
to those bundles that the client can reasonably expect to have to import.
In general in a complex application an implementation is likely to
depend on more packages than it's api. So if you consider making your
application distributed or want it to run in a constrained environment
it seems prudent to extract the api such that client code can use it
without having to resolve the implementation classes.
To complete the picture and bring it back to the original question, I'd
always /tend/ to separate api, spi and impl into three separate bundles.
I'd try to make api depend on as little as possible. I'd make spi depend
on api and again on as little else as possible. I'd make impl depend on
api and spi.
If after doing this impl depended only on api and spi I'd probably
consider whether impl was ever likely to get more complicated. If it
wasn't then I'd probably collapse back to one bundle. Of course this
could always be done prior to building /any/ bundles if you are good at
modelling in you head or on paper etc.
Good conversation :)
Regards,
Dave.
Peter Kriens wrote:
Hmm. I like implementations that carry their interfaces. OSGi can handle
multiple implementations that carry the same API code. Refreshing might
then sometimes restart a bundle that could have been prevented but I fail
to see that as a big drawback.
I think it is crucial that bundles run out of the box and not require
you to chase other bundles to get it to work. This first level
experience is
quite important. Just doubling the number of bundles because you might have
to stop a bundle does not like the right trade off to me.
In the OSGi build, all the implementations care the interfaces they
implement
so they always run out of the box so setup is simplified.
I.e., the org.osgi.impl.service.log .jar bundle carries the packages
org.osgi.impl.service.log + org.osgi.service.log. Obviously, bnd makes
it quite simple to construct these type of bundles.
Kind regards,
Peter Kriens
On 2 jun 2008, at 18:11, Jeff McAffer wrote:
Leaping on this thread as it's something I've had a lot of experience
unpicking and wouldn't want others to have same pain.
Another issue that is worth considering (and yet another reason to
separate into api and impl) is that due to osgi resolution requirements
if you put your impl in the same bundle as the api this effectively
requires client code to resolve bundles that your impl uses but they
may
have no need of using.
This can rapidly get out of control and in the worst case a client
needs
to import a much larger set of bundles to use a client api than would
otherwise be needed.
Yes, this is definitely a concern. Just to paint the flip side of the
spectrum, if you put the API in a separate bundle then either you have
a lot
of small bundles (high overhead ratio in management and runtime foot
print)
or you lump together unrelated API and have a similar problem to what you
describe.
I'm not countering but rather suggesting that there is not a single, one
size fits all answer.
Jeff
_______________________________________________
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
_______________________________________________________________________
This email has been scanned by both Message Labs and Paremus internal
systems for viruses and inappropriate attachments. Email suspected of
carrying a virus payload or inappropriate attachment will not be
delivered to you, and the sender will receive an appropriate warning
notice.
_______________________________________________________________________
_______________________________________________________________________
Paremus Limited. Registered in England
No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or entity to
which it is addressed and may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other than the
intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from any computer.
_______________________________________________________________________
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
