Hello Martijn, On Oct 11, 2011, at 14:17 , Martijn van Berkum wrote:
> Weaknessed or to be discussed parts in this definition: > I replaced composite with the term component. After looking up the defintion > of composite, it was stated that a composite consists of a distinct set of > components, which is, I guess, the word we were searching for (composite as a > word is flawed as this is the result of combining those 'components', not the > 'lego building blocks' we meant it to be). I'm not in favor of using the term component, because a "component" in our implementation code, which uses the Dependency Manager, refers to "something" that has dependencies on services, configuration or whatever and that might or might not publish an API (either an OSGi service, a REST service, or both). Having two things named "component" sounds too confusing. Approaching this bottom up in code we already have: - inherited from Java: classes and interfaces, which are grouped into packages - inherited from Dependency Manager: components, which are declared and can be introspected, and have dependencies and publish services - inherited from OSGi: bundles, which are our "modules" and most fine-grained way of composing applications - inherited from Apache ACE: we have artifacts (which can be bundles, configuration files or pretty much and type of deployable) which we group into features, and features again are grouped into distributions Granted, all of these are still quite technical and low level, but still I would like to at least not reuse any of these terms in a different, inconsistent way. We could re-use "feature" or "distribution" (tbh, probably a "cloud component/composite" could end up as a "distribution" in ACE, and we would assemble those from "features" in ACE (which more or less could be mapped onto (sub)projects of Amdatu, maybe a bit more fine grained (as some projects really consist of more than one set of artifacts, such as the Amdatu Identity stuff we discussed, which has features that go on a "server" and things that go on a "client". Also, after giving it some thought, I'm not sure I like the fact that we define a component/composite as something that's "most cost effective". Going back to the theories behind modularity, there are several constraints the determine the "best" way to modularize a system. Cost is one of them, but there are others, such as low coupling, high cohesion, similar rates of change, etc. I feel we should be a bit more formal here and recognize all of those constraints (or not mention any in high level texts). > RPDC is a completely new term, even an abbreviation, which is risky, I would > like to have a more recognizable term Yeah, still thinking about this one. Somehow I feel we need to map this one on one or more of the technical terms I mentioned above. Greetings, Marcel
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
