On Wed, Apr 22, 2015 at 10:48 PM, Steve Moyer <[email protected]> wrote:
> I'm not sure the igloo project's implementation is better or worse than > escimo ... it's compliant to the SCIM specification a few versions > back. The current version has design flaws but is working well for us. > I'll try to describe the differences but since the eSCIMo code wasn't > functional when we forked, it's probably better to have Kiran describe > what he ended up with. I've added links to the two files we started > with at the end of the e-mail just to show that when we had the > discussion that led to us agreeing to fork the project, neither of us > had much working code and so these discussions were more philosophical > and theoretical in nature ... if we'd both had more done I'm sure it > would have been much more obvious that a merge was or was not possible. > > My understanding was that Kiran was building a mapping framework with > the that provided a SCIM "Service Provider" (server) that you could plug > different persistence systems into and then map SCIM resource attributes > into the persistence system. I'll let Kiran expand on his design but > structurally, we ended up keeping wink in the configuration (one of the > architectural mistakes I made). In the same way Kiran didn't look at > our repository, I haven't kept up with what he's done either, so please > let him describe his system. Does the the five minute tutorial exist > (http://directory.apache.org/escimo/five-minutes-tutorial.html)? I'd > like an overview too! > there is no doc (yet!) but the I will explain the design here in a few words. There are no concrete resource specific types in eSCIMo server, just a bunch of attributes encapsulated in a single top level class called Resource. It can contain anything that a user wants. Each Resource instance is backed by a mapper config where user can define what attributes the resource contains (and also means to extract an attribute value). This mapper based config is also intended for making it easy to plug other resource stores. (RDBMS is the next target, currently LDAP is the default user store) There is a maven plugin for generating java code from JSON resource schema for allowing clients to work with specific types, say User or Group etc. This plugin works with either online or offline schema files. And this has been an excellent tool for writing unit tests. And server validates received data based on the rules specified in resource schema in association with the mapping file and the associated entity present in the backend. I didn't want to use generated code in the server (like JAXB), that is not dynamic configuration friendly. In the end the goal is to write a general purpose SCIM server that can be either embeddable or deployable and also provide a maven plugin to write clients that are aware of resource types. > I can provide a bit more detail on Igloo but bear in mind that I believe > it needs rework too. We required the intermediate system to do much > more than map attributes between JSON and persistence due to our > business requirements. We accomplished this by creating JAXB annotated > classes for each type of SCIM resource and letting JAX-RS unmarshall the > received JSON into an associated Java object. The plan was also to use > BVF annotations to allow validation of the JSON contents while the > validity of the JSON structure has already proven (through successful > unmarshalling) that the document's schema was valid. In order to make > igloo more of a tool-kit, it's broken into modules that are individually > useful. At least initially, the Penn State business logic won't be > included since that's the part that isn't SCIM compliant ... you can > still build a fully functional system from the igloo components and > we'll not only offer a demo server but will host one for the SCIM > community on PSU servers. > > We'll also be building a "SCIM Studio" with various tools ... I had > previously promised the SCIM team I'd publish a "filter builder" based > on the lexer-parser in our system but we'll also provide linting, > customization and more. > > In any case, as it's cleaned up and has the architectural repairs done, > I'll be checking it into Github (for now). > > Now for a bit of good news ... I think we can help with the Kerby client > code. I'll have to dig around with some of the POC work I did using the > Apache DS Kerberos protocol code but I think that's a pretty exciting > project! > > None of this answers the Colm's question related to making these > projects live with each other (married or not) under one roof. I'll > leave that to your team! > > All the best, > > Steve > > P.S. Here are the links to the two files we started with: > > > http://svn.apache.org/viewvc/directory/escimo/trunk/server/src/main/java/org/apache/directory/scim/UserService.java?revision=1500438&view=markup&pathrev=1503246 > > > http://svn.apache.org/viewvc/directory/escimo/trunk/common/src/main/java/org/apache/directory/scim/ProviderService.java?revision=1503246&view=markup&pathrev=1503246 > > On 04/22/2015 08:13 AM, Emmanuel Lécharny wrote: > > Le 22/04/15 12:42, Colm O hEigeartaigh a écrit : > >> I don't think that having two different implementations of the same > thing > >> at Apache Directory is a good thing. However, it's certainly not > unheard of > >> for a project to replace an older codebase with a new donated codebase > for > >> a new major release, if there is a compelling reason to do so. > > As a matter of fact, Kerby is the perfect exemple of such a situation ! > > > > > >> For example, > >> maybe the architecture of the older project may be too limiting etc. > > or the donation is more advanced. > > > > -- > "One longs, in reading your code, to walk on all fours" - Voltaire > > -- Kiran Ayyagari http://keydap.com
