[EMAIL PROTECTED] wrote:

> The issue is that services are pluggable only within Turbine but
> not easily usable by projects outside of Turbine (like Cocoon
> for example).

When I created the BaseServiceBroker class my intention was easy
adoption of the services framework into other projects. TurbineServices
sholuld add only the bits that are specific to Turbine, like grabbing
essential config variables from the servlet environment.
 
> The goal of Avalon is to create an API that enforces low coupling
> between "components" (and "blocks") so that cooperation between
> components and/or blocks can be decided at run-time.
> 
> Making TurbineServices compatible with Avalon components would
> allow Avalon based project to use Turbine services and make
> some Avalon components available as Turbine services, hence
> expanding the pool of quality common utility code available for
> all the projects (even though they're still a lot more of
> Turbine services than Avalon components/blocks).
> 
> While the TurbineServices framework itself should be pretty easy
> to adapt to be compatible with named Avalon components, there are
> a lot of difficulties to make Turbine services available as
> Avalon components.
> A lot of current services were historically integrate part of
> the Turbine framework (and Turbine depended on a specific implementation).
> The API of these Services is still tightly coupled with the rest
> of the Turbine framework (it's the whole RunData issue).

Hmmm, can you give some exaples of Turbine depending on implementation
of
service, not the interface? I couldn't think of any.

On the other hand, impementation of many services depend on Turbine
environment
heavily, and therefore would be hard to extract for outside use.

Services should depend on ServiceBroker interface only, but right now
they depend
on TurbineSerices implementation, because of the
getProperties/getResources
methods. This is certainly bad, and I think that the only way to fix it
is including 
the ResourceService interface into the framework itself. The same goes
for LoggingService
which will be checked in Real Soon Now. ServiceBroker and the services
depend on it.
Including the interface in the framework will help decoupling service
implementations
from Turbine environment.

Rafal

--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to