The Story
Avalon classic:
|-------------| |-----------| | | | | | container |<------>| component | | | | | |-------------| |-----------|
Which has evolved ( meta + composition + maven project ):
|-------------| |-----------| |-----------| | | http | | | | | repository |<------>| container |<----->| component | | | | | | | |-------------| |-----------| |-----------|
Leading to the next logical step:
|-------------| |-----------|
| | | |
| repository |<------>| agency |
| | | | |------------| |-----------|
|-------------| | | http | | | |
| |<----->| container |<----->| component |
|-------------| | | rmi | | | |
| | ldap ? | | iiop |------------| |-----------|
| registry |<------>| |
| | | |
|-------------| |-----------| Scenario - forget about "locate, install, customize, deploy" - instead think about register once, and execute. For example, if I have a composite component that requires a product install, instead of dragging in a default configuration, I want to drag in a customized configuration matching my profile and environment and I want it to work with zero (or at least near zero) intervention. That logic resides in the "agency". It uses information about me, my domain, resources, etc. (stored in a registry) to dynamically construct a solution based on deployment information and artifacts available across a set of repositories.
Any thought about how we could go about building such an animal?
Stephen.
Followup
Self Healing Networks - http://sys-con.com/java/article.cfm?id=2201