Guys, I would like to address some questions and state some ideas that I have had in mind for some time concerning Avalon Merlin and the role of the LDAP protocol. Embedding is a major part of it although just one part. I’d like to discuss these matters for the short term, some ways out and for a long term strategy.
Short Term Direction ==================== 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. The jar file contains a special JNDI provider for LDAP. The JNDI provider is intended for use on the server side. The provider does not go through the LDAP protocol stack to process JNDI calls. Instead it makes calls directly (within the same process space) against Avalon services that wrap the server’s backend subsystem. A major goal with respect to embedding criteria is to leverage common published API’s familiar to JDK users. When users attempt to embed the server into their applications a familiar API should be leveraged. The JNDI is the most natural fit within the LDAP space and this is what we have chosen. How we use it is the question. When an InitialContext is requested using the server side JNDI LDAP provider, the provider’s InitialContextFactory is invoked to create the first context. The JDK class, InitialContext, merely wraps this provider specific context implementation and forwards calls to it. The InitialContextFactory implementation depends on a singleton Avalon service. If this service has not been initialized then the InitialContextFactory implementation knows the server has not been started. It is hence the first Context request on an InitialContextFactory implementation which triggers the bootstrapping of the Merlin kernel and consequently the startup of the LDAP server. Once the LDAP server has started the InitialContextFactory implementation can then continue to handle the request for the first Context. 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. 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. Intermediate Term Direction =========================== Steve spoke about a set of goals a while back regarding the direction of Merlin in regard to federation and distribution. Directory services have a potentially massive role to play here as a corner stone technology or a firm foundation/base for a distributed service management platform. Many have already realized the need for looking up services in distributed environments using a directory. There are plans to back UDDI and even WSDL with LDAP. These schema designs are already appearing in the form of RFC drafts. LDAP is already an integral part of the .Net server platform. M$ has taken LDAP farther to date in terms of NOS and component frameworks than any other vendor. I’m personally somewhat disappointed in Java’s progress with its lack of directory technology integration into its component frameworks. Large distributed systems with hundreds and thousands of component services need industrial grade management technologies for their administration and enablement. LDAP is the key to orchestrating these distributed systems, whether it is leveraged directly or indirectly by backing another interface like UDDI, JMX or Steve’s proposed DPML, etcetera. This topic I started to write and realized it should fall under its own email category. But I shall continue to touch upon it and then later refine these ideas within another email. There are configuration time aspects that fall within the SCM domain dealing with the resolution of artifacts needed by a service. These aspects are being addressed very elegantly by Merlin today using some of the Maven code and the concept of a repository. I would like to see this go further however. I think there is another level we can go to. Maven needs to become a service which is directory enabled. Maven as we know it today becomes a simple client to access the server. Basically the information within the POM must be centralized in one place and accessible for frequent reads but very few writes. Today this is in a CVS repository and that should change to a directory. More details can be provided on this later. At some point SCM starts to fall under the category of Change Control. Here we deal with deployment time details into an operational environment. Applications deployed into an operational environment will be potentially composed of several services distributed across multiple machines both physical and virtual (JVM based). A centralized registry is required first to access and resolve inter-service dependencies. This is something that would ingrain itself into the Avalon lifecycle methods. The container services themselves exposed via Avalon lifecycle methods are intertwined with a directory. Think about Configurations being pulled based on a deployment profile from a directory. The deployment profile could be for a test environment or for a production environment and stored within the directory. When a service is handed a configuration it may come from anywhere or even multiple places. Some configuration info may default from the XML file and others may come from the directory who knows but we could simplify the configuration management of distributed applications here. Configuration is only one lifecycle example. The service dependency handling is another one I drool about. Namely think about resolving dependencies without regard to whether a service is local or remove. Should it even matter? 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. 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. 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. 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. Any remarks, thoughts? Alex? Steve? Anyone? Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
