cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon Blocks and internal web services
Date Fri, 29 Mar 2002 10:00:22 GMT
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:
> (hsql db)
> .....

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

To unsubscribe, e-mail:
For additional commands, email:

View raw message