On Monday 20 October 2003 19:40, [EMAIL PROTECTED] wrote:
> Guys,

whaoo, what a long email! :)


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

> 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).



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


> 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. ;)

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

Reply via email to