Re: FYI: work in progress

Barnhill William Mon, 26 Jan 2004 08:06:59 -0800

Scott,

I took a look at JicarillaFramework. In his words it's... <quote> The Jicarilla-Framework builds upon Type-3 IoC, adding an Active interface to better support multi-threaded components. Besides some pretty generic utility code (like a set of base classes for nested exceptions), it adds basic abstractions for the building blocks of lightweight event-based systems, like sources, sinks, stages, multicasters, etc. </quote>

The goal of commons-services is to provide an Apache-licensed product for accessing any type of service framework with the same API and provide a lightweight service mechanism. A sub-goal is to make use of Apache products BSF and commons-configuration to add flexibility.

JicarillaFramework seems designed to support primarily Type-3 IoC, and primarily for embedding into a web server, which makes sense as the parent project Jicarilla is a web server.

The tree of service frameworks commons-services would eventually support the containers in the outline below that I found on picccontainer's web site (The initial emphasis will be on Apache hosted frameworks such as Cornerstone, Avalon, Fulcrum). I am not sure where exactly Cornerstone,Hivemind,Fulcrum, and JicarillaFramework go in this outline. It probably would be good to capture this outline with that information added.

<quote>
1.Inversion of Control
1.1 Dependency Injection (former type 3)
   1.1.1 Constructor Dependency Injection
         Examples :
         PicoContainer
         Spring Framework <http://www.springframework.org/>
   1.1.2 Setter Dependency Injection (former type 2)
         Examples :
         Spring Framework <http://www.springframework.org/>
         PicoContainer
    1.1.3 Interface Driven Setter Dependency Injection
             Examples :
             XWork <http://wiki.opensymphony.com/space/XWork>
             WebWork 2 <http://wiki.opensymphony.com/space/WebWork2>
    1.1.4 Field Dependency Injection
         Examples :
         Plexus <http://plexus.codehaus.org/>(to be confirmed)
 1.2 Contextualized Dependency Lookup
   1.2.1 Pull approach (registry concept)
         Examples :
         EJB that leverages JNDI
         Servlets that leveraging JNDI
   1.2.2 Push approach (former type 1)
         Examples :
         Servlets that leverage ServletContext
         Avalon <http://avalon.apache.org>
         JContainer's DNA <http://dna.jcontainer.org/>
         OSGi (to be confirmed)
         Keel <http://keelframework.org/>(uses Avalon)
</quote>

Another point I would like to stress is that this is not a service framework in itself. At it's highest level it basically provides a common means for configuration, and event dispatcher which knows only about the event identifier (a URI) and an event data map, and a service dispatcher that knows what services/resources a ServiceFactorySource provides through its ServiceFactory instances. Rather than create another framework, I am trying to provide a mechanism to use any framework, preferably with not or little change in the passed in configuration. So instead of having the debate of 'let's use xxx for jetspeed2', we will hopefully have statements like 'these are my experiences using xxx/yyy/zzz as the service framework implementation with jetspeed2'.

Bill Barnhill

.
Weaver, Scott wrote:

FYI,

Look at http://jicarilla.sourceforge.net/. I think the David Le Strat had
already made mention of this project, but will bring it to light this
thread.  This project currently allows you to deploy components developed
for other IoC containers into it.

