I think that some of the services in Fulcrum are components and some are
services. A services layer, even according to Tomcat, offers a framework
with services to assist connecting clients coming in (connectors,
security) but also offers services to its components ("blocks") as well.
For example, Tomcat is a Service block which offers services to its
components "Web-Apps", including connectors/security to clients. A Web
App can be a "block" which can contain another service layer to its
components. For example a Tomcat Web App can be a SOAP Service.
So a Web App "block" architecturally contains another Service Layer
which implements SOAP and offers services to it's blocks which are now
Web Services which are still "large scale" and subject, it is assumed,
to further componentization as well as offering SOAP connectors / SOAP
security/ SOAP services to its client blocks.
I guess a Service Block offers both lower and upper layer services. I
think a service is something that is manipulated by
configuration/request/response and a component is more integrally
manipulated.
But "-0 on Fulcrum" definitely worries me about Scarab deployment.
Pat Monardo
-----Original Message-----
From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 25, 2002 1:50 PM
To: Turbine Developers List
Subject: Re: Turbine 3 direction
On Thu, 2002-07-25 at 12:38, Henning P. Schmiedehausen wrote:
> while the idea is cool, I'd prefer to get the fulcrum stuff to
> actually work with T2 and T3 and then migrate a stable code base. The
> current fulcrum code base is "preliminary" at best... :-)
>
> Please allow us to make at least one Fulcrum release before migrating
> to yet another platform...
I agree with Jason and James.
-0 for release of Fulcrum.
I'd be -1 except I'm going to be gone for most of August
and don't have time to fight about it between now and
when I leave. Nor do I have time to work on an
alternative. So I won't block a Fulcrum release, but
I'll ask really nicely. Please, please don't release
Fulcrum.
Here's why I'm opposed to it.
As I said on turbine-user earlier this week, I think the
decoupling of Fulcrum from Turbine 2 reveals that the
"services" are really "components".
<tangent name="definition of terms">
"services" are larger grain business services that an
application offers to external systems. Fulcrum's
services are mostly there to serve the internal needs
of the application -- localization, database pooling,
file upload, scheduling. Those are "components", not
"services". XMLRPC is also a component 'cos it's
there to support an external interface, but it isn't
a service in-and-of itself.
</tangent>
Avalon does components much, much better. It won't
be hard at all to implement the Avalon lifecycle
interfaces.
Also, we (me included) have done a fairly poor job of
supporting Fulcrum to date. I don't see a release
helping matters. I also think it's not appropriate to
release something if we intend to abandon it, or if
some of the developers are unwilling to support it.
I'd rather see the energy spent implementing Avalon's
lifecycle interfaces and getting Plexus integrated with
T2 and released.
It's probably slightly more work than getting Fulcrum
working with T2. But it's a much bigger payoff -- we
and Avalon would be able to share components.
> Personally, I'm a little scared about "being run over by Avalon". :-)
>
> And in search of docs, I'm upset by links like this:
> http://jakarta.apache.org/avalon/phoenix/what-is-a-block.html ... %-)
> (So, can anyone actually tell me what a block really is?)
I would ignore Phoenix and Blocks. It's not that they aren't
interesting, just not what Turbine needs. We just need to
implement the component lifecycle interfaces and make Plexus
work. As I said on the user list earlier this week, Avalon is
about components and about containers that compose and control
the components. We can focus on the framework and the
lifecycle interfaces and not worry about whether Blocks are
well defined.
> ATM I don't see no reason why any component of Fulcrum should be
> dropped. Maybe the db service, because it is no longer necessary.
Agreed. The components (except db) stay, with a little refactoring.
The Fulcrum framework gets replaced by an Avalon container.
-Eric
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
