Rafal Krzewski wrote:
>
> [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.
>
Yes, but the issue for external projects is more how to use the services
than the service framework itself. I think creating bridges between
the Avalon framework and the Turbine services framework should be quite
easy. The real difficulty lies in making the services themselves
work outside of Turbine.
> > 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.
>
I used past tense, with the recent changes in security, resources and pool,
I believe most if not all dependencies have been removed.
> On the other hand, impementation of many services depend on Turbine
> environment
> heavily, and therefore would be hard to extract for outside use.
>
Unfortunately true even if this (with hindsight) could have been prevented.
To take one example, look at the scheduler service.
Such a component would be of great use in many project and does not
inherently tie to any Turbine specific capability (not part of the layout
process or framework infrastructure, etc...) so its a perfect candidate
for "avalonization".
Take the SchedulerService interface and recursively list all the
dependencies required for building this interface (and this interface only) :
SchedulerService
JobEntry
JobEntryPeer
TurbineDB
DBConnection
ServletUtils
Turbine
RunData
everything...
See what I mean ? ;)
I believe the scheduler service can certainly be changed to remove a lot of
dependencies (simply make JobEntry an interface, that will remove the Peer
dependency which then escalates...).
My point is that componentization was not a design goal of Turbine to begin
with and trying to retrofit it in the framework will take a *huge* amount
of effort.
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
