Virtual truth (chapter 1)

by Deborah Volk on April 13th, 2009

I saw a note by Mark Wilcox on his blog regarding Oracle Virtual Directory (OVD) and SharePoint. Mark's note details how among other things OVD could be used to provide a unified LDAP-based view of users in multiple Active Directory forests not bound by a trust mechanism. If you've ever encountered SharePoint and multiple forests, the OVD solution is priceless (ok, they might charge a little per processor). This made me think about other interesting use cases for using a virtual directory but before going to outer edges of the galaxy, I'll cover the basic scenario first.

We'll use our favorite El Caro Corp as a hypothetical guinea pig for our Gedankenexperiment. El Caro has grown from a small business to a large corporation and as a result of this wild (some might say unrepentant) growth, it has a number of enterprise applications. El Caro's go-to market strategy is based on partners who resell El Caro's products. Thus, El Caro has a CRM app where it tracks partners and related sales opportunities with product SKUs, a Master Data Management (MDM) system that contains all product SKUs, corresponding product names/descriptions and configurations of these products that El Caro offers to the market and finally a Sales Compensation (SC) tool that works out the commission due to the partner based on a sale of a product SKU by the partner.

These 3 apps all store their data in their own repositories - CRM in its own database, MDM in an LDAP-compliant directory and SC in one humongous Excel spreadsheet (don't laugh, this isn't far from reality). The JPY 6384000 (roughly $64,000 at the current JPY/USD conversion rate) question is this: how can El Caro management achieve a single view of their partner-sales-product universe? The ultimate goal is to have a dashboard showing sales opportunities for a particular territory with each opportunity displaying partner name, product name, opportunity dollar amount, commission due to partner and the estimated profit margin for El Caro on the sale.

To achieve a single view of data across 3 different repositories, two things have to happen. First, relationships between records in different sources must be identified. Second, somehow the records must be "brought together". (I am using the term record to mean a set of data even though some sources such as directories should be more appropriately labeled as containing entries rather than records). We're concerned with the 2nd step and here we have two major options - to copy the records from all 3 sources into one central repository or leave the records where they are and provide a view onto them. Since virtualization space is white-hot, the 2nd option is referred to as (you guessed it) a virtualized view.
In the first option our central store (database, directory, Excel, ...) will contain copies of records and perform the "unification" step. This is equivalent to exporting the data from 3 sources, massaging it, importing the data into our store, glueing the records into one and finally achieving a single record/view of partner-sales-product space. The problem with this approach is that we've just created a chunk of work that serves no business purpose...other than moving data. We've got the overhead of maintaining the central data service (labor, hardware, utilization, etc) and the data in our central store duplicates the data already available elsewhere. On top of this, if someone spots a data issue (what do you mean they didn't charge them for 16 extra CPUs?!), it'll be your fault. After all, the data is in your store.

The other option is to provide the unified view without copying or moving the records to a central location. In this option, records from 3 sources are "joined" together into one view much the same way this is done in a database. (Database views do not contain copies of records from underlying tables that make up the view). This is the purpose that virtual directories were born with. Viewed from this perspective, a virtual directory is a very smart, data-oriented, aggregation-capable multi-protocol proxy. The virtual directory may accept a request via HTTP or LDAP formatted as plaintext or XML (e.g. SOAP), transform the request into multiple requests with (potentially exotic) format/protocols palatable to the downstream source(s), apply routing rules to the request, send them back to the sources of data, retrieve the results, perform aggregation on results and finally send the results back to the requester. This sequence of events is very basic, virtual directories are capable of a lot more but the central premise of protocol translation, routing and aggregation of data holds true throughout.

In chapter 2 of the Virtual Truth novel, we'll look at interesting use cases that we at Identigral have encountered in the field while working with Oracle Virtual Directory.

Homework: compare and contrast portals, mashups and virtual directories.

Bonus: Everything You Wanted to Know About SharePoint User Mgmt But Were Afraid To Ask


Posted in Oracle Virtual Directory, Directory Services    Tagged with ovd


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)