avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject Re: Re: embedding strategies?
Date Tue, 21 Oct 2003 15:48:23 GMT
<snip/>

> >For the short term as stated before I would like to provide a single jar.  For the
time being, let us name the artifact ldap.jar.  This jar with a footprint under 1Mb would
contain a full fledged LDAPv3 compliant server using a default configuration and an embedded
Merlin kernel.
> >
> 
> Just for reference - the embedded Merlin unit test package is 152k. This 
> is basically made up of a kernel loader, repository classes and the APIs 
> for meta, composition and activation. The rest of the content is sucked 
> in automatically via the repository.
> 
> Is that an acceptable strategy?

Perfect! I was expecting a bigger size but the repo concept again saves the day ;). 

<snip/>

> >There are several questions I have regarding this process.  First what required and
optional information (parameters) do I need to bootstrap the Merlin kernel?  
> >
> 
> In the DefaultEmbeddedKernel a map argument is passed to DefaultLoader. 
> DefaultLoader extracts values from the map to build the 
> DefaultKernelContext which is used to build the DefaultKernel. The 
> DefaultLoader class is lacking some documentation concerning map keys 
> (but I've just fixed this). Basically it comes down to:
> 
> 1. a directory referencing the user repository base directory
> 2. optional directory that is the root anchor for optional-extension jar 
> files
> 3. optional home directory
> 4. optional url to a kernel configuration
> 5. optional array of block urls to be added to the root container
> 6. url to a targets configuration
> 7. a server mode flag
> 8. a debug flag
> 

This is exactly what I was looking for thank you Steve!


> >Likewise I need to list the parameters required of the LDAP server however this stuff
is extracted from Merlin during the contextualize and configuration phases.
> >
> >Another major question is how to get Merlin to access default configuration information
within this ldap.jar as a resource rather than off of the file system?  Or can Merlin do that
already.
> >
> 
> We would need to do some tweaking to enable this.
> 

Not a problem - I can help or wait until the feature is added.  Basically for the time being
I can use an extra parameter to point to a config.xml file on disk.  Let me know if I can
help out.


> There is a case for restricting a service to local. Outside of this 
> special case you want to make service resolution totally transparent - 
> i.e. the consumer should not be aware of any distributed aspect of the 
> provider.

This is similar to the use of the local interfaces in EJB 2.0 (EJBLocalObject and EJBLocalHome)
but more transparent I guess.  One should not have to deal with different interfaces let the
service manager handle these details.  Exception handling and sematics can also be abstracted
away nicely to be handled by the container.

> 
> >Now if you want to talk federation here we can take it to another email trail all
together.
> >
> 
> :-)
> 
> >
> >
> >Also note that the LDAP server itself or parts of it can be embedded back into Merlin
to enable these directory enabled lifecycles.  
> >
> 
> This is something I've been thinking about over the last couple of 
> weeks. For example - using LDAP as a configuration source requires that 
> deployment sub-system looks for and applies a stage provider from a 
> system context. The system context needs to be established relative to a 
> seperate containment hierachy (probably declared in the kernel). Anyway, 
> this is ties into the subject concerning container listeners and 
> internal Merlin facilities management.

Yes I have also been thinking about what it would take to embed the database machinery into
a kernel.  Basically a system backend needs to be available as part of the kernel so the services
can leverage the backing store.  The data within can be served out of the kernel using one
or more adapters you like for management.  An LDAP Adapter or JMX adapter can be used.  

Also note that LDAP has an Asynchronous notification mechanism which we will support right
under the JNDI provider that wraps the backends.  It would under kernel embedding senarios
have a role as an event source to notify on changes to entries within backends.  BTW this
is a great mechanism for getting the component reconfiguration stuff working.

<snip/>

> >Long Term Strategy
> >==================
> >
> >Avalon and specifically a service management platform like Merlin have the potential
for solving most of the lacking features of EJB.  Avalon can compliment and in some cases
and applications even replace the role of EJB.  In my experiences as a J2EE consultant and
architect I have seen developers bastardize the heck out of EJB; more constraints do not always
lead to better practices by the masses.
> >
> >Regardless, developers have taken EJB and tried to develop services with them.  Rather
than use EJB?s to design transactional business processes developers en mass are foolishly
trying to leverage EJB as a services programming framework and failing miserably.  Building
efficient fault tolerant services and their components should not always require EJB?s.  I
can continue on here for some time as well but I?ll quickly try to summarize a vision of tomorrow
by drawing it out ? please bear with me:
> >
> 
> I'm with you!
> 
> >
> >
> >Imagine a day where you need to build a service that is used by a bunch of other
services and some EJBs in various business processes.  You walk up to your computer and pull
up Eclipse.  You begin by creating an Avalon project.  You declare dependencies on artifacts
present in your Maven repository (using the Maven Eclipse plugin) and start building your
project (which is one in the same as your distributed POM).  Eclipse completes the project
creation by guiding you through a simple and quick lifecycle wizard to enable your service.
 Services and configurations can be defined locally or remotely from the directory accessible
through an Eclipse IDE feature (as opposed to a plugin).   After writing your service interface
(ROLE interface) implementation code you can, at the touch of a button, deploy your service
into a test environment.  This can occur by simply flagging the service POM as active in test.
 Oh and I forgot to mention the automatic SOAP, RMI, and AltRMI export facilities on deploy
that are auto generated if you wish them to be enabled.  Also EJB wrappers for the service
can be generated and deployed to any application server ? Ok I can go on for ever while imagining
the check boxes here but this is what I see for the time being and what I would like to explore
for the future.
> >
> >Any remarks, thoughts? Alex? Steve? Anyone?
> >
> 
> The big picture your describing is IMO spot-on .. including the relative 
> positioning of Avalon. On the positioning subject - I want to try and 
> build up some general documentation about Avalon, service oriented 
> architectures, and relationship/positioning to J2EE iniatives. Some of 
> the points you were hinting at need to be dragged out into the open.
> 
> On the technical front - as soon as we have JIRA up I want to try to 
> pull as much of the recent threads together with the objective of 
> sketching out a development roadmap - hopefully that should start to 

A quick dev road map - we need to do this quickly.  I needed this yesterday. ;)  I wish there
were more hours within the day.

> happen in a few days. Aside from embedding and some of the internal 
> architecture aspects of Merlin there is the entire "interactive Avalon" 
> subject which in part overlaps with an Avalon tools subject. I'm still 
> in colating mode but hope to draw some consolidated thoughts together on 
> that later in the week.
> 

Same here.  I'm just in awe of the possibilities right now cleaning up the drool off of the
floor.  BTW its a good move to go with Jira which will be a most valuable addition to coordinating
and tracking progress.

Cheers,
Alex



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


Mime
View raw message