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]
