portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barnhill William" <barnhill_will...@bah.com>
Subject Re: RE: FYI: work in progress
Date Mon, 26 Jan 2004 18:45:26 GMT

Scott,

Basically the way to do what you plan, as I would envision it with 
commons-services, is
- I have not yet decided how I would integrate JMX, possibly it would 
be something like an MBeanService that JMX capable ServiceFactory 
instances exposed for each JMX capable service.
- commons-configuration with a std commons-services tree structure 
would be used for configuration, using Pico or using Avalon, or whatever
- The Adapter for a particular framework sits between the framework 
(aka Pico) and commons-services, translating the framework into commons-
service apis and calls, and commons-service exposed services look like 
regular framework services.
- To publish services as web services you would need to create an 
AxisServiceToolkit that
   (1) Translates commons-services configuration trees into WSDL
   (2) Translates GET/POST requests into 
          (a) service invocations
          (b) WS-I requests
   (3) Generates SOAP responses from the results of 2.1 or 2.2

Once such a ServiceToolkit was done the services of any framework that 
had a commons-services adapter package could be exposed as web services.

Say for instance that you went with Pico and in a year a better 
framework came out and you switched to that.  If commons-services had 
the support then that framework's developers might very well write the 
commons-services adapter so Apache projects could use that framework. 
If you were using commons-services you could just swap out the jar 
files and change of of the configuration info and be good to go.  Using 
Pico directly you would need to rewrite all your code.

Of course that scenario assumes:
(1) commons-services gets off the ground and functions well
(2) commons-services gets the level of adoption necessary to encourage 
framework developers to create an adapter package for their framework 

Pretty early for both assumptions, but I'm hoping I can get the initial 
code up soon, and that it is good enough to get others to start 
improving it with their contributions and bug fixes.

Bill



> - Apply transparent JMX on those components.
> - Use the Cornerstone's configuration system.
> - Use Cornerstone to orchestrate Pico components when needed.
> - Eventually use Cornerstone to transparently publish Pico 
> components as Web

----- Original Message -----
From: "Weaver, Scott" <Sweaver@rippe.com>
Date: Monday, January 26, 2004 11:37 am
Subject: RE: FYI: work in progress

> Hi Bill,
> 
> I think we are pretty much going to use Pico as our component 
> framework and
> use Cornerstone with Pico components to:
> 
> - Apply transparent JMX on those components.
> - Use the Cornerstone's configuration system.
> - Use Cornerstone to orchestrate Pico components when needed.
> - Eventually use Cornerstone to transparently publish Pico 
> components as Web
> 
>  Services.
> 
> What are you ideas on fitting this into the common services api?
> 
> 
> Regards,
> *================================* 
> | Scott T Weaver                 |
> | <weaver@apache.org>            | 
> | Apache Jetspeed Portal Project |
> | Apache Pluto Portlet Container |
> *================================*
> 
> > -----Original Message-----
> > From: Barnhill William [mailto:barnhill_william@bah.com]
> > Sent: Monday, January 26, 2004 10:07 AM
> > To: Jetspeed Developers List
> > Subject: Re: FYI: work in progress
> > 
> > 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 <" 
> target="l">http://www.springframework.org/>>     1.1.2 Setter 
> Dependency Injection (former type 2)
> >           Examples :
> >           Spring Framework <" 
> target="l">http://www.springframework.org/>>           PicoContainer
> >      1.1.3 Interface Driven Setter Dependency Injection
> >               Examples :
> >               XWork <" 
> target="l">http://wiki.opensymphony.com/space/XWork>>              
> WebWork 2 <" target="l">http://wiki.opensymphony.com/space/WebWork2>
> >      1.1.4 Field Dependency Injection
> >           Examples :
> >           Plexus <" target="l">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 <" target="l">http://avalon.apache.org>
> >           JContainer's DNA <" target="l">http://dna.jcontainer.org/>
> >           OSGi (to be confirmed)
> >           Keel <" target="l">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.
> > >
> > >Regards,
> > >*================================*
> > >| Scott T Weaver                 |
> > >| <weaver@apache.org>            |
> > >| Apache Jetspeed Portal Project |
> > >| Apache Pluto Portlet Container |
> > >*================================*
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Barnhill William [mailto:barnhill_william@bah.com]
> > >>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: jetspeed-dev-
> unsubscribe@jakarta.apache.org> >>>For additional commands, e-
> mail: jetspeed-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>---------------------------------------------------------------
> ------
> > >>To unsubscribe, e-mail: jetspeed-dev-
> unsubscribe@jakarta.apache.org> >>For additional commands, e-mail: 
> jetspeed-dev-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >----------------------------------------------------------------
> -----
> > >To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: jetspeed-dev-
> help@jakarta.apache.org> >
> > >
> > >
> > >
> > 
> > 
> > -----------------------------------------------------------------
> ----
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-
> help@jakarta.apache.org
> -------------------------------------------------------------------
> --
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message