RE: Samples for DSML 2.0

[mark@mjwilcox.com]

Worrying about error codes in an XML document? I think that
DSML should fit more closely to being the XML equiv of LDIF, that
is the ability to move directory data around outside of the LDAP
protocol.

If I get an DSML document, I should be expected to parse and do
something with it. If it's an modification, then I should be able to
handle the errors.

I know I've been lurking, but did I miss something? :)

Mark



On 3 Nov 00, at 8:49, Tony Gullotta wrote:

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


Mark Wilcox
mark@mjwilcox.com
Got LDAP?