{"id":969,"date":"2008-04-08T00:00:00","date_gmt":"2008-04-08T00:00:00","guid":{"rendered":"\/?p=969"},"modified":"2008-04-27T12:53:02","modified_gmt":"2008-04-27T20:53:02","slug":"more-on-the-second-generation-of-metadirectory","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=969","title":{"rendered":"More on the second generation of metadirectory"},"content":{"rendered":"

Oracle\u2019s Clayton Donley <\/a>has joined the Metadirectory discussion and maybe his participation will help clarify things.<\/p>\n

He writes:<\/p>\n

I was reading this posting<\/a> from my friend and colleague, Phil Hunt, in which he talks about the ongoing discussion between Dave Kearns<\/a> and Kim Cameron<\/a> about the death of meta-directories.<\/p>\n

Not only is he correct in pointing out that Kim\u2019s definition of Meta 2.0 is exactly what virtual directory has been since 1.0, but it\u2019s interesting to see that some virtual directory vendors continue to push something<\/em> that looks very much like meta-directory 1.0.<\/p><\/blockquote>\n

Before we go further, I want to peak at how Clayton\u2019s virtual directory<\/a> works:<\/p>\n

\u2026 If the request satisfies the in-bound security requirements, the next step is to invoke any global level mappings and plug-ins. Mapping and plug-ins have the ability modify the operation such as changing the name or value of attributes. The next step after global-plug-ins is to determine which adapter(s) can handle the request. This determination is made based on the information provided in the operation.<\/p>\n

The primary information used is the DN of the operation – the search base in the search or the DN of the entry in an all other LDAP operations like a bind or add. OVD will look at the DN and determine which adapters could potentially support an operation for that DN. This is possible because each adapter in its configuration tells what LDAP namespace it\u2019s responsible for.<\/p>\n

In the case where multiple adapters can support the incoming DN namespace (for example a search who\u2019s base is the root of the directory namespace such as dc=oracle,dc=com), then OVD will perform the operation on each adapter. The order of precedence is configurable based on priority, attributes or supported LDAP search filters.<\/p><\/blockquote>\n

Pretty cool. But let\u2019s do a historical reality check. The first metadirectory, which shipped twelve years ago, included the ability to do real-time queries that were dispatched to multiple LDAP systems depending on the query (and to several at once). The metadirectory provided the \u201cglue\u201d to know which directory service agents could answer which queries. The system performed the assembly of results across originating directory service agents – in other words mutliple LDAP services produced by multiple vendors.<\/p>\n

And guess what? The distributed queries were accessed as part of \u201cthe metaverse\u201d<\/strong>. The metaverse was in no way limited to \u201ca local store\u201d.<\/p>\n

The metaverse was the joined information field comprising all the objects in the metadirectory. Only the smallest set of \u201ccore\u201d attributes was stored in the local database or synchronized throughout the system. This set of attributes composed the \u201cobject root\u201d – the things that MUST BE THE SAME<\/em> in each of the applications and stores in a management continent. There actually aren\u2019t that many of them. For example, in normal circumstances, my surname<\/strong> should be the same in all the systems within my enterprise. So it makes sense to synchronize surname between systems so that it actually stays the same over time.<\/p>\n

As metadriectories started to compete in the marketplace, the problem of provisioning and managing core attributes came to predominate over that of connecting to application specific ones. Basically, I think it was just early. That doesn\u2019t mean one should counterpose metadirectory and virtual directory, or congratulate oneself too much for \u201downing\u201d distributed query. The problem of distributed information is complex and needs multiple tools – even the dreaded \u201ccaching\u201d.<\/p>\n

Let me return to what I said would be the focus of \u201csecond generation metadirectory\u201d:<\/p>\n

Providing the framework by which next-generation applications can become part of the distributed data infrastructure. This includes publishing and subscription. But that isn\u2019t enough. Other applications need ways to find it, name it, and so on.<\/p><\/blockquote>\n

If Clayton and Phil think virtual directories already do this, I can see that I wasn\u2019t clear enough. So here are a few precisions:<\/p>\n