Thanks for the reply. So Niclas wrote:
>In a multi-tier system, each tier is potentially running on different >computers, and employs various types of scalability solutions. >SO, you would run one or more Merlin/Fortress instance(s) for each tier. My three tiers are : The Swing GUI ( Presentation ), The BusinessRules and the Database layer ( DAOs in my case ). And all these tiers are running on the same computer ( My database of course runs on a separate server ). Now this particular application that I mentioned is just a scenario I took up to see how and where Merlin would fit in, so that I can plan Merlin based application in future. So if the mentioned application is an entirely wrong example scenario for which Merlin was designed for, then pls point that out. So right now I have all my classes packaged in jars and there is a main jar that starts up the GUI and other dependency jars are in the classpath and this is how things work. And just to mention my jars placed on a web server could be downloaded and run to any machine on my network using webstart, but this is not a requirement. >For instance, I could take a bunch of low-level services; SocketServer, >PooledThreadMangement, MimeTypeResolver, ContentEncoder, and so on, and >packaged/wire all of those "components" together in a Merlin container, and >declare a HttpService, which could be used off-the-shelf by others who >doesn't care about how to assemble an HttpService from low-level >"components". So could I think of the classes in my application as various components that are dependent on other components ( which in turn could have their own dependencies ) and all these would be loaded by Merlin and the required functionality offered by GUI would be performed in the "Active Service" lifecycle stage of the GUI component. Or is this not a good example ? Thanks Vikas -----Original Message----- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 9:38 AM To: Avalon framework users Subject: Re: Classloader and Container On Tuesday 13 January 2004 09:00, Vikas Phonsa wrote: > I wrote a Web Services Client which sends Data Embedded SOAP Messages to a > Server. So is Avalon recommended for such kinda application. I think I read > that we could consider it for about anything. Avalon Framework is ALL about "Component Oriented Programming". With that also comes a few "tricks" (others would call it Patterns to sound more sophisticated) which make COP a rock-solid discipline of software development. 1. Inversion of Control (IoC). The "component" has no business trying to instantiate, locate or gaining access to resources. That is the job of the "container". The "component" can safely rely on the "container" providing the required service and resources, in Avalon's case via either the ServiceManager or the Context. 2. Separation of Concerns (SoC). A "component" should do "One Thing" and "Do It Well". By freeing (decoupling in a sophisticated term) the "component" from every other "component", software re-use can come in place nicely. 3. Separation of Interface and Implementation (SoII). This is a trick to allow for swappable implementations of a "service". For instance, I may define a UserPreferences service, and my initial implementation is a simple properties file. I can now write other components that uses the UserPreferences service without knowing the implementation details, and later we can swap the implementation, that use LDAP, RDBMS or SmartCards instead. > So in the big picture, all the classes in the three tiers of the > application ( which is not a web application atleast in my case ) would be > components loaded by more than one containers ( maybe one for each tier ) > and there would be many dependencies ??? In a multi-tier system, each tier is potentially running on different computers, and employs various types of scalability solutions. SO, you would run one or more Merlin/Fortress instance(s) for each tier. Now, although Merlin is a "container", Merlin has a container concept that is different from the "container" mentioned above. "container" above is responsible for making the "component" a happy citizen. Container in Merlin is a powerful concept of hierarchical compositions, potentially creating a new "component" from many sub-"components". A Merlin container is capable of wrapping one or many components, load their classes and resources in a dedicated classloader, and then declare one or many services fulfilled by the container. This explicit use of classloaders are to hide implementation details, improve security and open the door for many future tricks. This allows other "components" (in Merlin though) to use the new "component"'s services as if they were implemented by a larger monolithic "component". The immediate advantage of the Merlin's container concept, is that it packages a 'service solution' to reduce overly complex 'wiring' for any higher-level application using those services. For instance, I could take a bunch of low-level services; SocketServer, PooledThreadMangement, MimeTypeResolver, ContentEncoder, and so on, and packaged/wire all of those "components" together in a Merlin container, and declare a HttpService, which could be used off-the-shelf by others who doesn't care about how to assemble an HttpService from low-level "components". I hope this clears some confusion. Note; In the above text "component" refers to a solution of a service contract. "container" refers to the generic mechanism of where to place the "component". These terms without quotes have more ambiguous meanings. Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
