8 Replies Latest reply on Oct 27, 2008 6:13 AM by bdaw

    JBoss Identity Design Preview

    bdaw

      I prepared a prototype design with simple implementation containing
      Hibernate and LDAP data stores. There is also a simple testcase that runs
      against mixed (DB+LDAP) scenario.

      Main concepts behind the architecture are described here:

      http://docs.google.com/View?docid=dfzsjmg9_18dmn56sdk

      The code is available here:
      http://anonsvn.jboss.org/repos/jbossidentity/tags/PREVIEW-23-10-2008/

      Three main places to look at are:

      1) The API:

      http://anonsvn.jboss.org/repos/jbossidentity/tags/PREVIEW-23-10-2008/identity-api/src/main/java/org/jboss/identity/api/

      2) The SPI

      http://anonsvn.jboss.org/repos/jbossidentity/tags/PREVIEW-23-10-2008/identity-spi/src/main/java/org/jboss/identity/spi/

      3) Test case for two sample organization structures - it is the showcase
      of the API usage.

      http://anonsvn.jboss.org/repos/jbossidentity/tags/PREVIEW-23-10-2008/identity-impl/src/test/java/org/jboss/identity/impl/api/OrganizationTest.java

      Javadoc can be generated from the maven project by doing:
      # mvn javadoc:javadoc
      in the root of the build

      Disclaimer: This is prototype implementation so code is not
      pretty/efficient and many things are still missing. One of those things
      is XML configuration so all the services in test cases are bootstrapped
      in a rather messy way. Few things are still missing in the design like the concept of policies to list just one of them.

      At the moment implementation contains Hibernate and LDAP identity
      stores. The API should be 90% complete and this is the main place I
      would like you all to look at and share your impression. I'm obviously
      biased with portal use cases so take a look and tell me what is missing ;)

        • 1. Re: JBoss Identity Design Preview
          jeff.yuchang

          Hi,

          One thought for the API:

          Collection findAssociatedIdentities(Group group,
          boolean inherited,
          int offset, int limit,
          boolean orderedByName,
          boolean ascending) throws IdentityException;

          For this API, can we wrap the offset, limit, orderedByName, ascending into a parameter Object, so that it other project might be easier to extend this class meet some other projects needs.

          I also noticed that the other methods, such as findAssociatedGroups(....).

          Thoughts?

          • 2. Re: JBoss Identity Design Preview
            jeff.yuchang

            Firstly, I think the API and SPI is very good. It is very flexible. ;-).

            However, I had a thought when I saw the OrganizationTest class.

             session.getRelationshipManager().associateGroups(rhOrg, jbossDivision);
             session.getRelationshipManager().associateGroups(rhOrg, rhelDivision);
            


            I was thinking it would be easier to see the relationship if we do as following in the API level.

             rhOrg.addGroup(jbossDivision);
             rhOrg.addGroup(rhelDivision);
            


            I know the latter one might add complexity in the implementation. But it seems to me more clearer from the API perspective. I don't know which way to better to go. Just bring about this thought, see what you guys are thinking of this.

            Thanks
            Jeff

            • 3. Re: JBoss Identity Design Preview
              bdaw

              I was thinking about using something similar to JNDI SearchControl mechanism. Then offset/limit and orderByName/ascending could be placed in two separate objects passed in an array.

              Collection<Identity> findAssociatedIdentities(Group group, boolean inherited) throws IdentityException;
              
              Collection<Identity> findAssociatedIdentities(Group group, boolean inherited, IdentitySearchControl[] isc) throws IdentityException;
              


              One benefit is to let add other parameters in the future, the other is easy discovery of supported features (is specific control supported).

              What kind of extensions do you have in mind btw?


              "jeff.yuchang" wrote:
              Hi,

              One thought for the API:

              Collection<Identity> findAssociatedIdentities(Group group,
              boolean inherited,
              int offset, int limit,
              boolean orderedByName,
              boolean ascending) throws IdentityException;

              For this API, can we wrap the offset, limit, orderedByName, ascending into a parameter Object, so that it other project might be easier to extend this class meet some other projects needs.

              I also noticed that the other methods, such as findAssociatedGroups(....).

              Thoughts?


              • 4. Re: JBoss Identity Design Preview
                jeff.yuchang

                 

                "bdaw" wrote:
                I was thinking about using something similar to JNDI SearchControl mechanism. Then offset/limit and orderByName/ascending could be placed in two separate objects passed in an array.

                Collection<Identity> findAssociatedIdentities(Group group, boolean inherited) throws IdentityException;
                
                Collection<Identity> findAssociatedIdentities(Group group, boolean inherited, IdentitySearchControl[] isc) throws IdentityException;
                


                One benefit is to let add other parameters in the future, the other is easy discovery of supported features (is specific control supported).

                What kind of extensions do you have in mind btw?



                when I referred to extension, I was thinking about we might want to oder by some other attributes. not just name.

                The above approach seems better to me, as you said, it would be easy for us to discover the supported features then 'Parameter Object' way.

                -Jeff

                • 5. Re: JBoss Identity Design Preview
                  bdaw

                  This is something I was thinking about from the beginning. It can be done by keeping reference to the session in identity model classes. The main problem I see is the mix of two approaches:

                  - most management methods in the model objects (Identity/Group/Role)
                  - all management methods in manager objects connected to the session (the only reason to have 4 separate managers is to not end up with 100 methods in IdentitySession)

                  Now to mix - some methods in Identity/Group/Role and some in managers

                  Most of the search/find/resolve methods need to remain in managers anyway. Now if you think about the assignments you can place methods you mentioned in the Identity/Group but those operating on the collections will need to remain in the managers:

                  public void associateGroups(Collection<Group> parents, Collection<Group> members) throws IdentityException


                  Also you can have

                  group.findAssociatedGroups(GroupType groupType, boolean parent, boolean inherited, ... )


                  but then you still need to keep few of findXXX methods in the manager as they don't belong to one model object... What I'm afraid of is the confusion of users where to look for certain methods. That's why I decided to put all all methods in the managers.

                  I'm not totally against the approach you suggested but I'm simply not sure if it can be done without making API a bit messy. We can discuss about possible solutions. One idea would be to simply duplicate some methods to have them in both places.




                  "jeff.yuchang" wrote:
                  Firstly, I think the API and SPI is very good. It is very flexible. ;-).

                  However, I had a thought when I saw the OrganizationTest class.
                   session.getRelationshipManager().associateGroups(rhOrg, jbossDivision);
                   session.getRelationshipManager().associateGroups(rhOrg, rhelDivision);
                  


                  I was thinking it would be easier to see the relationship if we do as following in the API level.

                   rhOrg.addGroup(jbossDivision);
                   rhOrg.addGroup(rhelDivision);
                  


                  I know the latter one might add complexity in the implementation. But it seems to me more clearer from the API perspective. I don't know which way to better to go. Just bring about this thought, see what you guys are thinking of this.

                  Thanks
                  Jeff


                  • 6. Re: JBoss Identity Design Preview
                    bdaw

                    Makes sense. I'll refactor the API/SPI accordingly later then. At the moment I want to add configuration and bootstrapping mechanism so the framework can be tried out easier. It should also enable us to improve testsuite and let apply proper refactorings easier.

                    Lets collect all the ideas now :)

                    "jeff.yuchang" wrote:
                    "bdaw" wrote:

                    ....


                    when I referred to extension, I was thinking about we might want to oder by some other attributes. not just name.

                    The above approach seems better to me, as you said, it would be easy for us to discover the supported features then 'Parameter Object' way.

                    -Jeff


                    • 7. Re: JBoss Identity Design Preview
                      jeff.yuchang

                       

                      "bdaw" wrote:
                      This is something I was thinking about from the beginning. It can be done by keeping reference to the session in identity model classes. The main problem I see is the mix of two approaches:

                      - most management methods in the model objects (Identity/Group/Role)
                      - all management methods in manager objects connected to the session (the only reason to have 4 separate managers is to not end up with 100 methods in IdentitySession)

                      Now to mix - some methods in Identity/Group/Role and some in managers

                      Most of the search/find/resolve methods need to remain in managers anyway. Now if you think about the assignments you can place methods you mentioned in the Identity/Group but those operating on the collections will need to remain in the managers:

                      public void associateGroups(Collection<Group> parents, Collection<Group> members) throws IdentityException


                      Also you can have

                      group.findAssociatedGroups(GroupType groupType, boolean parent, boolean inherited, ... )


                      but then you still need to keep few of findXXX methods in the manager as they don't belong to one model object... What I'm afraid of is the confusion of users where to look for certain methods. That's why I decided to put all all methods in the managers.



                      Exactly the issue that I am worrying about with my suggestion, thats what I mean complexity on the implementation, and say 'I just bring about this issue'. ;-(. We may keep it as it is now, cause I haven't come up a easy way to accomplish this change. Not sure others will have a better way?

                      -Jeff

                      • 8. Re: JBoss Identity Design Preview
                        bdaw

                        I created a separate topic for this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144427

                        "jeff.yuchang" wrote:
                        "bdaw" wrote:
                        ....


                        Exactly the issue that I am worrying about with my suggestion, thats what I mean complexity on the implementation, and say 'I just bring about this issue'. ;-(. We may keep it as it is now, cause I haven't come up a easy way to accomplish this change. Not sure others will have a better way?

                        -Jeff