2008/12/17 Craig Phillips <[email protected]> > Hi, > > Thinking about "osgi in action" et al... One thing I keep talking up, and > have yet to find the time to actually put a rudimentary demonstration > together, is along the following... [please pardon any mis-spellings and > typos and occasional jumbled sentence fragment(s) if they happen, not to > mention any relative ignorance on my part as I've been slightly away from > OSGi in practice for a couple months] > > Admittedly, computers have to be rebooted, but in theory, IMO, an OSGi > container (and, distributed portions thereof) should be able to run 24x7 for > a complete application (loosely defined) life cycle; I see declarative > services (and, the variants thereof, from iPOJO and Spring-DM et al) as a > key mechanism for accomplishing and managing forward/backward compatibility > and things like OBR (and, shrug, this P2 thing) for deployment management, > especially under "low stress"; > > Furthermore, this rant also has implications to build, as build is not fun > and is not made any more pleasant by the massive infrastructures being put > together by these monstrous tools (for which I am too keenly subjected to on > a daily basis and the state of today's build-state simply sucks big time); > > In my quest, shall we say, I mostly want to take advantage of the > versioning that OSGi provides (although I want the versioning at the service > level, not just the package level -- pardon my ignorance if I'm off a bit) > and to push for serious separation of API from IMPL; > > It seems as if at least a generation of programmers out there simply missed > the boat and all the Grady Booch / "main sequence band" lessons regarding > component circular dependencies... Hey, I had to get BSF/j-ruby/groovy > working within the context of an equinox container and had to resort to > "buddy policy: dependent", not to mention a more than interesting experience > of writing my own custom class loader in order to make all that happen; > > I contend that there should be a non-binding rule that APIs be > non-activated bundles in their own right, fully versioned (at the package > level, since "service" doesn't quite apply to a static interface, loosely > speaking) [noting that an API could be a non-abstract class, BTW]; > > So, APIs and IMPLs are NOT bundled together.. yeah, I can just hear the > "snorts" and "screams" and "chairs falling over" in the distance [nod to > Ozzy LOL]; First of all, build should ONLY use API.jar's; If I modify an > IMPL.jar, the hudson's of the world should not be kicking off a massive job, > except maybe for the sake of an integration test to run; Second, an IMPL can > be deployed without serious breakage to the world of existing OSGi based > apps running on the planet; > > What I want to demonstrate, at run time (because I've ranted enough on how > much I hate what the state of build is today), is along the lines: > * A non-activated and versioned api.jar, let's say is version 1.0.0 > * An impl.jar, as wired to api.jar in such a manner that it is clear that > impl.jar, at whatever version, implements api.jar at version 1.0.0; > * A client.jar which is wired to api.jar for version range 1.0 to 2.0, > where 2.0 is excluded (meaning, anything less than 2.0); > > So, life cycle continues... we find bugs and minor enhancements to > impl.jar, but they don't break / mod the api... Hence, we put out new > deployments of impl.jar, as still implementing api.jar at version 1.0.0, of > varying minor version increments; As we put out the new impl.jar increments, > declarative services is "unbind'ing" and "re-bind'ing" the service to > client.jar; So far, so good... > > Now, we add items to api.jar.... we have no broken the backwards > compatibility to api.jar, so no need to bump the major version number. We > just bump the minor version portion; As such, we create a new version of > impl.jar that supports the mods to the api; And, as above, we can deploy > this new and still backward compatible set of api and impl jars with the > unbind and re-bind to the client.jar (noting that we have to STOP the old > versions of the bundles and should uninstall at a time in which we know > there are no clients out there that are wired specifically (meaning, not > "ranged") to older/legacy bundles; Speaking of said issue... > > If client.jar had been wired specifically to api.jar at version 1.0.0 > (assuming this is even possible at the service level -- if the api is small, > the package level versioning will get the job done, but that's not exactly > what I want / desire), then we would not be able to STOP/uninstall the > older/legacy api.jar/impl.jar set; So, I'm assuming that client.jar can wire > to the mod'd API/IMPL application bundle set, even though it was "built" > using api.jar at version 1.0.0 [this is all run time stuff I'm referring to > above -- hence, client.jar has not be rebuilt]; And, of course, I assume the > mod'd api as implemented by the 1.0.1 version (or there abouts) of impl.jar, > provides a functional backward compatibility capability; > > As for breaking backward compatibility, like in the case of a delete or > rename or maybe a really massive mod to the api, we bumped the major number > of the api.jar to 2.0.0; We can deploy the new 2.0.0 api.jar and 2.0.0 > impl.jar into the existing container and nothing in the older/legacy breaks > -- it continues to function using the older/legacy bundles, for which we did > not STOP/uninstall; Once a new client is deployed that uses api.jar at > level 2.0.0, we can then go and STOP/uninstall the older/legacy client > bundle; > > Using the above, for which I have yet to demonstrate and have no certain > confidence level if this is achievable, at least using OSGi 4.1 (and, > nothing in the OSGi 4.2 spec that I see thus far leads me to alter my > suspicions plus or minus), but theoretically a container would otherwise be > able to run 24x7 for the entire life cycle of an application (as implemented > using OSGi et al as "services"); > > And, back to build -- we don't need this monstrosity infrastructure if we > were to force proper programming practices in which API is fully divorced > from IMPL; Let's face it, impl's change a lot! But API's should be fairly > stable; Hence, hudson's shouldn't be busy running jobs constantly as they > are today; Simply put, if you mod an impl, hudson/CIs should only build the > impl bundle and maybe run an integration test and go back to sleep; In this > day and age, it seems that parent.pom changes on a daily basis, shrug; > Where's the convention? Like standards, just wait a day and a new one > appears; > > And when you started to add distributed services and Newtons and composites > and the like, it just gets more and more important that we have > serious/significant separation of API from IMPL; I tell everyone who will > listen (and considering this lost generation that doesn't know how to spell > "main sequence band", there aren't many out there who do "listen" -- just > override this one method and type mvn -- "pool's open!") -- get used to lots > of little jar files! I think things like Newton have ideas on how to manage > "lots of little jar files", but I haven't looked at that effort in a number > of months... > > For what it's worth... Well, I feel better LOL ... for now... Cheers, > Craig >
yes, separation of API and IMPL has a lot of benefits - but like any technique you have to know when (and how much) to apply it just like programming-to-interfaces, ie. you wouldn't want to end up with thousands of interfaces just for the sake of them and yes, I'd also like to see simpler (but not simplistic!) build tools - it's sad to see how much time can go into fighting the build :( one idea I've had in the past (unfortunately no time to investigate it in detail) is to have a build system based on OSGi that you could throw source bundles at - these would get compiled and the binaries pushed out to other frameworks - you could then have several frameworks each devoted to build, unit testing, integration testing, etc. and have developers continually throwing source bundles at them (of course you'll still need to reboot them occasionally to test combinations in isolation...) perhaps you could then use a rule system to decide how bundles get routed through the network of "build" frameworks? anyway, imho the best thing we can do today is evangelize about these "best practices" so that the next generation of libraries and applications can take advantage of OSGi (or at the very least do no harm!) - such as why you should avoid Class.forName I mean, not everyone has to use OSGi, but there are things you can do to prepare your code that can end up helping everyone _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
