What would be the easiest way to add a new field to a list of potential fields on an existing ldap schema?
How would this affect existing records?
The field would be added at the deepest level of the dn (each user account).
Typically you can extend the schema of the LDAP server. Specific details depend on the underlying service providing the LDAP. (Active Directory is slightly different than eDirectory, and slightly different than in OpenLDAP or SunOne).
However, common to all those possible LDAP servers is the concept of an Auxiliary Class.
The base schema that comes with the server usually has Structural classes which are ones you can really use for objects. Another is Abstract classes, which are really just placeholders, so that you can have other classes (Say a structural class) inherit from it. Perhaps two Structural classes might inherit from the same abstract class, thus making definitions easier and cleaner.
Finally we come to Auxiliary classes which are probably the most useful. These classes cannot stand on their own, but you can add the class name to the Object Class (objectClass) attribute list, and then the additional attributes defined in the Aux class can be used.
This is the safest, least painful way to extend an LDAP Schema. It does not touch Base schema, nor any of the standard shipping classes. Rather, you have a completely standalone class that you can add to any object you would like, and it is easy to modify.
Related
Assuming everyone has the rights to do the CRUD operations (everyone is an admin type user). I have displayed CRUD operations the user can perform in the Domain diagram however, it's become quite messy. I am curious if it's acceptable to do the alternative approach shown in the images below instead since the multiplicative relationships remain the same for each action (create,edit,delete)
Seperated CRUD
Alternative approach? (create, edit, delete)
In short
If it becomes messy, it probably lacks of separation of concerns, or represents associations that are not really needed.
More explanations
Are the associations needed?
An association between User and Xxx implies a semantic relationship between the two classes. This means that instances of the classes are linked and not just for the time of an operations. So x would be able to find the User(s) that updated it, and u would know the Xxx instances that it updated. This kind of association can make sense if you want some audit trails, but this seems not to be your purpose here.
In other words, the fact that a User may perform some operations that CRUD instances of Xxx is not sufficient for justifying an association.
If they are needed, do they represent what you think?
Now it appears that your associations are can ..., i.e. some kind of authorisation scheme. Your diagram tells that each user would need to know in advance all the Xxx that it could update. This is a heavy burden. It would also imply that a user needs to know all the Xxx it can create; before they are even created? This looks somewhat inconsistent.
Modeling an authorisation scheme
If you'd wand to design an authorisation system, you'd probably not link users directly to the object, but use some intermediary mechanisms:
To express that a user can create new projects, you'd probably have some authorisation object that tells the caracteristics of projects that can be created.
To express that a user can edit, update, delete projcts, you could have a direct association like you envisaged, if some admin would maintain such authorisations.
But probably you would have some authorisation object that would tell what a user can do (e.g. a user "role"/"profile") and what category of projects.
Equally probable is that there are some rules that govern CRUD authorisations (e.g. a user having the role "edit" can edit the project he/she is assigned to, but not the others). Making use of such rules instead of explicitly designing (redundant) authorisations could then save you a lot of unnecessary extra associations (and extra constraints to keep the authorisations consistent with the rules).
Separation of concerns
And to keep things continue to be messy, you should consider:
having a separate diagram in your model for the authorisation concept
use some common CRUD interface: the users would then be associated with the CRUD interface without having to replicate everything for every possible class.
The main issue with both of your class models is a confusion between the type/instance levels. Your "can create/edit/delete" authorization relationships do not hold between a specific user and a specific object (an instance of Company, Project or Ticket), but rather between a specific user and a sepcific object type (Company, Project or Ticket), so it's not an ordinary association between two ordinary object types.
If you want to describe/define such authorization relationships with a class model, you would need to define a meta-class like ObjectType and express that your object types (Company, Project or Ticket) are instances of it.
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
I have several schemas that inherit one or more elements from a collection of 'common' schemas. In this particular instance, I'm importing one of these schemas to make use of a single complex type defined in it.
When I generate the java objects from the schema, I get my schema types, and the element I referenced as expected, however I also get objects generated for the 30+ other types from the common schema.
I want to use the common schema, because I want to rely on automated builds for updating my schema when the common schema changes, but I do not want the extra java classes generated.
Suggestions ?
There's no out of the box approach to achieve what you want. The reason I am offering an opinion here is rather to point out (maybe for others) some issues one needs to take into account no matter which route ones go.
The 'extra' label is not always straightforward. Substitution group members are interesting. In Java, think about a class (A) using an interface (I), and a class (B:I) implementing (I). Some may say there's no dependency between A and B, while others would require B in the distribution. If you replace (I) with a concrete class, things become even less clear - consider that the substitution group head doesn't need to be abstract; or if the type of the substitution group head is anyType (Object in Java).
More so, if the XML processing was designed to accommodate xsi:type then it is even harder to tell (by looking at the schema) what is expected to work where.
Tools such as QTAssistant (I am associated with it) have a default setting that will pull in all strict dependencies (A and I above); and either ALL that might work (B above), or nothing else. Anything in between, the user needs to manually define what goes in the release. This is called automatic XSD refactoring and could be used easily in your scenario.
lets say i have the following classes:
customer, applicant, agency, partner
i need to work with databases and use mappers to map the objects to the database. my question is, can i generalize these classes with the class person and just implement a mapper for this class? basically it would look like this:
instead of this:
the mapper classes use orm to save and edit fields in the database, i use them because the application i am doing has to be developed further in the future.
If each of the classes (Partner, Applicant, etc.) has different attributes, you can't have only one mapper for all of the classes (well, you can, but then you would have to use meta-programming to retrieve information from the classes lower down the hierarchy). The solution also depends on how and who manages your database: do you have control over how it is designed or is it something that you cannot change? in the second case I would definitely use a mapper per class to allow full decoupling between DB and app. In the first case, you could use some kind of mapping hierarchy. And also, it depends on what language/frameworks you are using.
Good Luck!
I'm trying to create an LDAP based address book. For each recipient/user in it, I will need to store information about their contact points. Information will include:
contact type - phone/email/fax/pager/etc.
label - grandma's attic, work, home, etc.
address - actual phone number/email/etc.
and few other properties
I've figured out by now that there is nothing out of box that can handle this, but that I can create my own ContactPoint ObjectClass, make it a structural class and have it be a child of inetOrgPerson. but I still can't seem to wrap my head around how this all comes together. For example, how would I query for a person and his/her contact points?
LDAP is designed to be extensible and defining new schema elements is often required. When clients cannot find an attribute with the syntax and name they desire, they should define a new attribute with an appropriate object class. Designers should:
know the existing schema elements
use existing schema elements where possible
not use vendor-specific attributes, this results in poor quality, brittle systems. Use only attributes and object classes from schemas defined by the standards body (unless of course you roll your own)
inherit from an existing object class instead of defining a new object class
use matching rules (from the attribute type definition) for comparisons and not use language equality constructs.
avoid the extensibleObject unless absolutely required. Using extensibleObject is a last resort option and is similar to using an untyped programming language and results in poor quality, brittle, difficult to maintain systems
For more information, please see "LDAP: Programming Practices"
Make it an inetOrgPerson and an extensibleObject. Then you can use any attribute from anywhere in it. I would steer well clear of defining your own object classes.