cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <>
Subject Re: shared object Proposal
Date Wed, 12 Jan 2000 13:12:55 GMT

Stefano Mazzocchi wrote:
> Michael Engelhart wrote:
> >
> > on 1/11/00 8:05 AM, Brett McLaughlin at wrote:
> >
> > > I'm +1 for the idea, -1 on your implementation (nothing personal ;-) ).
> > > I think things like this do not belong (coded) in Cocoon.  They are part
> > > of a large application frameworks, like Turbine (incidentally, where we
> > > have implemented something similar to what you outlined).  Those
> > > frameworks, which are designed to use things like Cocoon (Cocoon, keep
> > > in mind, is a _publishing_ framework, not an application framework),
> > > should handle services.
> > >
> > > So maybe take a look at Turbine, this is there, and then Turbine can
> > > certainly use Cocoon for screen processing.
> > >
> > > -Brett
> > nothing taken personally ;-)  Thanks for looking at the proposal.
> >
> > In some ways I agree but don't you think that Turbine could be considered
> > overkill for smaller web applications?  Things like database access (and
> > thus connection pools shared objects) are very common if not a requirement
> > on even the smallest intranet that may not have the need for something like
> > Turbine.
> Both are good points.
> Also, turbine should be included into something bigger than that, the
> Avalon framework which includes all the required design patterns. Cocoon
> should itself be an Avalon block.

OK, in theory I can go with this, but in practice, as you pointed out,
this seems to be a ways off :-(

> But the problem remains: designing such a complex architecture from
> scratch is _very_ difficult and error prone. Cocoon uses some of those
> patterns and tried to come up with a working solutions.
> I know turbine people are lacking the publishing features of Cocoon
> while Cocoon people are lacking the services Turbine does.

More than the actual services, I am more concerned that Cocoon does not
have a services _architecture_ which Turbine does.

> Turbine people believe Cocoon is a piece of their framework, but this is
> totally wrong. There is no such distintion as "application vs.
> publishing" framework. Because they mostly overlap in dynamic content
> generation.

Really?  Which Turbine people are those ;-)  Since I'm the only one
floating around it seems, I don't agree with that... I do think Cocoon
is separate from Turbine, just as say FreeMarker or WebMacro are... but
I do think it will generally be a matter of Turbine calling Cocoon
(using Cocoon) and not the other way around.

> So, what I want to see is NOT Cocoon called by Turbine, or turbine code
> called by Cocoon, but a _well_designed_ framework that includes both.

Hmmmm... what you are proposing is what I originally proposed Turbine
would be.  I got ... ramrodded ... because Jon was set on it being a
Dash derivitive, and most people wanted working code.  So I sacraficed a
lot of design to get a viable project started.  However, I agree with
you here Stefano, in theory.  But is Avalon (what you are certainly
referring to) close enough to useful to be that answer?  If not, I have
to say Turbine is fairly close to that structure.  I am close to adding
significant services architecture allowing things like XML-RPC for
remote services (without any user intervention), etc.  These belong to
the framework, not to an application.... if you honestly think Avalon is
closer, I can switch gears and incorporate it there.

> What Micheal proposed looks a lot like a light-avalon. This is the road
> to follow, IMO, but, unfortunately, I don't have that much time to
> investigate what is needed to make Cocoon + Turbine unite.

Again, I'm not sure I understand what you consider "unite".  Obviously
with the changes in CVS now, Turbine screens/control/whatever can use
Cocoon for generation. Of course there is not the integration so tight
that things like sitemap might sometimes apply targets to Turbine, etc. 
Is that more what you are saying?  If so, then we are looking at a wider
design (which I am for) but one that is not close to being realized
(which I am not so much for).  Worst case, we _have_ to have Cocoon 2
and Turbine 1 (final) cooperating.  One way or another, this is a must
in my mind.  Otherwise the ideas will lose interest....

I like the idea of a generic ServiceBroker, if you will.  This broker
has the responsibility of delegating requests for a given Service.  In
this general scenario, not only would things like Connection Pooling and
JNDI Contexts be services, but actual engines themselves.  For example,
I could request use of the Cocoon services, the Turbine services (with
Turbine retooled), etc.  So in essence an application would have to
write their own custom control structure, but for all the blocks, issue
requests to the service broker.  In my mind, these services are _never_
cast to what they are and have specific methods.  Instead, you have
something like:

public interface Service {

  public String getName();

  public void setName();
  public void init(Object ob);

  public Object get();

  public boolean execute() throws AppException;

  public void destroy(Object ob);


These general interfaces allow you tremendous flexibility!  You could
use the Service Manager to get a connection, for example:

Service connectionService = ServiceManager.getService("connection");
Connection con = connectionService.get();
// Use the connecction

This is very clean.  It allows the service "provider" to do things as
simple as returning a plain connection, or as complex as very advanced
connection pooling, all without the user of the framework having to
worry about it.

In the same fashion, remote services become easy.  Based on a property,
a request to getService() on a service that should be executed remotely
would actually return an instance of XMLRPCService, unknown to the
user.  The servce manager would load up the service instance with
information about the service and parameters to call (set in properties
files, for example).  Then when the user calls execute(), the
XMLRPCService would proxy the reequest across the network to the service
remotely.  Of course this is transparant because of the clean,
non-casted Service interface.

In the same way:

Service cocoonService = ServiceManager.getService("cocoon");

And suddenly, you have output.  This isn't what the final workings would
be, I think maybe instead you could actually init() the Cocoon service
with a sitemap fragment or something, but it's the idea that I'm driving

So you wanna tear me up Stefano, or do you like this ;-)


> Any thoughts?
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------

View raw message