> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > Nicola, your problem is in your loose definition of > > component. Not all objects are components. The SocketManager > > is a component. The Socket is an object. > > > > *ALL* components have the following attributes: > > > > 1) Separate interface from implementation (Socket fails here) > > > > 2) No argument public constructor > > > > 3) Distributed in binary form (aka jar file) > > So if I come up with a general Socket interface, we're good > to go with Socket as component? > > Didn't think so. > > Berin, you can argue endlessly that a socket isn't a > component, or what makes a component. Point is this: > > + There will always be something that fulfills your every > requirement for a component but that must still be pooled.
Leo, Who said this was about pooling? This is not about pooling. > + We do not want to write a separate manager for each one of > those. No matter how much that fits your view of good > architecture. *It is not practical.* Again, you have to have the proper abstraction. In this case, the Socket itself is the *wrong* abstraction. The container should not make up for your poor design habits. Also, don't forget you are not the only one writing components. Someone else will come up with an abstraction that works in multiple environments. > Can you convince us that you have a better solution than > what exists now, or that we for some reason do not want the > container to handle the pooling, do so. I repeat. THIS CONVERSATION IS NOT ABOUT POOLING. Please do not confuse the issues. WE ARE NOT ADDRESSING POOLING. We are addressing ABSTRACTION. > The arguments we have had regarding that would indicate > that no such solution exists. Let me ask you. In this instance, would you implement information as a component, or would you provide an abstraction to get the information? Let's leave the socket alone for the moment. In Avalon, it is not the container's responsibility to obtain the information from the persistence mechanism, nor to validate it is the exact information you need. It is also not the container's responsibility to determine if the calling user is permitted to see that information. All of that should be provided in an abstraction that takes care of all those points for you. Done correctly, the abstraction can be generic enough to work for many different types of information--increasing its usefulness. The concept of representing your information as psuedo-components (I refuse to give them the honor of full component status) does not scale because you are forced into one way of doing things, and you are requiring the container to make up for your lack of design. Those things are bad. Even in EJB Entity Bean design, you have a Home interface that allows you to get a particular instance of the entity bean. That home interface is the level of abstraction that I am advocating. You should specify *HOW* to get your information, not *WHAT* the information is. It would be even better if all your components were like stateless session beans--but we know that is not always practical. What happens if you want to change the persistence mechanism? What happens if you want to change the way security is enforced? When you represent your information as components, you have to change the *same* logic in several locations--even if you use an external component to do the actual persistence management. If you have one interface to get at your information, you can change it in one place and everything is happy. Information is practically just at too fine a detail for the design to scale properly. Worse, designs centered around information rather than who works with the information are harder to comprehend, and have more points of failure. This has nothing to do with pooling. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
