> whaoo, what a long email! :)

Sorry but the idea takes alot to spill out.  I bet Steve, yourself, and others on the 
Avalon team have similar ideas too - but I doubt it will be a one pager in all cases 
;) Once again forgive me.  Perhaps I'll keep the long emails down to one a week. ;)

> 
> 
> <snip/>
> 
> > Questions:
> > ----------
> >
> > There are several questions I have regarding this process.  First what
> > required and optional information (parameters) do I need to bootstrap the
> > Merlin kernel?  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.
> 
> I dont get it, could you explain your goal?

I was wondering what parameters I need to give the kernel to have it work properly.  
Take for example the base directory parameter that is used to calculate the home 
directory during Contextualization.  Parameters like that are what I would like to 
know about.

> 
> > 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. I’m sure this is just the beginning
> > of the questions to follow.  However as I stated before I shall chronicle
> > the process so we can document and evolve the mechanism if need be.
> 
> 
> Maybe your should provide your own Configuration impl
> Or use a LDAP to XML InputSource mapper/convertor (that could be really 
> usefull).
> 

I may have been unclear.  I was wondering if there is a mechanism to get Merlin to 
read the config.xml from within the ldap.jar.  I guess so since this file only needs 
to be in the classpath right?

> 
> 
> > Intermediate Term Direction
> > ===========================
> 
> <snip>
> 
> > Also note that the LDAP server itself or parts of it can be embedded back
> > into Merlin to enable these directory enabled lifecycles.  Merlin’s
> > configuration as well as the applications that run on it can be managed as
> > relational data within the directory.  It can be exported via LDAP for
> > management for certain aspects as well as through JMX.  Also LDAP
> > replication and master slave configurations can be leveraged to make the
> > environment fault tolerant.  The data we are dealing with here is idea for
> > a directory: it is highly critical information that is read frequently and
> > written to very INFREQUENTLY and it needs to be fault tolerant and highly
> > available.  Master slave replication in LDAP enables a high degree of
> > availability.  Plus LDAP the wire protocol is really fast since it is based
> > on ASN.1 and BER.  It can get small pieces of data to where you need it
> > faster than many other protocols.  Unlike the RDBMS where each vendor
> > invented their own inefficient line protocol for data transfer, LDAP is the
> > transfer protocol and very good at it.  So the data can be replicated for
> > clustering, it is highly available, and accessed rapidly in a standard
> > fashion.
> 
> Well, sure, LDAP has some good points (especially in 
> authentification/directory jobs), but RDBDB have the famous nice (old?) SQL 
> that (considering my experience) is far simplier for than Ldap search 
> request. (Do LDAP support transactionnal features?) 
> Also some guy would say that XML/DB are the best of both world. 
> 

Actually LDAP filters which are basically the where part of a SQL query are much more 
simple than SQL.  Here is a simple example of an LDAP search filter.

(& (ou=people) (l=sunnyvale) (c=usa)) 

Notice the reverse polish notation (prefix).  Then there is the search base DN you 
need to specify and the scope of either the entire subtree, one level below the search 
base or object level search.  The scope parameter as its name suggests restricts the 
search within some limiting scope.

The notation is simple and straight forward.  The equivalent sql on a table with a ou, 
locale, and country column would have been:

SELECT * FROM SOME_TABLE WHERE OU='people' AND L='sunnyvale' AND C='USA' ;

LDAP is not transactional and I don't really think it should have to be.  LDAP is a 
specialized line protocol as well as a data access model that can be backended by any 
database - transactional or non-transactional.

However keep in mind that LDAP and directories in general are intended for read 
operations.  I don't want to belittle LDAP for just implementing white pages but think 
of a directory like a phone book.  Your phone book does not change every day.  Ever 
year or twice a year it is updated and a copy is sent to you.  LDAP is perfect for 
fast access to non-transactional shared data that does not change frequently but is 
accessed repeatedly by several distributed clients.  It is great for making 
information redundant and highly available.

The RDBMS is designed more for OLTP based applications using short term transactions.  
It is designed to optimize writes whereas directories are designed to optimize reads.  
Directories usually have many more indices than their RDBMS counterparts and this is 
what makes reads more efficent and writes less efficient.

Basically architects need to think of the data their distributed applications manage 
in several ways.  You have common shared data that needs to be highly available and 
does not change frequently.  Then you have transactional data gathered from on line 
transaction process that is different for each transaction and the rate of writes is 
high.  These two different kinds of information should not be accessed, writen or 
handled in the same manner.  Their usage patterns are completely different so why 
should we use the same structures to store them.  The only commonality here of the 
data is that it is relational because it needs to be queried.

Does this make more sense? Do you agree with the different means to store these 
different kinds of information?

> 
> > We can continue to divide and conquer federation and distribution concepts
> > to get a clear picture of where we want to go.  However I fear loosing the
> > attention of people reading this email so I will jump to the long term
> > strategy now.
> 
> lol
> 
> 
> > 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:
> >
> > 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.
> 
> Image the day where you wake up, an say "hmm today I would like to interface 
> the car, with the coffee machine, when coffee I'll be hot, warmup the engine" 
> ;)
> Yeah, sure, the less we do, the more we can. ;)

;) Dreams are the begining.  I firmly believe in the fact that if you can imagine it, 
good science can materialize it.  Dreams are the innovative aspects and the rest is 
just mechanics.  We can build what we imagine.  There are no limits.

Alex



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

Reply via email to