On Wed, 4 Dec 2002 08:56 pm, Peter Donald wrote: > On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote: > > These are useful things, no question. Components need some way to get at > > data and services that are supplied by the container. Again, why do they > > care that a particular service or piece of data was supplied by the > > container or a peer? > > Components don't care what the origins of the resource are - all of it is > potentially "contextualized" on a per component basis and all generally has > certain criteria to adhere to but beyond that it is about it. The different > resources are separated out for the sake of humans and no other reason. > > Context is separated from ServiceManager because humans see them as > different things - especially during the assembly process.
Good point. Is this such a problem now that all the containers support auto-assembly, where the assembler's view goes from 'container-supplied vs application-supplied' to 'automatically-supplied vs explicitly-supplied'? It strikes me as unfortunate that the assembler's world view, being largely container-specific, should force an abstraction that means nothing to the component onto the component writer's world view. (Assuming that it *is* meaningless, which is what we're trying to figure out). An artifical abstraction is going to cause 'cognitive dissonance' of it's own. Consider the poor assembler that has to port or maintain an application across a bunch of containers, where services are container supplied in some containers, and application supplied in others. Or a collaboration between container and application in others. > > Yes, I know that they're "different logical things". But so are, say, > > authentication services and persistence services. We don't use different > > mechanisms to deliver those services to components. It would be > > pointless to do so: > > I disagree. If persistence were provided to the component and the component > was effectively made to be an OJB object or something like that then we > would likely provide persistence/transaction capabilities in a very > different manner. Most likely via some transparent EJB-like manner. > > In the same way if AAA services were provided to a component as part of > it's environment then it would likely also follow an EJB/Servlet style > setup where the container does it via interception and allows components to > access it programatically via something like > > getServletContext().isPrincipleInRole( String role, Principle p ); > getSessionContext().isCallerInRole( String role ); > (or insert real examples here or JAAS). Of course. I should have qualified my comment a little better. What we're talking about is how to slice and dice the 'left-overs': The resources that a component needs, which are not explicitly modelled by framework. So, we're not talking about a logger, or configuration, or parameters. Nor are we talking about transparent services that just happen. Nor would we be talking about AAA services modelled as part of framework - they wouldn't be 'left-overs' any more. However, AAA services that aren't modelled as part of framework are in scope. But we're back to the old question: Why is this: AuthenticationService = (AuthenticationService)context; better than this: AuthenticationService = (AuthenticationService)serviceManager.lookup( AuthenticationService.ROLE ); > If the services are things that the container provides to the component as > part of it's environment then the user perceives them as different to > services that the component uses. I can't think of one API that actually > merges the two concepts. Here's a couple: * EJBs and DataSources are both delivered via JNDI. * Myrmidon's TaskContext.getService() provides access to both container services and antlib-contributed services. Don't forget that many domain-specific APIs (mailets, for example) don't provide *any* access to arbitrary services, and so can't go merging them with container provided services. Honestly, I don't really put much credence in the 'no-one else does it' argument (except to ask why not?). I can't think of another API that splits resource delivery over multiple lifecycle methods, but, well ... > > 5. Who cares? Why are you bothering me with these questions? > > > :) Not too late to vote for 5 :) -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
