[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Samples for DSML 2.0
Does LDIF have the support for delete? How about searching for specific
entries? I guess I was hoping the DSML give me the features of LDAP, but
using XML and HTTP(S) instead. If that's not the charter, that's ok, but
I'd need to look into something other than DSML for my needs. DSML 1.0
is good for laying out the data, but I need something to make the
requests for the data.
Tony
-----Original Message-----
From: mark@mjwilcox.com [mailto:mark@mjwilcox.com]
Sent: Monday, November 06, 2000 8:17 PM
To: dsml@lists.oasis-open.org
Subject: RE: Samples for DSML 2.0
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC