| [higgins-dev] Fwd: Re: Using JNDI as Higgins data model |
|
FYI, this is what I got back from Vincent.
I hadn't thought about using JNDI References as a way to represent relationships.
If we steer more towards an RDF model, I'd have to re-think the pros/cons of using JNDI as an SPI/API >>> Vincent Ryan <Vincent.Ryan@xxxxxxx> 4/14/06 12:24 PM >>> Hello Jim, First of all sorry for not getting back to you sooner. I've taken a look at the Higgins architecture and, like you, I can see JNDI as a fairly natural fit here. In fact, the similarity is quite remarkable ;-) I also took a look at your binding to LDAP and that looks like a worthy approach. So to answer your original questions: 1) Yes I believe JNDI can be used to meet the Higgins data model goals. JNDI could be used in Higgins in either of two ways: a) Above: Higgins declares JNDI as its API and specifies a number of Higgins-specific classes and a binding to JNDI. Higgins Contexts and DigitalSubjects are exposed directly as JNDI Contexts. Existing JNDI Context operations such as list and getAttributes can be applied to these Higgins objects. Relationships between Higgins objects could be modeled as JNDI References or as Attributes. For example, env.put(Context.PROVIDER_URL, "ldap:///cn=vinnie,dc=sun,dc=com"); DirContext higgins = new InitialDirContext(env); DirContext buddies = (DirContext) higgins.lookup("context=MyBuddiesList"); NamingEnumeration buddiesList = buddies.list(); Attributes august = buddies.getAttributes("subject=August West"); DigitalSubjectType augustType = (DigitalSubjectType) august.get(DigitalSubjectAttributes.TYPE).get(); DigitalSubjectRelationship augustRelationship = (DigitalSubjectRelationship) august.get(DigitalSubjectAttributes.RELATIONSHIP).get(); ... b) Below: Higgins specifies its own API. Existing JNDI service providers could then be enhanced by means of Higgins-specific object factories to return the appropriate Higgins objects. Or alternatively, new Higgins-specific service providers could be developed. You are probably best positioned to gauge the most likely outcome. If specific issues with using JNDI are identified as impediments then perhaps we could address those in modifications to subsequent releases of JNDI API. 2) No I don't believe JNDI is too LDAP-centric. In fact, we introduced the javax.naming.ldap package to address elements of JNDI which were not sufficient for developers of advanced LDAP applications. JNDI is designed to support a wide variety of naming systems and data stores so it is structured into three packages, ordered in increasing complexity: javax.naming javax.naming.directory javax.naming.ldap The idea is that developers should choose the package that best fits the capabilities of their target naming system. This allows developers using a basic system to ignore the complexities offered by JNDI for use in more sophisticated naming systems. A wide variety of service providers have already been developed for JNDI, including ones from Novell: http://java.sun.com/products/jndi/serviceproviders.html There may be others. These are just the ones that authors wished to make public. Let me know if I can help further. I'll be able to provide a faster response from now on ;-) Bye for now. Jim Sermersheim wrote: > Hi Vincent, > > In your analysis, it may help to look at the model I proposed at > http://spwiki.editme.com/DataModelProposalAlternativeOne (this is an > alternate to the one at http://spwiki.editme.com/DataModelProposal) > > I divorced it from JNDI to keep the discussion focused on data model > rather than interfaces, though JNDI is mentioned a few times as a > reference example of an interface solution. > > Most other things that come to my mind when I think about using a > JNDI/Directory model have to do with schema. I've never been all that > excited about the way schema is done in directories. In your experience > with JNDI Service Providers (aside from LDAP), do people implement > schema support? If so, to what extent? > > Thanks again, > > Jim |