I'm in agreement with Marcel. In my experience of teaching OSGi and SAT, those folks who are unfamiliar with the issues surrounding dynamic services, and the capabilities of ServiceListeners and the ServiceTracker, often find it hard to appreciate the benefits that higher level abstractions, such as SAT, dependency manager, and DS have to offer. I also appreciate the "less is more" way of thinking with regards to libraries, so it is particularly important for new OSGi developers to understand the problems that dynamic services introduce.
I have also met people that claim that "dynamic services" just won't work and that restarting the framework and/or VM is the only answer when re-provisioning the framework. Dynamic service are certainly not "for free", but they are possible, and I've seen them work well in applications that consist of 100-200 bundles. While their concerns are valid, they are typically speaking from a point of view of building dynamic services "by hand" and have felt the pain. This sounds like a great opportunity for you to review the available approaches to dynamic services and present your finding! Good luck, Simon Marcel Offermans <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/21/2007 10:46 AM Please respond to OSGi Developer Mail List <[email protected]> To OSGi Developer Mail List <[email protected]> cc Subject Re: [osgi-dev] SAT recommendation Hello Aggelos, Basically, I agree with what Niclas and Simon already said. On Apr 21, 2007, at 3:15 , Aggelos Mpimpoudis wrote: > Continuing my exploration of OSGi, I found that > ServiceActivatorToolkit developed by BandXi would make my life > easier with the service registry and all the matters that come to > you, when you hear about a bundle that is importing services. > /*SAT, for those who never heard of it, is a part of OHF project > (dont know if it started as part of this project) (look it up, at > eclipse.org)*/ > Would you encourage a new OSGi developer, to try SAT from his first > steps? From a teaching point of view, I would first make sure developers understand the dynamic nature of the service registry. Next step would then be to introduce them to the service listener, followed by the service tracker. Make them use those for a little while, giving them some excercises. They will discover for themselves that these become harder to use once the number of service dependencies increases. Once they fully understand the problem, you can present them with solutions (of which there are many): - service binder; - declarative services (R4 spec); - dependency manager; - iPOJO; - SAT. > Is it safe to dump the servicetracker and switch to SAT method at > this early steps or would you suggest to keep on with the first? > Thank you very much in advance! Just like Simon is a bit biased towards SAT probably, I'm more biased towards the dependency manager (I wrote). The latter has been used in several commercial projects already, where we have seen gains in developer productivity because they did not need to worry about "getting the dependencies right" (of course, they still need to be very aware of the dynamic environment, you can't and should not try to hide that). Greetings, Marcel _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