-----Original Message-----
From: Barnhill William [mailto:[EMAIL PROTECTED]
Sent: Monday, January 26, 2004 7:32 AM
To: Jetspeed Developers List
Subject: Re: FYI: work in progress

Jun,

Thank you.  This initial effort is basically a rough cut and I will want
any help I can get in improving the initial codebase.  I've been doing
some reading on Open Source and I think that I will post code once the
commons-service package is done and a commons-services-demo package  is
done.  The demo package will implement a very simple use of
commons-services to access beans in jar files as  services. I've changed
my mind because it seems more in the spirit of Open Source to get the
service framework developers in from the get-go on implementing the code
to use all the features of their framework through the common API.

On another note, I imagine that the scheme part of URI schemes I
suggested below should be prefixed with vnd.apache. , in conform with
IETF suggestions.

Thanks again,

Bill

Jun Yang wrote:

Hi Bill,

I am very excited at hearing this effort!  This is definitely not an
easy task.  Thanks for doing it!  Please let me know if I can be of
any help.

Jun

Barnhill William wrote:

Hello all,

Just so everyone knows, I am currently working on a commons-services
package,  to attempt to do for service frameworks what
commons-logging has does for logging frameworks. It is progressing,
but not yet ready to publish. I plan to post code and docs on my web
site when it's ready.  I'll provide the URL at that time.  My aim is
for this to be accepted into the Jakarta commons sandbox, if I can
develop sufficient interest in the package.

The purpose of the package is to provide a common services API
suitable for use in an enterprise environment.  This package would
perform the same role for various service frameworks that te Jakarta
commons-logging package does for logging frameworks.

The requirements I am currently working from follow, and comments are
both welcome and appreciated:
1. MUST eat it's own dogfood when possible :), i.e. MUST user Jakarta
packages where applicable such as commons-logging and
commons-configuration

2. MUST NOT access property files, but instead use commons-

configuration

3. MUST have a helper class that has a method to read a property file
into a commons-configuration HierarchicalConfiguration

4. MUST have a helper class that has a method to write a
commons-configuration HierarchicalConfiguration into a property file

5. MUST NOT access XML files, but instead use a
HierarchicalConfigurationXmlReader to access the XML stored within a
HierarchicalConfiguration

6. MUST not express any knowedge of a particular service framework in
the core package.

7. Services MUST be requested via a lookup mechanism based on
resource URIs. The following are the only requirements for the
resource URI: (1) It is Hierarchial, (2) It is not Opaque.  The
specific scheme and path meanings are purposely not specified and
would be decided outside this framework, but the following URI
formats are offered for possible use:
 ifc.java:///fully/qualified/pkg/ifcname -- To lookup a service by
the interface it provides
 ifc.java:///fully/qualified/pkg/  -- to look up a list of services
that provide interfaces in this package
ifc.java:///fully/qualified/pkg/...  -- to look up a list of services
that provide interfaces in this package and all subpackages
role:///role/hiearchary/rolename -- To lookup a service by the role
that it fulfills
 role:///role/hiearchary/  -- To lookup a list of services that
fulfill any role at that specified heirarchy level
 role:///role/hiearchary/... -- To lookup a list of services that
fulfill any role at that specified heirarchy level and any sublevels

8. The interfaces and conceptual purpose of its methods MUST coincide
with the following statements:
a. ServiceToolkit -- Manages ServiceFactorySource instances and their
associated metadata
b. ServiceFactorySource -- Maps resource Ids to ServiceFactories,
providing the ServiceFactories and their associated metadata
c. ServiceFactory -- Provides the ability to request/release service
instances, based on the passed resource identifier or service id
d. ServiceEventListener -- Event listener for service events, this
expected to be exposed as a service by event capable components.
e. ServiceEvent -- Encapsulate an event passed to services, includes
an event identifier URI and a map containing event data.

9. An example implementation of an adapter package MUST be provided
that uses these interfaces to provide access to a known service
framework. The initial implementation will be for Avalon's Merlin
framework.  Two other implementations are planned: Cornerstone, WSIF

Basically this is just to let everyone know my current intent, and
that my notes on Cornerstone are on hold until after the package is
done.
The interfaces and configuration section are almost done, and I have
started the Avalon adapter package.

As soon as the Avalon adapter package is working I will post URLs to
sources and binaries for the following packages:
(1) org.apache.commons.services.api.*
(2) org.apache.commons.services.util.*
(3) org.apache.commons.services.avalon.*
(4) org.apache.commons.services.demo.*

Obviously, if I cannot get enough support for including this into the
commons then I'll need to change the org.apache.commons portion of
the package names.

Thanks,

Bill Barnhill


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FYI: work in progress

Reply via email to