LDAP Structure

LDAP directory servers store their data hierarchically.

Why break things up into a hierarchy? It is easier in relationships understanding , You may wish to grant permissions to a group of individuals based on the directory structure and Combined with replication, you can tailor the layout of your directory structure to minimize WAN bandwidth utilization.

DN (Distinguish Name) it is The top level of the LDAP directory tree is the base, referred to as the "base DN." A base DN usually takes one of the three forms listed here.

Let's assume I work at a US electronic commerce company called FooBar which is on the Internet at foobar.com

1- o="FooBar, Inc.", c=US (base DN in X.500 format)
O refers to the organization, C refers to company headquarters.

this was the preferred method of specifying your base DN but these days, most companies are (or plan to be) on the Internet. And what with Internet globalization, using a country code in the base DN probably made things more confusing in the end. In time, the X.500 format evolved into the other formats listed below.

2- o=foobar.com (base DN derived from the company's Internet presence)
This format is fairly straightforward, using the company's Internet domain name as the base.

3- dc=foobar, dc=com (base DN derived from the company's DNS domain components)
this format is split into DC(domain components): foobar.com becomes dc=foobar, dc=com.
In theory, this could be slightly more versatile, though it's a little harder for end users to remember. And it is the most recommended format.

Underneath your directory's base, you'll want to create containers that logically separate your data. most LDAP directories set these logical separations up as OU entries. OU stands for "Organizational Unit," which in X.500 was used to indicate the functional organization within a company.

LDAP directory tree (not including individual entries) might look like this:
dc=foobar, dc=com
ou=customers
ou=asia
ou=europe
ou=usa
ou=employees
ou=rooms
ou=groups
ou=assets-mgmt
ou=nisgroups
ou=recipes

Individual LDAP records

All entries stored in an LDAP directory have a unique "Distinguished Name" or DN.

* The DN for each LDAP entry is composed of two parts: the Relative Distinguished Name (RDN) and the location within the LDAP directory where the record resides.

The RDN is the portion of your DN that is not related to the directory tree structure. Most items that you'll store in an LDAP directory will have a name, and the name is frequently stored in the cn (Common Name) attribute.

Since nearly everything has a name, most objects you'll store in LDAP will use their cn value as the basis for their RDN.

Information Directory and LDAP Chitchat

The LDAP can enable almost any application, running on almost any computer platform, to obtain information from your LDAP directory. And that directory can be used to store a broad range of data: email address and mail routing information, HR data, public security keys, contact lists, and much more.

What is the directory (information Directory)?

A directory is a way of organizing information so that you can find it easily. It lists Objects .for example, people, books in a library, merchandise in a department store—and gives details about each one.

A directory is a specialized database that stores collections of information about objects. These collections of information are called entries, and they make up the individual building blocks of the directory. A directory might contain entries about, for example, employees, their job titles and salaries.

While a directory is a type of database, it is designed very differently from a relational database. For example,

1- Typical use of a directory involves a relatively small number of data updates, and a potentially very large number of data retrievals. By contrast, typical use of a relational database involves continuous recording of transactions, but retrievals are done relatively infrequently, when, for example, an employee needs to generate a monthly report. In short, a directory is designed to be primarily read-focused, in contrast to a relational database that is primarily write-focused.

2- Directories also differ from relational databases in that they use relatively simple transactions to store and retrieve relatively small units of data—for example, an e-mail address, a telephone number, or a digital portrait. By contrast, a relational database is designed to handle large and diverse transactions using large data items and many operations so LDAP directories are not well suited for storing data where changes are frequent.

3- In a directory, each entry is associated with a unique distinguished name that identifies it across multiple servers and administrative regions. Because they are inherently global, directories can provide users and applications with “location independence,” making identical information transparently available throughout the system.

4- Directory allows you to securely delegate read and modification authority based on your specific needs using ACIs (collectively, an ACL, or Access Control List). For example, your facilities group might be given access to change an employee's location, cube, or office number, but not be allowed to modify entries for any other fields.

Notes:

- Don’t even think of using it as a database back end for your high-volume e-commerce site .

- LDAP is used to access this Directory information by easily and standard way and The directory is known as an LDAP directory.

What is the LDAP?

LDAP (Lightweight Directory Access Protocol) is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. LDAP is especially suited for deployment with Internet-centric because it support TCP/IP, "thin-client" applications.

So LDAP isn't a database at all, but a protocol used to access information stored in an information directory ( LDAP directory).

The LDAP protocol is both cross-platform and standards-based, so applications needn't worry about the type of server hosting the directory.

Note:
Oracle Internet Directory implements (OID) Version 3 of LDAP, which was approved as a proposed Internet Standard by the Internet Engineering Task Force (IETF).where that the OID is directory service implemented as an application on Oracle Database to enable retrieval of information about dispersed users and network resources.

When should you use LDAP to store your data?

If the answer to each of the following questions is Yes, then storing your data in LDAP is a good idea.

1- Would you like your data to be available cross-platform?
2- Do you need to access this data from a number of computers or applications?
3- Do the individual records you're storing change a few times a day or less, on average?
4- Does it make sense to store this type of data in a flat database instead of a relational database? That is, could you effectively store all the data for a given item in a single record?

Reference:
Summarized from an Introduction to LDAP - Michael Donnelly
http://www.ldapman.org/articles/intro_to_ldap.html

Oracle BPEL Process Manager Client API

We did not find direct WebCenter way to access the BPEL process, but we found API “Oracle BPEL Process Manager Client API”.

This API support invoking the BPEL Process programmatically via a Java Code. The API is slightly different depending on whether you are invoking a two-way operation (which has both input and output messages) Synchronous proces or a one-way operation (which just has an input message and returns no result) Asynchronous process .

So this API provides to us two services Post Service and Request Service where its using depends on the type of BPEL process.

Asynchronous BPEL Process:
It provides only initiate operation which has input without output so we use post function to access this Operation.

Synchronous BPEL Process:
It provides only also Process operation which has input and out put so we use request function to access this operation.

**********************************************************************
How we use this API?

1- Setting the configuration for connecting to Oracle BPEL Process Manger.
Hashtable jndi = new Hashtable ();
jndi.put (Context.PROVIDER_URL, "opmn:ormi://10.10.2.141:6003/orabpel");
jndi.put (Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
jndi.put (Context.SECURITY_PRINCIPAL,”oc4jadmin”); // username of Bpel Manager
jndi.put (Context.SECURITY_CREDENTIALS,”welcome1”); //password of BPEL Manager
jndi.put ("dedicated.connection",”true”);

Locator = new Locator (“default”,”welcome1”); // default is the domain Name and welcome1 is the
Password of the domain.

deliveryService = (IDeliveryService) locator.lookupService (IDeliveryService.SERVICE_NAME);

Locator class: used to connect to the domain on the BPEL Process Manager and fetch a list of BPEL processes deployed on that server. In this case, we use the Locator class to return a handle to an IDeliveryService instance.
IDeliveryService Interface: used to invoke/initiate BPEL processes deployed on a BPEL Process Manager.

2- Passing XML messages via Java.
String SchemaInputXML = "" +
" ererer " +
" dgfdggdg " +
" ";
nm = new NormalizedMessage ();
nm.addPart ("payload", SchemaInputXML);


NormalizedMessage class: construct an XML message, construct an input message for request or construct an Output Message for response.

3- Invoking the operation.

Invoking Synchronous Process:
It call process operation which return output message and need input message
So we use the IDeliveryService.request () methods to access this process.

NormalizedMessage res = deliveryService.request ("userBPEL", "process", nm);
// userBPEL is Process Name and process is operation method name and nm is the input message.

Invoking Asynchronous Process:
It call initiate operation which need input message and does not return output so
We use IDEliveryService.post () method to access this process.

deliveryService.post (“userBPEL”,”initiate”, nm);

**********************************************************************
How to retrieve the Result?

Synchronous process:
It is easy to retrieve the result using normalizedMessage object as we saw in the synchronous invoking.

Asynchronous process:
It is not easy to get the result but we can inform the user of the process by making the Process send JMS Message or email (I did not try it ...I just read it) Or using conversation ID to identify the process instance before posting and after that use this ID to identify a specific instance and retrieve status information from it .

String convId = GUIDGenerator.generateGUID();
nm.setProperty(NormalizedMessage.CONVERSATION_ID, convId);
deliveryService.post(processID,operationName, nm);
IInstanceHandle fg = (IInstanceHandle)locator.lookupInstanceByConversationId(convId);

**********************************************************************
What we need to use this API?
oc4jclient.jar, Orabpel-common.jar and Orabpel.jar