Marcus Crafter wrote:
My pleasure. If we don't implement this, Cocoon will simply collapse on its own inertial weight in a few years.Hi Stefano,Thanks for starting the ball here :)
Yes. Exactly. But we will use unique identifiers to indicate those 'virtual-packages' to allow versioning of the contract itself. (virtual package is a pretty bad name for what is, in fact, a contract and not a real package).Similar to virtual-packages in Debian ? eg: exim; provides: mail-transport-agent sendmail; provides: mail-transport-agent mutt: depends: mail-transport-agent Which allows you to install any particular implementation of a virtual-package.
It is an implementation detail. It will be up to how we want to implement this.>2) polymorphism: I can have different implementations of the same >behavior and I can switch them simply by acting on the block manager, >without having to touch a single configuration line in any block. The >blocks are, in fact, sealed. Does the installer choose based on some policy which implementation will be used, or will it require an admin to choose it at install time ?
Like you, I see the need for automatic deployment without human intervention (this is great for clustered environments). So, instead of installing a cob, we could install a description of the entire collection of cobs with all the right dependencies (much as Phoenix does with server description files).
But I would like to have either manually choosen or hardcoded into a descriptor file. Policy-based rules are heuristic and might not work as expected.
I really can't see how we can do this without impacting severly on the neutrality of the system (and, therefore, on the communities behind those packages).If its policy based, do you think it's worth having the possibility to recommend a particular implementation due to other concerns outside of functionality like performance ? defects ? etc ?
I would write that as a note into the block descriptor for humans to read. I wouldn't go as far as creating an ontology of policies that the block deployer will have to infer from. Sounds like a very slippery slope to me.I'm not sure how FOP and iText compare in performance but if your application is really performance critical, and assuming both serializers are feature complete (as far as your report is concerned) being able to 'Recommend' (Debian talk) the faster one might be useful.
Hmmm, that would require a centralized database of all block implementations available worldwide! or am I missing something?Similarly if there are 2 blocks that implement the same block interface, but one of them contains a known defect, being able to 'Recommend' the other one might also be desirable, especially if the blocks are hosted from a source the user has no direct influence over.
> > 2) role(s): > the URI(s) of the behavioral role(s) this block implements > and exposes [optional] Do you mean the specification of which 'virtual-block's this particular block implements, and/or extra services that are exposed as part of this Blocks API ?
In your terminology, I mean the 'virtual-blocks'
>Also, the /BLOCK-INF/ directory contains the 'roles' file for Avalon >components: > > /BLOCK-INF/roles.xml After looking at the Merlin/etc oriented way of specifiying Avalon components, I'd be more inclined to use the x-files if possible (we could perhaps retain a roles.xml for ECM style compatibility reasons though).
I'm in favor of any more modern solution than ECM roles, as long as this remains back compatible with what we have today.RoleManager just provides the ability to shortcut your configurations (and with the introduction of Fortress specify your component handler), whereas the x-files allow you to do full meta-info analysis of components which I presume would be a necessity in such a distributed system. Merlin style x-files are described at http://jakarta.apache.org/avalon/excalibur/merlin/assembly.html. Essentially for each Avalon Component there is a manifest entry identifying it as so, and a .xinfo & .xprofile file identifying role oriented and instance information of the component. With this approach, components are loaded and validated automatically, and the container can tell you even before a client requests the first component whether the request and use of the component will succeed (as far as dependancies on other components, context entries, component versions, etc, go).
Instead of policy inference, I would think of providing some automation descriptor files instead. I would personally be afraid of the server making the wrong assumptions and installing something which is not what I asked for.
>Possible use-case scenario
>--------------------------
>
>Suppose you have your naked cocoon running in your favorite servlet
>container, and you want to deploy myblock.cob. Here is a possible
>sequence of actions on an hypotetical web interface on top of Cocoon
>(a-la Tomcat Manager)
>
> 1) upload the myblock.cob to Cocoon
>
> 2) Cocoon scans /BLOCK-INF/, reads block.xml and finds out the
>behaviors this block depends on as well as the block that it extends.
>
> 3) the block manager connects to the uber "Cocoon Block Librarian" web
>service (hosted probably on cocoon.apache.org) and asks for the list of
>blocks that exhibit that required behavior.
>
> 4) the librarian returns a list of those blocks, so the users chooses,
>or the manager allows the user to deploy its own block that implements
>the required behavior or to reuse those already deployed blocks that
>implement the required behaviors.
>
> 5) Cocoon checks that all dependencies are met, then unpacks and
>installs the blocks
>
> 6) For each block that exposes a sitemap, the deployment manager asks
>the deploying user where he/she wants to *mount* that block in the
>managed URI space or if he/she wants to keep them internal only (thus
>only available to the other blocks, but not mounted on the public URI space)
>
> 7) for each block that requires installation-time configurations, the
>block manager will present the user information on how to configure the
>block.
>
> 8) If no collisions in the URI spaces are found, the blocks are made
>available for servicing.
Sounds good to me, it would be also nice if the whole process could
be automated in some way without manual intervention though. I
think this is where my 'Recommends' comment way above comes from.
Right. A deployment script is what you need. I would suggest the following:For example, our application servers (16 of them) are restarted daily at 7am and it would be nice if the systems could come up automatically without requiring a deployment admin to answer/manually configure each of the 16 systems at startup/installation time.
1) you install things manually on one development machine
2) you test the system
3) when you are satisfied, you ask the block manager to replicate its status to a list of defined URIs. In this circumstance, the block manager of the cluster machine will act as a web service for the block manager of the development machine you are testing and complete replication can be performed transparently.
But, again, these are just implementation details.
Perhaps deployment configuration settings/profiles could be given to the deployment manager for automatic block deployment ? (...how many times can I use deployment in the once sentence!) :)
Yep
AAHAHHHHHHHHHHHHHHHHHHHHHHGGGGGGGGGGGGGG! I knew it! I knew it!Will the block protocol also be networkable and allow blocks on other hosts to be mounted remotely ?
My anti-FS meter went out of scale! :)
NO, cobs are cocoon services not web services.
If you want to connect to a remote service, and you want to implement this as a block on that machine, fine. But entirely different is the situation where the service lookup/discovery/trust/validation is done over the network.
And, to be honest, I really don't see how this could be useful.
Eh, that would be nice indeed, but the block interface is *JUST* a URI. Nothing more. There is no contract descriptor and this paragraph explains exactly why: because it would be too difficult to know where to stop describing the contract!>Some design decision taken >-------------------------- > >o) NO BEHAVIOR VALIDATION: > >I thought a lot about it but I think that having 'behavior description >languages' (such as the WSDL-equivalent for blocks) is going to be >terribly complicated, expensive to implement and hard to use and >enforce, even for simple blocks which don't expose a sitemap and are >just repositories for informations. > >For this reason, there is no validation taking place: if a block >implements a particular behavior and exposes it thru its descriptor >file, Cocoon automatically assume it implements the behavior correctly. > >In the future, we might think of adding a behavior description layer to >enforce a little more validation, but I fear the complexity (for >example) of validating stylesheets against a particular required >behavior. > >IMO, only human try/fail and patching will allow interoperability. On a side subject, how about a tool that could generate a skeleton block based on the block interfaces one wants to implement (ie. the block.xml, sitemap.xmap, etc). That would make it a bit nicer for developers as the tool could provide skeletons for what needs to be implemented for that block to correctly implement particular block interfaces.
>o) VERSIONING AS PART OF THE BEHAVIOR URI >o) CROSS-BLOCK SECURITY >o) COCOON MANAGER SECURITY > >The cocoon manager might be a block itself that connects to specific >cocoon internals and provides a web interface for it. So, it can be >removed or disabled when put on production. > >Also, the feature of automatic discovery of blocks thru the 'cocoon >block library' can be turned off or substituted with its own (even the >'cocoon block library' could be a block, so you could have your own >block library on your system instead of connecting to the apache one). +1, good idea. Perhaps automated block deployment could be done with a particular implementation of the 'automatic discovery' mechanism you describe above.
Yeah, that's another option.
I think everybody agrees here. I also think it would be great to count also Phoenix into that, althought I'm not sure on the issues there. Peter, what do you think?>o) OPTIONAL COP >TODO >---- > > 3) Which avalon container should we use since the one we currently use >(ECM) is not powerful enough? is there already a container which is >powerful enough to handle our needs as described here? if not, what do >we do? we implement our own or work with the avalon people to fix theirs >to meet our needs? I agree, ECM isn't powerful enough to handle all this. The 2 new Avalon containers are Fortress and Merlin. It would be great if there was some synergy between Avalon & Cocoon to develop/improve one/both of these containers to be suitable for use in Cocoon, rather than implement our own.
Merlin offers better support for the meta-info approach to managing components and container hierarchies, whereas Fortress offers better ECM style compatibility. Both don't yet handle package level dependancies but I don't see any problems adding that. The choice of container is important though as a lot of what you describe could be container concerns rather than application concerns (eg. package validation, versioning, classloader management, etc).
I'm fully aware of that.
Easy here. The difference between Avalon and Cocoon is that Cocoon has a bigger and more focused community. Avalon framework is great. But everything else, well, it's fragmented like hell. It's mostly a tons of one-man shows. I hate that.Having most of that at the container level makes it much easier for Cocoon which would then become the essential core, blocks, and perhaps any required container extensions, etc. This is where 2.1 has suffered IMO, as the 2.1 codebase includes features that IMO should really be handled at the container level (eg. extra avalon lifecycles, configuration file monitoring, sitemap/subsitap -> container hierarchy management, etc). Perhaps we need to investigate a bit deeper into what the container should do for us. This will allow selection of which container to be a bit easier.
Until this situations remains, I don't feel confortable with moving more stuff over to Avalon even if this makes sense architecturally.
Please understand that 'much easier' highly depends on the POV:
Once I get our admin app up and running here at the bank I'd be happy to look deeper into this.
Great! That would be *very* helpful! -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
