[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Samples for DSML 2.0
-----Original Message-----
From: Tony Gullotta [mailto:TGullotta@access360.com]
Sent: Tuesday, October 31, 2000 9:55 AM
To: Andy Harjanto; James Tauber; dsml@lists.oasis-open.org
Subject: RE: Samples for DSML 2.0I'm a little confused about the how you're proposing LDAP operations in an XML document and then also using SOAP. Why would we not just use the data model for repesenting the data returned from the operations and use a JNDI like SOAP api for executing the operations. Since SOAP is an object oriented RPC mechanism, it would seem to make sense to leverage a well acceptected API like JNDI to implement these operations instead of making something up from scratch. Of course, I wouldn't suggest mimicking JNDI exactly since there is some stuff that's probably not needed, but at least the approach is sound.Tony Gullotta
Lead System Architect
Access360
Phone (949) 450-6400
Fax (949) 450-6500
www.access360.com
access360
A Better Way to Manage Access Rights
-----Original Message-----
From: Andy Harjanto [mailto:andyhar@Exchange.Microsoft.com]
Sent: Monday, October 30, 2000 6:01 PM
To: James Tauber; dsml@lists.oasis-open.org
Subject: Samples for DSML 2.0
James sent out few proposals on requirements, DSML operations, and Directory draft data model a month ago. Since then, we have made a little progress. I would like to propose a few samples to stimulate the discussion again. IMHO, discussing real samples allows us to make an incremental progress while making sure we're on the same page.
In simple term; this is what my understanding so far. Others are welcomed to correct me.
1) Directory data model which allows easy XPATH navigations and queries. The model is not neccessarily backward compatible with DSML version 1.0.2) Representing LDAP Operations in an XML document.
Note: 1) and 2) may be combined latter in a document, but let's talk this separately for now.
We agreed to use SOAP as the transport (and possible method executions), but let's side aside this for moment, and concentrate on the XML model.
Proposed XML documents.
The samples, by all means, are not intended to cover all the possiblities, rather, they are just used illustrate important points.1) Represent Directory data model in XML.
<...omit the XML namespace for moment, I would like to focus on the format>.
The goal is to be able to produce an XML document which represents directory data model but it could easily be accessed via XPATH.
General Format:
<objectName-value someattribute="..." ... >
<childName-value someattribute="..." ...>
</childName-value>
<childName-value someattribute="..." ...>
<grandchildName-value someattribute="...">
<...>
</...>
</grandchildName-value>
...
</childName-value>
...
</objectName-value>
* XML element maps to objectName. Note: XML element can not contain space, where LDAP object Name can.
* XML attribute maps to object's attributeExamples:
<MyCompany rdn="OU=MyCompany" dn="..." description="..." class="..." >
<SalesAndMarketing rdn="OU=SalesAndMarketing" homePage="..." class="..." >
<Consulting rdn="CN=Consulting" >
</Consulting>
</SalesAndMarketing>
<ResearchAndDevelopment rdn="OU=ResearchAndDevelopment" description="...">
<ProductX rdn="CN=ProductX" startDate="01/02/1998">
</ProductX>
<ProductY rdn="CN=ProductX" startDate="04/02/1999">
</ProductY>
</ResearchAndDevelopment>
</MyCompany>
Example Queries:
a) Get all objects in R&D
MyCompany/ResearchAndDevelopment//b) Get all products under development since 1999
MyCompany/ResearchAndDevelopment//[@startDate >= "01/01/1999"]c) Get ProductX. MyCompany/ResearchAndDevelopment/ProductX
d) Enumerate children in SalesAndMarketing. MyCompany/SalesAndMarketing/*
etc, etc.
Notes:
* In a high unlikely event, what if you don't have permission to view parent's object, but we could view child's object? How do we represent this ?
2) LDAP Operations in XML format.
My proposal is to come up with words that are common to data access terminology, rather than using LDAP jargons. The samples only cover common operations.General XML operation format
<an_operation path=”…”>
</an_operation>
Path value identifies the targeted object where the operation will be applied. Potential formats supported are:
· Distinguished name. For example, “dn:OU=Developers,DC=example,DC=com”
· GUID. For example, “guid:a7fc61cc4661924e98f5316ff060baeb”The idea is to create an extensible scheme, where each vendors might have a different way to identify an object in the directory. At the minimum, each vendor must support dn path; e.g "dn:..."
Updates
<update path="…" >
<attribute_name>…</attribute_name >
<attribute_name>…</attribute_name >
</update>Create
<create path="…" class="…" name="…">
<attribute_name>…</attribute_name>
<attribute_name>…</attribute_name>
</create>Delete
<delete path="…">
</delete>Move
<move path="…">
<to path="…" />
</move>Rename ( we could have combined with Move, but IMHHO, people understand rename clearly)
<rename path="…">
<name>…</name>
</rename>LDAP Operations Examples:
<update path="guid:a7fc61cc4661924e98f5316ff060baeb" >
<sn>Gibbs</sn>
<telephoneNumber>(425)777 7777</telephoneNumber>
</update>
<create path="dn:CN=Samuel Heinz,OU=Marketing,O=Example, C=US" class="user" name="Samuel Heinz">
<samAccountName>sammisas</samAccountName>
<userPrincipalName>sam@example.com</userPrincipalName>
</create>
<move path="ad:fabrikam.nttest.microsoft.com/Marketing/Bob Adams">
<to path="ad:fabrikam.nttest.microsoft.com" />
</move>
<move path="dn:CN=Bob Jones,OU=Marketing,O=Example, C=US">
<to path="guid:a7fc61cc4661924e98f5316ff060baeb" />
</move>Comments ?
Thanks
andy
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC