The Apache Directory team proudly announces the Apache Directory project graduated incubation under the Apache Software Foundation (ASF) according to the ASF Board Summary for February 23, 2005.
- Posted by: Trustin Heuiseung Lee
- Posted on: March 04 2005 00:19 EST
Our primary vision is to build an enterprise directory server platform (Apache Directory Server) and its components where other Internet services snap in to store their data within the directory so they may be managed using LDAP. Those services include LDAP itself, DNS, DHCP, SLP, UDDI, NTP, and most importantly Kerberos, which can integrate with the services to provide full-featured network authentication service.
Features of Apache Directory Server:
* Designed as an LDAP and X.500 experimentation platform.
* The server exposes all aspects of administration via a special system backend.
* Both the backend subsystem and the frontend are separable and independently embeddable.
* Provides a server side JNDI LDAP provider which directly interacts with the backend storage.
* Powered by MINA, a powerful framework for building Internet protocol servers.
* Remote management via JMX.
* Java-based triggers and stored procedures.
The Apache Directory team is looking for developers and users to work
with the server and give feedback. Mailing list information is at:
Check the Apache Directory project at: http://directory.apache.org/
The Apache Software Foundation provides organizational, legal, and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users.
- The Apache Directory Project Exits Incubator by Mileta Cekovic on March 08 2005 18:13 EST
- What is difference between the frameworks by Daniel Fellars on March 08 2005 19:46 EST
- DB as backend? by Rickard Oberg on March 09 2005 04:25 EST
- DB as backend? by Trustin Heuiseung Lee on March 09 2005 07:51 EST
- RE: DB as backend? by Marc Boorshtein on March 09 2005 07:58 EST
- DirXML/LDIF by Rickard Oberg on March 09 2005 08:16 EST
- RE: DB as backend? by alex karasulu on March 09 2005 10:44 EST
- DB as backend? by alex karasulu on March 09 2005 10:26 EST
- Quality by Pavel Tavoda on March 09 2005 07:06 EST
Wow, Apapche is steadily rounding its family of servers.
I am wondering if any insight can be given as to the differences between the 4 frameworks listed: apseda,protocol,MINA,sedang?
they all look like they accomplish the same thing. does the directory project use all of them together, or is it configurable to use just one?
If I want to use one of these for a network server socket layer without using directory, what are the pros/cons of each?
APSEDA is dead. Protocol and SEDANG is also being considered dead for now. So there is only one choice: MINA.
MINA works as a network abstraction layer for Apache Directory Server, but this doesn't mean that MINA and ApacheDS is coupled. You can use MINA for any purposes.
Please give her a try, then you'll get to love her. ;)
Hi Daniel,APSEDA is dead. Protocol and SEDANG is also being considered dead for now. So there is only one choice: MINA.MINA works as a network abstraction layer for Apache Directory Server, but this doesn't mean that MINA and ApacheDS is coupled. You can use MINA for any purposes.Please give her a try, then you'll get to love her. ;)Cheers,Trustin
Why do you say APSEDA is Dead, How is MINA stronger then seda or Sedang.
Is Mina same as Netty.
Where can I get more Info on MINA and its merits.
I'm sorry for this late reply.
APSEDA was immature in its API design, so that users couldn't develop network applications easily. MINA provides comprehensive API that boosts development speed. And of course you can implement SEDA on top of MINA. SedaNG didn't evolve as fast as MINA, so it went back to sandbox. That's why we're using MINA.
We have a number of customers that are stuck with application account info in relational databases. They would like to expose them through LDAP, but I have been unable to find a good way to do so thus far. Would it be possible to plug in such a user database as a *limited* backend for the ADS? It would be read-only mostly.
Yes, you can. ApacheDS provides a user-implementable interface for backend storages.
Use a virtual directory. Virtual directories act as a proxy layer between your application and your data, allowing your application to communicate via LDAPv3 to what it thinks is an LDAP directory while the virtual directory communicates with backend repositories (such as LDAP, DB & webservices). There are primarily two leaders in the space:
Well, we've been discussing this (just now) with one of our customers, and it seems much easier to simply populate a standard directory (such as eDirectory) with application account data (i.e. use a meta-directory approach) using something like DirXML, or just plain LDIF files. It's definitely a very simple and robust solution anyway, and should be easier than hacking a custom DB backend.
But using a virtual directory, like the ones you describe, should also be a very good solution. I think it all comes down to customer requirements (e.g. is it required to be always up to date, or is a daily update ok), and pricing.
We hope to have virtual directory capabilities soon. It's just not that hard to do once you got the baseline protocols grok'd. Expect to see these capabilties emerging within a matter of weeks, perhaps as early as 0.9 or 0.10 are released.
BTW I'm totally shocked at how much Octet String and Radiant Logic can charge: ~50K and up for their products. Companies like Boeing seem to pay without a peep. Hopefully we'll have a free alternative soon and people can save a few thousand bucks. A virtual directory for us is just a mapping tool on top of a configurable dynamic backend. We are already working on one.
Actually, a virtual directory is NOT simply a "mapping" tool. What you are describing is more of a "simple proxy". Virtual directories offer far more functionality including:
Multiple namespace arbitration
Multiple directory integration
Logical joining of directory entries
Extended access controls
Seperate "views" per application
Numerouse proxt features such as load ballancing and directory routing
If a virtual directory were just a "mapping" tool, then everyone would just use openldap's proxy.
And as for why people pay 50k for such products: You have just spent a million or two deploying a portal, spent over a year in the deployment with a week to go until going production and just realized your portal software can't get access to your company's users because they are spread across several data stores. Re-architecting corporate data structures can take over a year while a virtual directory can be deployed in a matter of days. What's 50k compared to a failed multi-million dollar deployment?
In recent article at: http://searchwin2000.techtarget.com/originalContent/0,,sid1_gci1056461,00.html the guys at Burton Group are suggesting that LDAP is now moving from isolated to consolidated and now to distributed. The article give lots of good reason that I won't repeat here.
Distributed here means that while we can have multiple instances of LDAP, the underlying data are practically the same (or "integrated"). It's more like saying "ln -s" (linking a file in UNIX) rather than "cp" (copying a file). I agree with you that Virtual Directory is not simply a mapping tool per se but it must be able to combine entries from heterogeneous data sources (such as DB and LDAP).
There are also more reasons for people to use Virtual Directory aside from integrating heterogeneous data sources. It may also be used to shield main directory from attacks that would disrupt the enterprise operation. This feature is what OpenLDAP Proxy is for (http://www.samag.com/documents/s=9142/sam0405c/).
Marc I'm not suggesting that a VD is *just* a mapping tool. If I do not mention all the aspects of a VD in a 5 line TSS post forgive me. It also does not mean that I think a VD is only a mapping tool. Nice try.
Regardless you have an interesting stance on the cost to the customer. I suspect the reason why a 50K cost to a user is ok with you is because you are at the receiving end: an Octet String employee. Perhaps you should come out and say this. I don't blame you for your stance. I just think there's subterfuge in recommending the companies you work for as if you're not an employee but just another commentator. Your approach is so typically commercial.
Is Radiant Logic a reseller of Octet String's VDE?
First I'd like to say that the tone of your argument is not necessary. People may talk and disagree without being rude to each other.
Second I'd like to point out several facts about Octet String and myself (Marc Boorshtein):
1. I am no longer an employee at Octet String
2. Octet String has been very active in the open source community.
3. Radiant Logic is not a reseller, but a competitor to Octet String.
Now, as I have stated in point #2, Octet String has been a VERY active member in the open source community. Octet String's co-founder and CTO wrote a 100% java ldap server almost 5 years ago and released it under the GPL (http://javaldap.sourceforge.net/). He recently granted the rights to CodeHause to re-license it under the academic free license. Previously he wrote the PerlLDAP and co wrote the Net::LDAP libraries, both under the same license as Perl.
In addition to his own Open Source work, Clayton continued his dedication to the community while at the head of Octet String. In 2002 he hired me, as an Open Source developer, to write the JDBC-LDAP bridge. The bridge is a tool that allows JDBC based applications to communicate with LDAPv3 based directories. Once the tool was completed, Octet String donated it to OpenLDAP and it is still the only jdbc-to-ldap driver that is both free as in speech and as in beer. Once the jdbc-ldap project was completed, I was hired on as a fulltime employee. While at Octet String I continued to develop and improve the bridge as well as fix several bugs in the JLDAP ldap library (mostly around web services) and have continued to improve and develop the bridge and the SQL Directory Browser with the full support of Octet String.
Finally the cost is not "OK" with me because I use to work at Octet String; that is what the market has deemed its worth. It's a simple matter of supply & demand as well as the economy of scale. The demand is derived from very large companies where certain identity management problems and scale require the supply of software to fix those problems. As a case in point, look at the example I gave in my previous posting. Who would be spending 1-2 million on a portal deployment? It would not be a small business that has a few hundred users where such a price tag is cost prohibitive. It would instead be a company like Boeing that has 100k+ employees plus partners where a massive heterogeneous environment exists that spans several continents.
As for being "so typically commercial", we live in a society where it is commerce that allows us to put food on the table and take care of our families. As I have no intention to get into a discussion about the merits of capitalism in this forum (though I am always quite happy to in other arenas), I would simply like to state that the over whelming amount of interaction and donations to the open source community from Octet String should show that while it is in fact a business it is very active in endeavors that they will not be profiting from directly. I'd like to close with a comment from one of Octet String's customers "You saved us millions and saved my job".
p.s.: If you re-read your posting you do in fact say it is *just* a mapping tool :-)
Richard you can definately do this using a custom partition (backend) implementation. Yes you can plug it in. Actually in a few (maybe couple weeks) we'll release 0.9 which will make it much easier to do so.
Eventually though we should be able to introduce some virtual directory capabilities. Once this is in place you won't have to devise a new custom backend. Rather you would use mapping tools to map an RDBM schema to a DIT subtree. The VD engine of the server would do the rest.
They would like to use it as X.500 experimentation platform? What about real value of directory service like reliability, performance, security, ... .
Is it just another project for fun or something real?
We're developing Apache Directory Server for real enterprise environment. Its current version is 0.8 yet, and therefore we're striving to make it more suitable for production use. Currently, you can run ApacheDS with LDAP protocol.