Re: Samples for DSML 2.0

[Rob Weltman <robw@worldspot.com>]

  I'm interested in pursuing this approach, but I do have the concern
expressed earlier that I don't see yet how we can generate a valid XML
document with this approach, while not suppressing LDAP's support for an
entry with one or more auxiliary object classes.

  You asked earlier if XML Schema compatibility is required, and I think it is.

Rob
 

Andy Harjanto wrote:

 Yes, I agree with you. One of the requirements says that we would like to be able to express all LDAP operations in DSMLv2.0. Like I said in my previous mail, I didn't try to come up with complete LDAP operations in a few samples. Instead, I was trying to come up with few samples to stimulate discussions.  If we agree on the approach, then we could incrementally add the features to satisfy the requirements. If anybody has concerns on this approach, please let us know soon.  Otherwise, let's move on to the next phase. Thanks!

-----Original Message-----
From: Tony Gullotta [mailto:TGullotta@access360.com]
Sent: Friday, November 03, 2000 8:49 AM
To: Andy Harjanto; Tony Gullotta; James Tauber; dsml@lists.oasis-open.org
Subject: RE: Samples for DSML 2.0
 

OK. I'm not religious about the API approach, but when you brought up SOAP, it seemed to be a better fit. I like an approach that is not dependent on SOAP but could be used with HTTP(S) also. I am a little concerned though that your example approach may not be as flexible as the LDAP protocol is which would then leave an opening for someone to try and come up with yet another approach to DSML because they want more. I'm not an LDAP expert, but do you feel you can cover all the operations sufficiently (complicated search filters, comparisons, modification parameters, authentication options, error codes, etc.)?I know you are probably trying to avoid just implementing rfc 2251 in XML. We've actually done that by extending the DSML 1.0 dtd. Its not the prettiest thing, but it seems to work. We've implemented it over HTTPS.Tony
-----Original Message-----
From: Andy Harjanto [mailto:andyhar@Exchange.Microsoft.com]
Sent: Thursday, November 02, 2000 2:22 PM
To: Tony Gullotta; James Tauber; dsml@lists.oasis-open.org
Subject: RE: Samples for DSML 2.0
 

Thanks Tony!Yes, I thought about your approach too. My concerns with this approach are:       a) this could become chatty,       b) we may have to force to remember state.In more detail:a) Let's assume we want to update, delete, and create objects.  If we were to match each LDAP (or JNDI or ADSI) API to a SOAP call (not necessarily 1-1 mapping), then we may have at least 3 round trips.  For example;  Update("CN=JSmith,OU=....", "sn=JSmith"), Delete("CN=Alice,OU=...) and Create("CN=Bob", "organizationalPerson", ...)b) The client/server must maintain the state for each call.  The client either has to pass the Context in each call, or the client could abstract this in an object oriented way (but underneath the context must be passed to the server). The reasons I propose this approach are:a) Traffic could be kept to minimum for multiple operations. b) Directory could accept the update requests via an XML file (for example bath directory import/synch), or an XML stream received from HTTP requests ( it could be in the form of Raw HTTP request or SOAP Envelopes or other mechanism in the future).c) Stateless.  Once the stream is processed, the server can forget. d) SOAP still plays role in this approach.  I was thinking of one-two SOAP calls which transport the XML document, then it receives back status.
   for example
       SendUpdategrams( [in] string URL, [in] string XML, [out] string Status, [in, optional] string UserName, [in,optional] Password);       SendUpdategrams("http://mySoapSrv", "<?xml version="1.0"?> ...", &Status) Thanks!

-----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.0
 

I'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 attribute

Examples:
<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