[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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