Monday, December 31, 2007
Thursday, November 29, 2007
Spring
Now Java component development is coming full circle. New programming techniques, including aspect-oriented programming (AOP) and inversion of control (IoC), are giving JavaBeans much of the power of EJB. These techniques furnish JavaBeans with a declarative programming model reminiscent of EJB, but without all of EJB’s complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice. And that’s where Spring steps into the picture.
Why Spring? Spring makes developing enterprise applications easier.
J2EE should be easy to use। In keeping with this philosophy, Spring was designed with the following beliefs:
Why Spring? Spring makes developing enterprise applications easier.
J2EE should be easy to use। In keeping with this philosophy, Spring was designed with the following beliefs:
- Good design is more important than the underlying technology।
- JavaBeans loosely coupled through interfaces is a good model।
- Code should be easy to test.
Wednesday, November 28, 2007
Tuesday, October 30, 2007
Thursday, October 11, 2007
Monday, October 08, 2007
Tuesday, August 21, 2007
AJAX vs web service
AJAX is a technique for improving the user experience. You are able to
update the user interface without posting back and redisplaying the
entire page to the user.
Web services are services accessed over http using xml standards that
allow software systems to communicate using a standard protocol, I can
write a web service implemented in java and use it with a c# client for
example.
AJAX is about user interfaces, web services are about systems
interfaces. If you write an html form with some fancy AJAX that's not a
web service. How does my java application talk to your web service? It
doesn't!
It very possible to design an AJAX system with the EJB or webservice.
There is only one thing you must note. Ajax is using HTTP verbs, that
means it only talks to Servlet for (java) or CGI, or anything that is
using HTTP.
Now if you really need to make use of EJB or webservices.
This is the basic design:
AJAX ---HTTP--> Servlet ---> EJB / WebService
AJAX ---HTTP--> Webservice
For directly accessing webservices, you need to construct your SOAP message in your javascript code. Then send it thru POST.
You will get a SOAP message where you need to parse the content.
For EJB, there is always a requirement for the server-side code that accepts HTTP requests, to be able to access EJB.
update the user interface without posting back and redisplaying the
entire page to the user.
Web services are services accessed over http using xml standards that
allow software systems to communicate using a standard protocol, I can
write a web service implemented in java and use it with a c# client for
example.
AJAX is about user interfaces, web services are about systems
interfaces. If you write an html form with some fancy AJAX that's not a
web service. How does my java application talk to your web service? It
doesn't!
It very possible to design an AJAX system with the EJB or webservice.
There is only one thing you must note. Ajax is using HTTP verbs, that
means it only talks to Servlet for (java) or CGI, or anything that is
using HTTP.
Now if you really need to make use of EJB or webservices.
This is the basic design:
AJAX ---HTTP--> Servlet ---> EJB / WebService
AJAX ---HTTP--> Webservice
For directly accessing webservices, you need to construct your SOAP message in your javascript code. Then send it thru POST.
You will get a SOAP message where you need to parse the content.
For EJB, there is always a requirement for the server-side code that accepts HTTP requests, to be able to access EJB.
Accept that new job -- the right way
- Start well
- Restate the fine print
- Ask for clarification
- Keep it short
- End on a positive tone
A sample letter
Dear Mr Sharma,
Thank you for offering me the position of marketing manager.
I would be willing to join the organisation effective January 5, 2006. I would like to restate the following terms and conditions agreed upon during our final meeting:
As agreed, the total CTC (cost to the company) would be INR 5 lakhs per annum.
- I would be based out of Mumbai and would be provided relocation expenses.
- The company would offer me boarding and lodging for the first 15 days.
- I would be entitled to performance based bonuses after six months of probation.
- I would request a clarification on the following:
- The medical insurance policy offered to the employee and the dependent family members.
- The annual leave and carry forward policies.
Please let me know what would be a convenient time to call you and discuss the same.
Looking forward to joining the team at XYZ (name of the company).
Yours sincerely,
Vilas Malik(M)
XXXX
Address
I visited to Egypt from 13th January to 17th January 2007. This Tour was oragnised by my company Talentica and we were 39 people in group. It was a wonderful memory of our trip to Egypt. Below is the link of some pictures taken during trip.
Thursday, August 16, 2007
Oracle 10g
Oracle 10g is Oracle's grid computing product group including (among other things) a database management system (DBMS) and an application server. In addition to supporting grid computing features such as resource sharing and automatic load balancing, 10g products automate many database management tasks. The Real Application Cluster (RAC) component makes it possible to install a database over multiple servers.
10g follows Oracle's 9i platform. Oracle says that the g (instead of the expected i) in the name symbolizes the company's commitment to the grid model. However, according to some reports, many early adopters are deploying 10g solely for its automation features and have no immediate plans of implementing a grid environment.
Grid computing (or the use of a computational grid) is applying the resources of many computers in a network to a single problem at the same time - usually to a scientific or technical problem that requires a great number of computer processing cycles or access to large amounts of data. A well-known example of grid computing in the public domain is the ongoing SETI (Search for Extraterrestrial Intelligence) @Home project in which thousands of people are sharing the unused processor cycles of their PCs in the vast search for signs of "rational" signals from outer space. According to John Patrick, IBM's vice-president for Internet strategies, "the next big thing will be grid computing."
Grid computing requires the use of software that can divide and farm out pieces of a program to as many as several thousand computers. Grid computing can be thought of as distributed and large-scale cluster computing and as a form of network-distributed parallel processing. It can be confined to the network of computer workstations within a corporation or it can be a public collaboration (in which case it is also sometimes known as a form of peer-to-peer computing).
A number of corporations, professional groups, university consortiums, and other groups have developed or are developing frameworks and software for managing grid computing projects. The European Community (EU) is sponsoring a project for a grid for high-energy physics, earth observation, and biology applications. In the United States, the National Technology Grid is prototyping a computational grid for infrastructure and an access grid for people. Sun Microsystems offers Grid Engine software. Described as a distributed resource management (DRM) tool, Grid Engine allows engineers at companies like Sony and Synopsys to pool the computer cycles on up to 80 workstations at a time. (At this scale, grid computing can be seen as a more extreme case of load balancing.)
Grid computing appears to be a promising trend for three reasons: (1) its ability to make more cost-effective use of a given amount of computer resources, (2) as a way to solve problems that can't be approached without an enormous amount of computing power, and (3) because it suggests that the resources of many computers can be cooperatively and perhaps synergistically harnessed and managed as a collaboration toward a common objective. In some grid computing systems, the computers may collaborate rather than being directed by one managing computer. One likely area for the use of grid computing will be pervasive computing applications - those in which computers pervade our environment without our necessary awareness.
Load balancing is dividing the amount of work that a computer has to do between two or more computers so that more work gets done in the same amount of time and, in general, all users get served faster. Load balancing can be implemented with hardware, software, or a combination of both. Typically, load balancing is the main reason for computer server clustering.
On the Internet, companies whose Web sites get a great deal of traffic usually use load balancing. For load balancing Web traffic, there are several approaches. For Web serving, one approach is to route each request in turn to a different server host address in a domain name system (DNS) table, round-robin fashion. Usually, if two servers are used to balance a work load, a third server is needed to determine which server to assign the work to. Since load balancing requires multiple servers, it is usually combined with failover and backup services. In some approaches, the servers are distributed over different geographic locations.
Real Application Cluster (RAC) is a component of the Oracle 9i database product that allows a database to be installed across multiple servers. According to Oracle, RAC's shared disk method of clustering databases: increases scalability because servers can easily be added or subtracted to meet current needs, lowers costs because companies don't have to buy high-end servers, and improves availability because if one server fails, another can assume its workload.
RAC's shared disk architecture is an unusual approach to database clustering. Most competing database products (such as Microsoft's SQL Server and IBM's DB2 for Windows and Unix environments) use the alternative, which is known as "shared nothing" architecture. Shared nothing architecture partitions data and only gives each server access to its own disk subsystem, while shared disk architecture gives all servers access to the entire database. This adds failover capacity to the database, because all servers have access to the whole database. Proponents claim that this capacity increases 9i's reliability and availability significantly. British Telecom, for example, reported that deploying the product enabled them to cut their failover time from a typical 20 minutes to between 10-60 seconds.
10g follows Oracle's 9i platform. Oracle says that the g (instead of the expected i) in the name symbolizes the company's commitment to the grid model. However, according to some reports, many early adopters are deploying 10g solely for its automation features and have no immediate plans of implementing a grid environment.
Grid computing (or the use of a computational grid) is applying the resources of many computers in a network to a single problem at the same time - usually to a scientific or technical problem that requires a great number of computer processing cycles or access to large amounts of data. A well-known example of grid computing in the public domain is the ongoing SETI (Search for Extraterrestrial Intelligence) @Home project in which thousands of people are sharing the unused processor cycles of their PCs in the vast search for signs of "rational" signals from outer space. According to John Patrick, IBM's vice-president for Internet strategies, "the next big thing will be grid computing."
Grid computing requires the use of software that can divide and farm out pieces of a program to as many as several thousand computers. Grid computing can be thought of as distributed and large-scale cluster computing and as a form of network-distributed parallel processing. It can be confined to the network of computer workstations within a corporation or it can be a public collaboration (in which case it is also sometimes known as a form of peer-to-peer computing).
A number of corporations, professional groups, university consortiums, and other groups have developed or are developing frameworks and software for managing grid computing projects. The European Community (EU) is sponsoring a project for a grid for high-energy physics, earth observation, and biology applications. In the United States, the National Technology Grid is prototyping a computational grid for infrastructure and an access grid for people. Sun Microsystems offers Grid Engine software. Described as a distributed resource management (DRM) tool, Grid Engine allows engineers at companies like Sony and Synopsys to pool the computer cycles on up to 80 workstations at a time. (At this scale, grid computing can be seen as a more extreme case of load balancing.)
Grid computing appears to be a promising trend for three reasons: (1) its ability to make more cost-effective use of a given amount of computer resources, (2) as a way to solve problems that can't be approached without an enormous amount of computing power, and (3) because it suggests that the resources of many computers can be cooperatively and perhaps synergistically harnessed and managed as a collaboration toward a common objective. In some grid computing systems, the computers may collaborate rather than being directed by one managing computer. One likely area for the use of grid computing will be pervasive computing applications - those in which computers pervade our environment without our necessary awareness.
Load balancing is dividing the amount of work that a computer has to do between two or more computers so that more work gets done in the same amount of time and, in general, all users get served faster. Load balancing can be implemented with hardware, software, or a combination of both. Typically, load balancing is the main reason for computer server clustering.
On the Internet, companies whose Web sites get a great deal of traffic usually use load balancing. For load balancing Web traffic, there are several approaches. For Web serving, one approach is to route each request in turn to a different server host address in a domain name system (DNS) table, round-robin fashion. Usually, if two servers are used to balance a work load, a third server is needed to determine which server to assign the work to. Since load balancing requires multiple servers, it is usually combined with failover and backup services. In some approaches, the servers are distributed over different geographic locations.
Real Application Cluster (RAC) is a component of the Oracle 9i database product that allows a database to be installed across multiple servers. According to Oracle, RAC's shared disk method of clustering databases: increases scalability because servers can easily be added or subtracted to meet current needs, lowers costs because companies don't have to buy high-end servers, and improves availability because if one server fails, another can assume its workload.
RAC's shared disk architecture is an unusual approach to database clustering. Most competing database products (such as Microsoft's SQL Server and IBM's DB2 for Windows and Unix environments) use the alternative, which is known as "shared nothing" architecture. Shared nothing architecture partitions data and only gives each server access to its own disk subsystem, while shared disk architecture gives all servers access to the entire database. This adds failover capacity to the database, because all servers have access to the whole database. Proponents claim that this capacity increases 9i's reliability and availability significantly. British Telecom, for example, reported that deploying the product enabled them to cut their failover time from a typical 20 minutes to between 10-60 seconds.
Tuesday, August 14, 2007
Monday, August 13, 2007
oracle 'drop connected user'
scott@ORA92> drop user SHAMBHU;
drop user sunil
*
ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected
scott@ORA92> select sid, serial# from v$session where username = 'SHAMBHU';
SID SERIAL#
---------- ----------
11 16
scott@ORA92> alter system kill session '11,16';
System altered.
scott@ORA92> drop user SHAMBHU;
User dropped.
scott@ORA92> select username from dba_users
2 where username = 'SHAMBHU'
3 /
no rows selected
drop user sunil
*
ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected
scott@ORA92> select sid, serial# from v$session where username = 'SHAMBHU';
SID SERIAL#
---------- ----------
11 16
scott@ORA92> alter system kill session '11,16';
System altered.
scott@ORA92> drop user SHAMBHU;
User dropped.
scott@ORA92> select username from dba_users
2 where username = 'SHAMBHU'
3 /
no rows selected
Monday, April 02, 2007
Display logo with URL
Create a 16 pixel image and name it favicon.ico now place it in your web root folder. This image will be display with URL.
for more information go to: http://www.favicon.com/
for more information go to: http://www.favicon.com/
Export Utility
First idea is write an engine that will copy data in xml before uninstall and store the data back before installation. But problem here is with auto generated key. If copy the data then we need not to copy auto generated key. And most of the table have auto generated key. If we restore the data then these key will regenerate again and it might be have different key value than previous. If auto generated key is different then we need to change all references of keys. This is the main problem otherwise this was so simple. Just we need to write a class that will use jdbc connection to any database and take data from database and copy it to xml file. In reverse for restore the database we only need to read xml data make query for insert and execute the insert query on database using jdbc. How to solve this problem?
One thing i can, this idea just i am thinking. insert the data one by one and get auto generated from inserted and compare this value with existing ID. if both match then commit otherwise delete the inserted record. Again insert the data with same record of deleted data. now i will get new incremented key and compare again. do same procedure till the match generated key and exist key. in case of oracle we need to insert the data. we need to only get next sequence no from respective seuence table. I think this would be work but i am not sure. I need to think more on it so it should work without any error.
LDAP
Introduction
Directories—public or private resource lists containing names, locations, and other identifying information—are essential tools often taken for granted in our daily activities. Typically these directories provide information about people, places, or organizations as part of an overall solution. For example, a telephone is virtually useless without a directory to correspond names with telephone numbers. Historically, most directories were only available in printed form.
As the computer revolution forged ahead, printed directories gave way to an electronic counterpart. Many application providers capitalized on the directory concept offering proprietary versions that extended their application’s functionality. Network operating systems also provided directories, typically housing user and device information. Unfortunately, these first generation directories were often developed with little or no concern for interoperability. Isolated and specific in function, they performed admirably. However, it was obvious directories needed to interact within a larger network ecosystem. This idea grew into the definition of the X.500 standard.
Directory Foundation: X.500
In 1988, the International Organization for Standardization (ISO) and the International Telecommunications Union (ITU) introduced the X.500 standard. X.500 defines the protocols and the information model for an application and network platform agnostic directory service. As a distributed directory based on hierarchically named information objects, X.500 specifications characterized a directory that users and applications could browse or search.
The X.500 paradigm includes one or more Directory System Agents (DSAs)—directory servers—with each holding a portion of the Directory Information Base (DIB). The DIB contains named information objects assembled in a tree structure—defined by a Directory Information Tree (DIT)—with each entry having an associated set of attributes. Every attribute has a pre-defined type and one or more associated values. Object classes, containing mandatory and optional attributes, are defined within a directory schema. End users communicate with an X.500 DSA using the Directory Access Protocol (DAP) while the Directory System Protocol (DSP) controls interaction between two or more DSAs.
X.500: The Need for a Lightweight Alternative
Understanding the need for a streamlined directory standard, several implementers proposed a lightweight alternative for connecting to X.500 directories. Ultimately, the first iteration of LDAP gained traction as a simple alternative to the X.500 Directory User Agent (DUA). The new LDAP definition:
• Simplified protocol encoding
• Used text encoding for names and attributes
• Mapped directly onto the TCP/IP stack
• Supplied a simple Application Programming Interface (API)
What Is LDAP?
Organized development of LDAP occurred on several fronts. However, the most notable work, and the first freely available implementation, was completed by the University of Michigan in 1993. The University focused efforts on developing a simpler TCP/IP version of X.500’s DAP. DAP was considered cumbersome as it pushed much of its workload to the client.
Although LDAP is well rooted as a simplified component of the X.500 directory, it has become the de facto directory protocol on the Internet today.
LDAP: First Generation
LDAP’s initial implementations provided gateway services between X.500 directory servers and clients. The clients communicated with an LDAP gateway through LDAP-enabled software. In turn, the gateway handled transactions—on behalf of the client—with the X.500 DSA. This model promoted directory interoperability allowing application providers to easily develop client software capable of communicating with an LDAP gateway service, regardless of the backend platform. While LDAP was initially created to meet this requirement, it became clear that a parting from X.500 was needed to simplify deployments. In 1994, LDAP was transformed into a directory specification with its own database and structuring conventions.
Once transformed, the LDAP specifications reflected a true client-server model with clients making requests directly to servers for information or operations. One or more directory servers may either perform the operation or refer the client to another directory server that may be able to provide the requested information, or perform the requested operation. The LDAP client will see the same view of the directory no matter which server is contacted. If necessary, the LDAP server can authenticate the client to the operating system in use. Once received, the LDAP server will convert a request into an appropriate format for the accessed directory. For X.500 directories, the LDAP server would convert the LDAP request into a DAP request.
Enhancements with Version 2
As interest in LDAP increased, several new developments extended its core functionality while streamlining its footprint. In 1995, Request for Comment (RFC) 1777 was introduced for LDAP Version 2. RFC 1777 eliminated many of the impracticable components of X.500 that were central to the original LDAP specifications. Furthermore, network connectivity was changed from the X.500 Open Standards Intercommunication (OSI) model to the TCP/IP model.
LDAPv2 is officially defined by the following RFCs:
• RFC 1777 – Lightweight Directory Access Protocol (v2)
• RFC 1778 – The String Representation of Standard Attribute Syntaxes
• RFC 1779 – A String Representation of Distinguished Names
The Current State of LDAP
Developed by the Internet Engineering Task Force (IETF) in 1997, the current LDAPv3 implementation is a renovation of LDAPv2, which primarily tackles deployment limitations identified within the previous version. LDAPv3 also enriches compatibility with X.500 along with enhanced integration with non-X.500 directories. LDAPv3 encompasses LDAPv2 within a new set of RFCs.
LDAPv3 is a Proposed Standard currently defined by RFC 3377, which includes, the RFCs below in addition to support for the LDAPv2 RFCs listed above :
• RFC 2251 – Lightweight Directory Access Protocol (v3)
• RFC 2252 – LDAP (v3): Attribute Syntax Definitions
• RFC 2253 – LDAP (v3): UTF-8 String Representation of Distinguished Names
• RFC 2254 – String Representation of LDAP Search Filters
• RFC 2255 – The LDAP URL Format
• RFC 2256 – A Summary of X.500(96) User Schema for use with LDAP (v3)
• RFC 2829 – Authentication Methods for LDAP
• RFC 2830 – LDAP (v3): Extensions for Transport Layer Security
What Does It Mean to Be LDAP Compliant?
Claiming LDAP compliance seems to be a common occurrence among today’s directory-capable vendors. In truth, applications may be either directory-aware—capable of reading an LDAP directory—or directory-enabled—capable of reading and performing other defined LDAP operations on a directory. Both implementations should be considered LDAP-compliant if proposed standards are followed in achieving an application’s desired level of LDAP functionality. Compliance with standards, however, does not ensure interoperability. Standards may lack sufficient clarity, even after formalization, leading to varying guideline interpretations.
The compliance task for directory server vendors weighs on their ability to conform to defined standards while ensuring interoperability with those standards. In addition, the process of standard formalization is an ongoing effort compounding the difficulty of achieving full compliance. For example, LDAPv2 has been formalized with a defined set of RFCs, however, LDAPv3, a Proposed Standard, is theoretically still a work in progress as it moves toward an Internet Standard. In summary, a vendor’s compliance statement should be viewed as their ability to implement a known set of RFCs, accurately interpret those RFCs to ensure interoperability, and provide a framework capable of incorporating new RFCs.
Achieving Compliance: IETF Applicability Statement
The IETF has established an LDAPv3 Working Group—ldapbis—with the charter of steering the previously mentioned LDAPv3 RFCs through the Internet Standards process. In September 2002, the working group submitted a revised LDAP specification for consideration as a draft standard. Currently, no IETF LDAPv3 conformance or compliance directive exists; however, one of the most pervasive documents to be delivered by the working group is an LDAP applicability statement.
Once complete, an LDAP applicability statement will guide independent vendors toward IETF-based LDAP compliance. In all probability, third-party test suites, based on the applicability statement, will be developed, allowing vendors and end users to accurately determine LDAP compliance. Until then, vendor declarations combined with existing third-party testing suites are the most suitable alternatives.
Achieving Compliance: Third-Party Test Suites
Several LDAP compliance testing and certification solutions exist in the marketplace today. One of the most prominent test suites is offered by the Open Group, a technology-neutral consortium. The Open Group also sponsors the Directory Interoperability Forum (DIF), which compromises architects, strategists, and product managers from customers and vendors of directories and directory-enabled applications. According to the Open Group, the DIF is chartered to “provide testing and certification for directory servers and applications that use Open Directory Standards.” Microsoft Corporation is an active member of the DIF.
The Open Group LDAP Certifications
Recently released in 2003 are two directory Open Group/DIF test certifications: LDAP Ready and LDAP Certified. With an LDAP Certified directory, the vendor guarantees its LDAP directory server conforms to the LDAPv3 specifications published by the IETF. On the other hand, an LDAP Ready application warrants that it will interoperate with an LDAP Certified directory.
To become LDAP Certified, directory vendors typically submit a warranty of LDAPv3 conformance using the Open Group’s VSLDAP Test Suite as a compliance measuring tool. The warranty is intended to ensure conformity to industry standard specifications, conformity through a product’s lifecycle, and the quick remedy of any nonconformity. At the moment, no vendor has received either of these new certifications.
Setting an LDAP Compliance Baseline
According to the DIF , a baseline of LDAP compliance can be measured by verifying support of the following RFC components. By no means exhaustive, an LDAP compliance baseline can be supplemented by support of additional LDAP RFCs, features, or extensions.
Directories—public or private resource lists containing names, locations, and other identifying information—are essential tools often taken for granted in our daily activities. Typically these directories provide information about people, places, or organizations as part of an overall solution. For example, a telephone is virtually useless without a directory to correspond names with telephone numbers. Historically, most directories were only available in printed form.
As the computer revolution forged ahead, printed directories gave way to an electronic counterpart. Many application providers capitalized on the directory concept offering proprietary versions that extended their application’s functionality. Network operating systems also provided directories, typically housing user and device information. Unfortunately, these first generation directories were often developed with little or no concern for interoperability. Isolated and specific in function, they performed admirably. However, it was obvious directories needed to interact within a larger network ecosystem. This idea grew into the definition of the X.500 standard.
Directory Foundation: X.500
In 1988, the International Organization for Standardization (ISO) and the International Telecommunications Union (ITU) introduced the X.500 standard. X.500 defines the protocols and the information model for an application and network platform agnostic directory service. As a distributed directory based on hierarchically named information objects, X.500 specifications characterized a directory that users and applications could browse or search.
The X.500 paradigm includes one or more Directory System Agents (DSAs)—directory servers—with each holding a portion of the Directory Information Base (DIB). The DIB contains named information objects assembled in a tree structure—defined by a Directory Information Tree (DIT)—with each entry having an associated set of attributes. Every attribute has a pre-defined type and one or more associated values. Object classes, containing mandatory and optional attributes, are defined within a directory schema. End users communicate with an X.500 DSA using the Directory Access Protocol (DAP) while the Directory System Protocol (DSP) controls interaction between two or more DSAs.
X.500: The Need for a Lightweight Alternative
Understanding the need for a streamlined directory standard, several implementers proposed a lightweight alternative for connecting to X.500 directories. Ultimately, the first iteration of LDAP gained traction as a simple alternative to the X.500 Directory User Agent (DUA). The new LDAP definition:
• Simplified protocol encoding
• Used text encoding for names and attributes
• Mapped directly onto the TCP/IP stack
• Supplied a simple Application Programming Interface (API)
What Is LDAP?
Organized development of LDAP occurred on several fronts. However, the most notable work, and the first freely available implementation, was completed by the University of Michigan in 1993. The University focused efforts on developing a simpler TCP/IP version of X.500’s DAP. DAP was considered cumbersome as it pushed much of its workload to the client.
Although LDAP is well rooted as a simplified component of the X.500 directory, it has become the de facto directory protocol on the Internet today.
LDAP: First Generation
LDAP’s initial implementations provided gateway services between X.500 directory servers and clients. The clients communicated with an LDAP gateway through LDAP-enabled software. In turn, the gateway handled transactions—on behalf of the client—with the X.500 DSA. This model promoted directory interoperability allowing application providers to easily develop client software capable of communicating with an LDAP gateway service, regardless of the backend platform. While LDAP was initially created to meet this requirement, it became clear that a parting from X.500 was needed to simplify deployments. In 1994, LDAP was transformed into a directory specification with its own database and structuring conventions.
Once transformed, the LDAP specifications reflected a true client-server model with clients making requests directly to servers for information or operations. One or more directory servers may either perform the operation or refer the client to another directory server that may be able to provide the requested information, or perform the requested operation. The LDAP client will see the same view of the directory no matter which server is contacted. If necessary, the LDAP server can authenticate the client to the operating system in use. Once received, the LDAP server will convert a request into an appropriate format for the accessed directory. For X.500 directories, the LDAP server would convert the LDAP request into a DAP request.
Enhancements with Version 2
As interest in LDAP increased, several new developments extended its core functionality while streamlining its footprint. In 1995, Request for Comment (RFC) 1777 was introduced for LDAP Version 2. RFC 1777 eliminated many of the impracticable components of X.500 that were central to the original LDAP specifications. Furthermore, network connectivity was changed from the X.500 Open Standards Intercommunication (OSI) model to the TCP/IP model.
LDAPv2 is officially defined by the following RFCs:
• RFC 1777 – Lightweight Directory Access Protocol (v2)
• RFC 1778 – The String Representation of Standard Attribute Syntaxes
• RFC 1779 – A String Representation of Distinguished Names
The Current State of LDAP
Developed by the Internet Engineering Task Force (IETF) in 1997, the current LDAPv3 implementation is a renovation of LDAPv2, which primarily tackles deployment limitations identified within the previous version. LDAPv3 also enriches compatibility with X.500 along with enhanced integration with non-X.500 directories. LDAPv3 encompasses LDAPv2 within a new set of RFCs.
LDAPv3 is a Proposed Standard currently defined by RFC 3377, which includes, the RFCs below in addition to support for the LDAPv2 RFCs listed above :
• RFC 2251 – Lightweight Directory Access Protocol (v3)
• RFC 2252 – LDAP (v3): Attribute Syntax Definitions
• RFC 2253 – LDAP (v3): UTF-8 String Representation of Distinguished Names
• RFC 2254 – String Representation of LDAP Search Filters
• RFC 2255 – The LDAP URL Format
• RFC 2256 – A Summary of X.500(96) User Schema for use with LDAP (v3)
• RFC 2829 – Authentication Methods for LDAP
• RFC 2830 – LDAP (v3): Extensions for Transport Layer Security
What Does It Mean to Be LDAP Compliant?
Claiming LDAP compliance seems to be a common occurrence among today’s directory-capable vendors. In truth, applications may be either directory-aware—capable of reading an LDAP directory—or directory-enabled—capable of reading and performing other defined LDAP operations on a directory. Both implementations should be considered LDAP-compliant if proposed standards are followed in achieving an application’s desired level of LDAP functionality. Compliance with standards, however, does not ensure interoperability. Standards may lack sufficient clarity, even after formalization, leading to varying guideline interpretations.
The compliance task for directory server vendors weighs on their ability to conform to defined standards while ensuring interoperability with those standards. In addition, the process of standard formalization is an ongoing effort compounding the difficulty of achieving full compliance. For example, LDAPv2 has been formalized with a defined set of RFCs, however, LDAPv3, a Proposed Standard, is theoretically still a work in progress as it moves toward an Internet Standard. In summary, a vendor’s compliance statement should be viewed as their ability to implement a known set of RFCs, accurately interpret those RFCs to ensure interoperability, and provide a framework capable of incorporating new RFCs.
Achieving Compliance: IETF Applicability Statement
The IETF has established an LDAPv3 Working Group—ldapbis—with the charter of steering the previously mentioned LDAPv3 RFCs through the Internet Standards process. In September 2002, the working group submitted a revised LDAP specification for consideration as a draft standard. Currently, no IETF LDAPv3 conformance or compliance directive exists; however, one of the most pervasive documents to be delivered by the working group is an LDAP applicability statement.
Once complete, an LDAP applicability statement will guide independent vendors toward IETF-based LDAP compliance. In all probability, third-party test suites, based on the applicability statement, will be developed, allowing vendors and end users to accurately determine LDAP compliance. Until then, vendor declarations combined with existing third-party testing suites are the most suitable alternatives.
Achieving Compliance: Third-Party Test Suites
Several LDAP compliance testing and certification solutions exist in the marketplace today. One of the most prominent test suites is offered by the Open Group, a technology-neutral consortium. The Open Group also sponsors the Directory Interoperability Forum (DIF), which compromises architects, strategists, and product managers from customers and vendors of directories and directory-enabled applications. According to the Open Group, the DIF is chartered to “provide testing and certification for directory servers and applications that use Open Directory Standards.” Microsoft Corporation is an active member of the DIF.
The Open Group LDAP Certifications
Recently released in 2003 are two directory Open Group/DIF test certifications: LDAP Ready and LDAP Certified. With an LDAP Certified directory, the vendor guarantees its LDAP directory server conforms to the LDAPv3 specifications published by the IETF. On the other hand, an LDAP Ready application warrants that it will interoperate with an LDAP Certified directory.
To become LDAP Certified, directory vendors typically submit a warranty of LDAPv3 conformance using the Open Group’s VSLDAP Test Suite as a compliance measuring tool. The warranty is intended to ensure conformity to industry standard specifications, conformity through a product’s lifecycle, and the quick remedy of any nonconformity. At the moment, no vendor has received either of these new certifications.
Setting an LDAP Compliance Baseline
According to the DIF , a baseline of LDAP compliance can be measured by verifying support of the following RFC components. By no means exhaustive, an LDAP compliance baseline can be supplemented by support of additional LDAP RFCs, features, or extensions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Subscribe to:
Posts (Atom)