Thanks Steve,
alexi --- Stephen McConnell <[EMAIL PROTECTED]> wrote: > > > Alexi Polenur wrote: > > >Thanks Stephen, > > > > It make things clear. I am glad you have chosen > to > >leave service package. IMHO names in service > package > >better represent the concept. Specifically > Composable > >vs. Serviceable. The word Serviceable goes more > >naturally with the "user of something" when > >"something" implies "service". > > I have just one more question what happened with > >equivalent of "Recomposable" in the service > package? > > > > WHen preparing the service package I did not include > a Reservicable > interface because I simply felt that the > Recomposable semantics were > underspecified. Discussion on Re-* has recently > commenced on the dev list. > > >I understand, taht the same method service can > >potentially be used to reassigned a ServiceManager > >for specific Servicable. > > > > If a policy concerning reserviceable existed, then > yes - it would imply > that the service can be serviced multiple time via > the service method. > > >However, I thought it was good idea of using the > >special interface to capture design decision of > >allowing or not allowing of such reassignment. > > > > > > One of the issues being dealt with is the difference > between the > recognition of a policy (such as reservicable) and > the mechanisms used > to declare that policy. A Reserviceable interface > is an approach (a > marker interface). Another approach is to declare > reserviceable policy > at the level of type meta-info. This second > approach ensures that > policy is not tied to the object implementation > (i.e. it does not need > to appear in the class interface list). > > Cheers, Steve. > > >Thanks Alexi > >--- Stephen McConnell <[EMAIL PROTECTED]> wrote: > > > > > >>Alexi Polenur wrote: > >> > >> > >> > >>>Hi all, > >>> > >>> I just started discovering Avalon framework, and > >>> > >>> > >>I > >> > >> > >>>have a question described in the title of this > >>> > >>> > >>email. > >> > >> > >>> I think I can understand potential difference > >>>between notion of component and service. > >>> IMHO the Component and Service are very closely > >>>related concepts or rather two different view or > >>>prospective on the same consept. > >>> > >>> > >>> > >>Correct. The service package was introduced as a > >>candidate replacement > >>of the coponent package in order to eliminate > >>artifical implications > >>introduced my the Component interface. In all > >>respects the component > >>package and service package are equivilent with > the > >>exception that > >>Component is replaced by java.lang.Object in the > >>service package. > >> > >> > >> > >>>The both refer to the > >>>"reusable", "replaceable", "interchangeable" > chunk > >>> > >>> > >>of > >> > >> > >>>software. The difference is that term Component > is > >>>used to look at the concept from the "structural" > >>>prospective when term service used to emphasize > >>>"behavior" aspect of the concept. In other words > >>>Service is a Component which exposes set of > >>> > >>> > >>behaviors. > >> > >> > >>Nope - sorry about the confusion here - the > service > >>package is > >>functionally the smae as the component package - > no > >>semantic > >>differences. The service package is the preferred > >>approach and as work > >>on the container side of things nears completion, > >>wel will probably > >>deprecate the component package and clearly > document > >>the reasons, > >>rationale and replacements under the service > >>package. > >> > >> > >> > >>> Even though I would be really interested to > hear > >>>your comments on my understanding (right or > wrong) > >>> > >>> > >>of > >> > >> > >>>consepts of Service and Component, my real > question > >>> > >>> > >>is > >> > >> > >>>more practicle. > >>> > >>> The question is not "What the difference > between > >>>Component and Service concepts" but rather "What > >>> > >>> > >>the > >> > >> > >>>reason of having two very similar set of > interfaces > >>>one in package > >>> > >>> > >>org.apache.avalon.framework.component > >> > >> > >>>and another in > >>> > >>> > >>org.apache.avalon.framework.service". > >> > >> > >>> Looking at the interfaces and JavaDoc > description > >>> > >>> > >>it > >> > >> > >>>seems to me that this two packages are modeling > >>> > >>> > >>very > >> > >> > >>>similar abstractions. > >>> > >>> > >>> > >>> > >>I hope that clears it up for you. > >> > >>Cheers, Steve. > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
