LDAP서버의 DB로 버클리만 이용하는 것이 아닙니다. 

IBM Tiboli Directory Server - DB2

Oracle Internet Directory Server - Oracle

SunONE Directory Server - 버클리DB

openLDAP - 버클리DB

Aphelion Directory Server - 자체DB

등을 사용합니다.

버클리DB를 사용하는 것은 프로그램에 임베디드에 하기 쉬우며,

다른 DB와 비교해서 가볍고, 빠르다는 장점이 있어 사용하고 있고

상업적인 용도가 아니면 무료(소스공개)로 사용할 수 있는 점에서 사용하는거 같습니다.

SSL은 네트워크구간에서 데이터 보안을 위해 사용합니다.

Cyrus SASL 을 사용하는 이유가 무엇인지 ?는 잘 모르겠네요.

사이러스 프로젝트의 SASL(Simple Authentication and Security Layer)은  인증(정확하게는 Acess Control이겠지요.)이 요구되는 저장소에 접근시 간단한 방법으로 이를 만족시킬수 있는 API set을 가지고 있는 일종의 라이브러리이자 프로토콜이라고 보시면 됩니다.

이런 저장소들은 상당히 다양하지만 대표적인 경우으로 RFC 821, 822계열 즉, SMTP나 POP,IMAP,IMSP 같은류의 서버 구현시 이런 메카니즘이 필요하겠지요.

주목할것은 이놈도 94년부터 시작한 꽤 오래(?)되고 안정화된 프로토콜로 Netscape 의 J.Myers가 제출한 RFC2222 표준화되어 있습니다.

이 프로토콜은 초기단계에 sasl_checkpass() 같은 API호출을 통해 상당히 다양한 종류의 인증Realm과 Negotiation을 쉽게 구현할 수 있다는점이 장점입니다.  대충 지원되는 인증 Realm만 봐도 매력적인 놈입니다. ㅎㅎ

이외에도 이런 비메이져들도 모두 지원합니다.

그럼 SSL하고 차이는 뭐냐라는 의문도 생길수 있습니다. SSL은 대량의 Transport자체의 Application Message를 은닉할때 유용한것이므로 SALS와는 별도의 필요사항이지요. 즉 SSL은 LDAP add,modify,delete ..... 시에 훔쳐보는것을 방지하기 위해 프로토콜의 Payload를 보호하기 위해 도입된것이고 SASL은 이 LDAP객체나 Property에 접근하는 이 세션이 유효한가를 검증하기 위한 거라고 보시는것 맞을듯 합니다.

버클리 데이터베이스는 트랜잭션을 관리해 주는 소스가 개방된 라이브러리형 데이터베이스로서 확장성과 성능이 좋은편입니다.
일반적인 RDBMS들은 소켓 같은 IPC를 통해 SQL로 쓰여진 메세지를 전달 이를 해석하여 실행하는 형식(out-of process)으로 되어 있지만 버클리DB는 어플리케이션에 DB를 직접 엑세스하는 라이브러리를 제공함으로써 (예전방식의 DB라이브러리) 에플리케이션과 in-process공간에서 실행되는 형식으로 멀티 프로세스나 멀티쓰레드를 사용하여 동시에 데이타베이스 사용도 가능합니다.
또한 Java, C, C++, Perl, Tcl, Phthon 그리고 PHP의 풍부한 API를 제공해 주어 상대적으로 커스터마이징이 편하기때문입니다.
또한가지 장점은 강력한 이식성(Portablity)을 지원하여 모든 유닉스와 리눅스 플랫폼, MS-Windows 플랫폼, 32bit, 64bit 플랫폼, 하이엔드 인터넷 서버(High-end Internet Server)나, 데스크톱 시스템, 노트북 등 모든 곳에서 운용이 가능합니다. 뭐 임베디드에서도 쓸수도 있을만큼의 이식성을 가지고 있습니다.

이러고도 기본적인 DB로써의 기능인
1. Page cache management
2. Transaction and logging
3. Locking
을 지원하므로 상당히 괜찮지요.

뭐 다른점을 들자면 우리가 흔히 알고있는 다른 RDB처럼
- SQL 개념의 질의문 지원이나
- 객체 지향성(Object Oriented)지원이 약간 어렵다는 점.
- Network 기능이 없다.
- DBMS서버기능은 없다는 점 등입니다.

그러니, 그냥 DB라이브러처럼 사용하시면 좋은 구조인거죠.
사실 개발자 입장에서 보면 이놈의 DB는 Key와 value라는 두요소만 가지고 작업하는것이라, 무지하게 단순한 구조를 가져서 개발자가 책임져야할 부분이 많다는것이 흠 입니다만, 즉 좋은 설계가 중요하리라 봅니다. 이놈가지고 레코드 삽입,삭제,수정, 찾기 기능을 수행하고 좀더 상위 기능은 다 구현해야 합니다. 뭐, 혼자 맨땅에서 DB개발하고 하는것보다는 엄청난 혜택이지요.