On Tue, Feb 11, 2014 at 9:07 PM, Afkham Azeez <[email protected]> wrote:
> > > > On Mon, Feb 10, 2014 at 3:25 PM, Sameera Jayasoma <[email protected]>wrote: > >> There were some on going discussions on the subject in the recent past. >> Thats why I wanted to bring up this discussion. We were talking about the >> correct number of bundles, correct size of a bundle, etc. I heard a >> decision to make Carbon kernel a single bundle as well. Before coming to a >> conclusion on this subject, let me explain the proper criteria on scoping >> bundles. I've gathered following information from various sources. >> >> >> - *A properly designed bundle should be highly cohesive and loosely >> coupled.* Bundles should perform few related tasks. i.e tightly >> focused in what it does. Bundles should not have a tight coupling to its >> dependencies. i.e coupled to an API not to an implementation. >> >> >> - By looking at export and import packages of a given bundle, we can >> see whether the bundle is properly designed or poorly designed. >> >> >> - If a bundle has too much import package and export packages, then >> most probably this bundle is trying to too much in too many different >> areas(Incohesive). >> >> >> - If a bundle is importing many low-level APIs or implementations >> then this bundle is tightly coupled with other bundles. This theory >> applies >> to export packages as well. If a bundle exports too much packages >> including >> its low-level APIs and implementations, then this bundle is asking for >> trouble. Other bundles will get coupled to this bundle. >> >> >> - Poorly designed bundles can contains too many imports or too many >> exports which results in a nightmare situation if you are trying update >> the >> bundle at runtime. Since there are too many wirings to this bundle, an >> update of this bundle will result in an update of many other dependent >> bundles which in turn may results in a situation similar to a server >> restart. >> >> By considering the above facts I would say that the decisions on the >> number of bundles or the size of a bundle in a project actually depends on >> the context. There is no right answer. Its up to developer of the project >> to decide on the number of bundles and the size of bundles by adhering to >> the rules of high cohesive and loose coupling. >> >> IMHO, the idea of making Carbon kernel a single bundle is not a good >> decision. I think we should take above facts as a guide when scoping our >> Carbon bundles. >> > > Well there is the theory and then there is practice. > All the points that I've mentioned are best practices that people have learned over a period of time. > 1. Would we need to independently release kernel bundles? > Nope. We don't need to independently release kernel bundles. > 2. Would we need to independently patch kernel bundles? > Yes. We need to patch kernel bundles independently. We've been doing this with C4 and all the previous releases of Carbon. If we are aiming to patch kernel or any product without restarting the JVM, then we need to reduce coupling between bundles as much as possible. 3. What is the overhead of having too many bundles in the system? (we can > see practical examples from our current distributions) > There are properly defined guidelines for scoping bundles. We should be able to come up with the optimal set of bundles. Anyway what are the problems of having too many bundles in a system? > > Many major software projects release their binaries as one or a very few > jars. This makes it very effective to manage the jars, as well as improves > build times/improves developer productivity. Simply making decisions on > such theoretical points is not good. > In non-OSGi world having few binaries make sense. Because at runtime all the jars files will get merged to a single flat class path. I.e All the jar files becomes a single jar in non-OSGi applications. But in OSGi, the modularization that you see in the physical space will get reflected in the runtime. I.e. Bundles will have their own class spaces sharing resources among each other based on pre-defined rules. Thats why we need to carefully design our bundles to minimizes coupling among bundles. I agree that in our current products there are too many bundles. But going to the other extreme by merging them all to a single bundle is not the solution IMHO. We need to strike a balance between these two extreme. What I am suggesting it to use the guidelines that I've mentioned in my first email to properly design our bundles. Thanks, Sameera. > > Database denormalization comes to my mind as a good example. Theory says > that RDBMSs should be normalized, and ideally should not have redundant > data. But in organizations I have worked in the past, I have seen > situations where the teams got carried away with the theory, and normalized > the DBs too much, which led to performance problems. Then the teams had to > denormalize <http://en.wikipedia.org/wiki/Denormalization> such DBs. > > IMO, with bundles, we got carried away too much, and have way too many > bundles we can't manage. Even the kernel has more than 30 bundles IIRC! So > I believe merging the bundles, and coming up with a minimal set is the way > to go. The kernel can definitely be reduced to one or two bundles IMO. > > >> >> Thanks, >> Sameera. >> >> >> >> >> >> >> >> >> -- >> Sameera Jayasoma, >> Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://sameera.adahas.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > > *Lean . Enterprise . Middleware* > -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
