cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Thu, 07 Nov 2002 13:12:19 GMT
Marcus Crafter wrote:

> Hi Stefano,
>
> 	Thanks for starting the ball here :)
> 	

My pleasure. If we don't implement this, Cocoon will simply collapse on 
its own inertial weight in a few years.

> 	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.

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).

> >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 ?

It is an implementation detail. It will be up to how we want to 
implement this.

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.

> 	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 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).

>
> 	
> 	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.
> 	

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.

>
> 	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.

Hmmm, that would require a centralized database of all block 
implementations available worldwide! or am I missing something?

>
> >
> > 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).

>
> 	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).

I'm in favor of any more modern solution than ECM roles, as long as this 
remains back compatible with what we have today.

>
> >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.
> 	

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.

>
> 	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.

Right. A deployment script is what you need. I would suggest the following:

  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

>
> 	Will the block protocol also be networkable and allow blocks on other
> 	hosts to be mounted remotely ?

AAHAHHHHHHHHHHHHHHHHHHHHHHGGGGGGGGGGGGGG! I knew it! I knew it!

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.

> >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.

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!

>
>
> >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.

>
>
> >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.
> 	

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?

>
> 	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.

>
> 	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.
> 	

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.

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                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message