Timothy, First of all thanks for your detailed explanation of things. Timothy Bennett wrote:
>I know where you are going with this, and the answer is *not easily*. >You're thinking -- I've got this merlin application running and it's >hosting my components. Now, let me write and execute this other Java >application *external* to merlin so that it can invoke the service >methods that the merlin hosted components provide. Exactly, I was thinking that I should be able to do that. And if not, then things in Merlin Examples start making much more sense now. 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. 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 ??? Am I on the right line of thinking ? Thanks Vikas -----Original Message----- From: Timothy Bennett [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 9:05 PM To: [EMAIL PROTECTED] Subject: Re: Classloader and Container Vikas Phonsa wrote: > > Could someone pls explain what exactly is the difference between a container > and a classloader in Merlin. > Back me up, Steve, if more needs to be added... A container is a software entity that manages one or more components along with a context that those component(s) live within. For instance, let's take for example a plain ole Java server socket. In of itself, a server socket doesn't do much. Sure, it listens on a port for TCP connections, but that's about all without some help. You really need something to *manage* that server socket, such as spin off threads to handle the connections, maybe make decisions about what to do with the connections, determine when/how to startup the socket server and when/how to shut it down. That may not be the best example, but that gives you an idea about the role of the container. It's the world in which components are birthed, live and execute, and eventually die. The container is sort of a God-like thing, if that illustration makes sense to you. Not only does the container invoke the lifecycle methods of all the components (context, service, configure, initialize, start, stop, dispose, etc), but it also provides a context about which they operate. It might provide some services for all the components like security, isolation, maybe a framwork by which configuration information is provided to each component, and ultimately a framework and strategy for how the components (which don't do much on their own) are tied and wired together by dependencies to build a robust application. Another illustration might be that components are like microchips, and the container is the motherboard. A classloader in merlin is really not much more than the typical Java classloader concept. It is a strategy and loading all the classes (usually packaged in jar files) needed for your component(s) to live and execute. In merlin, each container gets is own classloader. Merlin allows you to build complex applications by wiring together blocks of components (or nested containers), and each container has its own classloader, or its own set of jar files that describe its code base of execution. > > The article "Developing with Avalon" says : > > ""The code that creates the Component is that Component's Container. The > Container is responsible for managing the Component's lifecycle from > construction through destruction"" So the container code would basically be > another java class then, right ?? > Likely, many classes... but yeah, a block of Java functionality. > So when we say the ECM is a container or Merlin is a container, are we > implying that they come with a java class that could load and manage our > components. Correct. And they MUST adhere to the interface contract outlined in the Avalon Framework. That is, we write components by providing implementations to one or more of the Framework interfaces: Contexualize, Configurable, Serviceable, Initializable, Startable, Disposable (lifecyle methods). As component developers, the Avalon Framework guarantees that containers will behave a certain predicable way, and that the lifecycle methods of our components will be invoked in a certain order and in a predictable fashion. That is, whether I'm in Fortress, Phoenix, or Merlin, I know the initialize() method will be invoked prior to the start() method. Therefore, I can build a system design around that contract. > > And in Merlin block.xml when we say : <container name="tutorial"> what are > we doing. Is a java class being created or loaded which is acting as the > container for our components specified in the block.xml. If yes, then which > class is that. > The important thing is that the block.xml is a container descriptor that merlin will use to build a container of components for you, and then manage their lifecyle. > And after that, say I want to use the RandomGenerator component that is > included in the examples to print a list of randomly generated numbers for > me on command line. Just like we run any simple java program from command > line. > > So I want to have a client program that wants to call a method in the > RandomGenerator component. And that client program would run from command > like -> java client. So how is that done. Ultimate aim of having and loading > components is so that other applications can use those, right ? > I know where you are going with this, and the answer is *not easily*. You're thinking -- I've got this merlin application running and it's hosting my components. Now, let me write and execute this other Java application *external* to merlin so that it can invoke the service methods that the merlin hosted components provide. That describes a scenario called Remote Method Invocation, and there are techologies that do that: RMI, SOAP, CORBA, etc. Most Avalon containers out-of-the-box do not provide RMI-like facilities natively. Containers typically protect and isolate your components from the environment around them. If your are familiar with EJB or servlet containers, the concept is nearly the same. However, there are technologies that are components themselves or extensions of a container's kernel that opens up the container to the outside world for remote invocation, namely Alt-RMI and there are some container value-adds out there that kinda provide this facility out of the box (Keel, I think...) Typically though, you write and deploy components in a container that will provide services to other components deployed within the container. So you would have a RandomGenerator service/provider, and some other component that would startup and as part of its execution (or as part of a yet another service it provides) would invoke the RandomGenerator. Think Service Oriented Architecture -- a philosophy of building robust applications that composed of tiny, reusable components that provide or consume services. Typically, I have need to build some server, but as part of the requirements, there is specific touch-points or gateways between my server application and the outside world it is interacting with. Those gateways might be the web, or a JMS bus, or a filesystem, or a third-party API that I'll wrap and host as a component. These gateways provide the highway for data or instructions to get *inside* my container hosted application, and trigger some unit of work my server was built and designed to do. That's certainly not the breadth and scope of how everyone uses Avalon containers, but that's my experience and I have found very little need for direct Remote Method Invocation of my components from applications external to the container. -- Timothy --------------------------------------------------------------------- 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]
