Nothing in this email is something new, but it will put some thoughts of mine down on the big component architecture picture.
Components exist for one purpose: to make development easier. Simplicity is the bottom line and the holy grail of development life. We do what is easiest to do. Rules and guidelines exist to make our lives easier in the long run. Those of us who have used components extensively know how they help you manage the effects of change in an application.
In the years of developing components, the system (aka container) writers have picked up a few tricks that simplify many aspects of working with components. Would life be easier without rules? Yes and no. Yes it would be easier to do what you want to do. No it would not be easier because others have no rules so there is no real way to work with others. The concept of contracts were the first things introduced to make components work. The contracts are the set of agreed upon rules so that two parties (components and containers) can work together for the mutual benefit of each other.
Later on, as component systems matured, we realized that components needed to be managed in some way. Most management concerns can be handled by the contracts, but sometimes it felt too confining as if the rules were there for the sake of rules. As more and more aspects of component requirements became available, other needs arose. For example, how can I add certain features to a set of existing components? How can I write tools to help make developing and deploying components easier?
Because there are many concerns, and features that can be dynamically added to a system in the container, we needed a way to control those features. For that reason, the concept of meta-information was introduced to the picture. Meta information allow tools and containers alike to discover important aspects of a component without forcing the same set of rules on all components. Take Phoenix for example. It requires all blocks to be singletons, it is a confining rule. Now contrast that with Merlin, Fortress, and ECM. They allow the component developer to tell the container how the component was designed to be used. The container then can adapt to the needs of the component as long as it knows what those needs are.
Without even realizing it, many containers either assumed a certain set of meta information about a component (like Fortress and ECM). Truth be told meta information is a key ingredient to controlling how aspects are applied to the component. The container can decide what to do with the information.
As we delve into the arena where the containers themselves are made up of a bunch of privileged components, we can have the container adapt to the way we want to work. This is in sharp contrast to huge component standards like EJBs and servlets. The relationship between container and component also provides natural places to apply cross-cutting concerns like performance monitoring, management interfaces, remoting components, and more. As long as we have an agreement that can be satisfied in some way, everything can work together.
It would be like us adapting our existing bank to now work with Quicken without having to go into the bank internals and changing its infrastructure. In essence, Quicken would be able to issue a "Quicken Bank Extension", and your bank would be able to load and use that extension so that you can now access your accounts through Quicken. It places more power back in your hand, without having to give up things you have grown to appreciate about your bank such as the tellers.
New and emerging component architectures are attempting address other issues like providing components in a typesafe manner, minimizing the feel that a piece of code is managed by a container, and in general making the use of components easier. Each step along the way has a reason for existence. Those who have simple needs should not be penalized, but again we don't want to go backwards and let the container dictate how we should develop our components. There are ways of extending how the container manages component instances that can get rid of the need for most of our interfaces in Avalon 4. For example, the container can do some magic to read the meta information (using reflection or attributes) and generate a factory that will safely create new instances of that component each time. That factory can be plugged in to something that manages component instances. Notice that the logic to handle the component lifecycle and the component lifestyle can be made completely separate. That way we can apply the same lifestyle (singleton, pooled, etc.) accross all components whether they are EJBs, Avalon 4 components, PicoContainer components, or something new.
The important thing to realize in the world of writing components is that with all the possibilities, we have to weigh it against what is *simplest* for the task at hand. If the one aspect of simplicity means that we have to trade container complexity for component simplicity, then we favor the component. In the end, simplicity is an elusive creature and we will always find a better way of doing things.
By leveraging the concepts and ideas that have proven themselves to work, we can come up with a set of rules of conduct to put together the nano-kernel (smaller and simpler than a micro-kernel). That way simple features can be added to the container until you have what you need. We can have the assurance that feature X will always be applied the same way. That means that we can confidently write components that take advantage of feature X. The nano-kernel just needs to know that feature X is required for the system so that it can do its job appropriately.
All our musings on component architecture are just that--musings. When we start working to make our musings a reality things change. We need to ask ourselves if something makes our lives easier or not. If I have simple needs, do I really want to have a steep learning curve? The user should be able to get up and running without having to think hard. Everything else is stuff that helps them understand what is happening on a deeper level. I don't think any of us qualify as being the naive user--we know too much. We can fix some itches that really have been around a while. Beyond that we need someone new to components to really let us know if things are as simple as they should be.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
