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/

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.

My Photo Link

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.

RFC	Feature	Description
2251	Abandon	The server accepts abandon requests and performs the requested abandon operations.
2251	Add	The server accepts add requests and performs the requested add operations.
2251	Anonymous Bind over SSL	The server accepts a simple bind over SSL where the password is null and treats the client as anonymously authenticated.
2251	Authenticated Simple Bind	The server accepts a simple bind request with a password and authenticates the client by that password.
2251	BER	The server correctly encodes and decodes protocol elements using ASN.1 BER as required by LDAP.
2251	Client Server Communication	The client transmits an operation request to the server, which performs the operation on the directory and returns results/errors.
2251	Compare	The server accepts compare requests and performs the requested compare operations.
2251	Data Model	Each entry must have an objectClass attribute. The attribute specifies the object classes of an entry, which along with system and user schema determine permitted attributes of entries.
2251	Delete	The server accepts delete requests and performs the requested delete operations.
2251	Modify (Add, Delete, Replace)	The server accepts modify requests and performs the operations, including additions, deletions, and replacements.
2251	ModifyDN – Move Leaf Entry to New Parent	The server accepts modify DN requests to move leaf entries to new parents and performs the leaf move operations.
2251	ModifyDN – Move Renamed Leaf Entry to New Parent	The server accepts modify DN requests to rename leaf entries and move them to new parents and performs the requested leaf rename and move operations.
2251	ModifyDN - Rename a Leaf Entry	The server accepts modify DN requests to rename leaf entries and performs the requested leaf rename operations.
2251	Search	The server accepts search requests and performs the requested search operations.
2251	Simple Bind with Password over SSL	The server accepts a simple bind request over SSL with a password and authenticates the client by that password.
2251	Simple Common Elements	The server correctly encodes, decodes, and processes the simple common elements of LDAPMessage envelope PDUs.
2251	TCP as the Transporting Protocol	A server implements mapping of LDAP over TCP and provides a protocol listener IP port 389.
2251 2252	Definition of Attributes	The server’s entries have attributes in accordance with the X.500 model. The server supports entries with attributes.
2251 2252	Definition of Object Classes	The server associates entries with object classes in accordance with the X.500 model.
2251 2253	Distinguished Name	The server correctly encodes and decodes protocol representations of distinguished names.
2251 2829	Anonymous Simple Bind	The server accepts a simple bind request where the password is null and treats the client as anonymously authenticated.
2252	Definition of Matching Rules	The server supports matching rules in accordance with the X.500 model.
2253	Parsing	The server correctly parses string representations of distinguished names.
2253	Relationship with LDAP v2	The server accepts but does not generate certain protocol constructs that are legal in LDAP v2 but not in LDAP v3.
2253	Relative Distinguished Name	The server correctly encodes and decodes protocol representations of relative distinguished names.
2829 2830	SSL over TCP as the Transporting Protocol	A server implements mapping of LDAP over SSL over TCP and provides a protocol listener IP port 636.