> 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]