At some point there is going to need to be a document explaining how EARs, WARs, JARs, Avalon Blocks, and Cocoon Blocks all relate.
Not being well versed in Avalon (yet), I'm not sure of the feasibility, but If Avalon could be abstracted further to handle this, and not introduce yet another level to this, I think it would help. The direction it is currently headed, the conceptual ramp-up on component architectures alone is going to be a challenge for new users. Just my mostly-lurker-$0.02-worth...... > ---------- > From: Stefano Mazzocchi[SMTP:[EMAIL PROTECTED]] > Reply To: [EMAIL PROTECTED] > Sent: Friday, March 29, 2002 5:00 AM > To: [EMAIL PROTECTED] > Subject: Re: [RT] Cocoon Blocks and internal web services > > Mircea Toma wrote: > > > > Hi, > > > > .............. > > .............. > > > > > This contract explicitly indicates: > > > > > > 1) web resources exposed by the block (for example files accessible > > > from other blocks) > > > 2) service components exposed by the block (for example avalon > > > components or sitemap components) > > > > I don't want to start another hot-headed discussion, but IMO Phoenix > > provides already a framework for service components. Lifecycle > management, > > logging, thread pools, class-loading management, and service > > assembly/interdependencies can be use for many parts of Cocoon. Cocoon > does > > a good job at managing fine grained components (sitemap components), but > > fails in managing coarse grained components (service components). > Example of > > services that can be imediatelly implemented as Phoenix blocks are > > components like: > > > > Server.java (hsql db) > > JSPEngine.java > > RendererFactory.java > > LuceneCocoonIndexer.java > > LuceneCocoonSearcher.java > > TranscoderFactory.java > > XSLTProcessor.java > > Store.java > > StoreJanitor.java > > ..... > > Yes and no. > > The intent is to use the same patterns that inspired the creation of > Phoenix (which are included in the original Avalon design that Pier, > Federico and I invented), but *not* to clone Phoenix! > > This is because the 'service' concept that can be provided by a > collection of logic components is very different from the 'internal web > service' concept that a cocoon block should provide. > > This different perspective, in fact, suggests different factorization of > blocks from the ones you outlined above, which are, in fact, > logic-oriented instead of 'concern-oriented'. > > Implementation-wise, I'm pretty sure we might end up "using" parts of > Phoenix directly (or patch it to make it abstract enough to handle our > needs as well), but at a totally different level (app-level rather than > core-level) and driven by different needs and concerns. > > > > > > > Each block contains a descriptor file (located in > > > /BLOCK-INF/block.xinfo) which indicates: > > > > > > 1) information about the block (author, version, original location, > > > license and all that other block metadata) > > > > > > 2) behavioral contract that the block implements (along with > > > information on mappings between the contract and this block's > > > implementation) > > > > > > 3) dependencies: this is a list of zero or more 'block contracts' > upon > > > which the block depends. > > > > Maybe I'm missing the point, but shouldn't be there another packaging > level > > where all blocks are bundled together with roles, sitemap, and flowmap > > descriptors? > > Yes, there must be a way to 'deploy a collection of blocks', just like > Phoenix does with 'server descriptors'. > > But I don't see the need for another packaging level because the roles, > sitemaps and flowmaps are already contained in the blocks. So, say you > want to install a webmail block, you install that and the system goes > around and shops for the blocks on which the webmail depends on. > > In case you don't want the installer to go around shopping for this, you > provide a single 'deployment descriptor' which indicates the entire > collection of URI where things are located on the web and the installer > goes there, grabs everything it needs and installs. But that's just one > xml file, not another package (it reduces the need for multipackaging > and makes it easier for us to publish blocks and create > web-service-driven repositories for behavior-based block shopping). > > > > a) have different implementations of the same block associated to > > > different blocks, so, for example, two different blocks might require > a > > > 'skin' role, but each of them might have associated different > > > implementations of that role. > > > > Do you mean here to replace ComponentManager/Selector with the CM > interface > > discussed for future Excalibur release CM.select(String role, Object > query) > > where, in this case, query would be the URL? > > I don't know. I'm currently not following Avalon development due to lack > of time and focus, the above isn't focused on implementation but only on > behavior and design. > > > > 5) for each dependency, the block manager scans the registry of > > > currently installed blocks in the system. If a block that implements > the > > > dependent contract is already installed, the user is ask to confirm > its > > > use, otherwise, the block manager will look in the block repositories > to > > > download the appropriate block and will ask the user to choose between > a > > > list of compatible implementations of that role. > > > > This things are currently implemented in Phoenix, but in kernel space. I > > agree that these features should be implemented in application space, > having > > a Cocoon specific implementation but service oriented. > > 'web service' oriented, I would say. > > My personal idea of a 'web service' is not just a way to have CORBA > implemented in XML over HTTP, but a way to provide *all* the information > one needs to use that web service. That requires not only logic, but > also all the resources (images, stylesheets, static pages, help > documents, etc..) that are required by the *user* of that service > (either a human directly or another web service) > > > > > > > In case of deployment descriptors, the block manager can be asked to > > > install the system without performing checkings (but these are > > > implementation details) > > ....... > > ....... > > > At the same time, this description format is very well going to be so > > > complex that WSDL will look like piece of cake and I'm scared about > > > this.... on the other hand, it might enable things like form > validation > > > and so on automatic and rather painless. > > > > I know that I am biased towards using Phoenix as a framework to develop > > Cocoon using a service-oriented approach, but I think its a good way to > > manage the increasingly growing Cocoon code base. > > Of course, I totally agree on the concept, but I don't think that > Phoenix is capable of providing solution for all our needs since Avalon > Blocks are very different from Cocoon Blocks (even if they aim use the > same design patterns). > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
