Menu
▾
▴
Re: [Bodington-developers] hibernate ~ spring ~ common core
|
From: Alistair Y. <ali...@sm...> - 2006-06-06 17:06:57
|
Could you expand on what common core means Selwyn? Perhaps I'm way off on a tangent here but you mentioned LDAP as a core schema. The federated services world started along this route (eduPerson) but seem to be migrating away from it and leaving schema design to application developers, using the OID model. Do you mean, e.g. Tetra can see "user_id" in bod_db and know it's the sam= e as "userid" in sakai_db? That would be a semantic nightmare unless OIDs were used. We could define a Tetra OID space. Plug in a new application with it's own db, have it provide an OID layer for it and hey presto, "Tetra" can AAA users across applications: - User logs in to Sakai - User clicks on link to login to Bod questionnare (say) - Bod is shibbed so "Tetra" kicks in - "Tetra" says to Sakai - give me OIDs 1.45.5.3 and 9.4.21.4 - Something makes a decision based on the values of those attributes defined by those OIDs. Sounding like a XACML layer in there too! I only mention it as the concepts sound a wee bit the same. --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > sorry, the question was... did the topic get aired? > > still I'll try and deal with your concern about innovation and explain > our perspective a little more with some kind of illustration in text :) > > > *innovation > > putting a lid on innovation would be the last thing on our mind [please > be assured of that] > on the contrary a common core data structure provides a license to > innovate sensibly. > regards application innovation you can have as many application > databases as you like, common is just that 'common'. > > *common core > > the proposal is so that a concept such as Tetra has a core on which to > build, > > in this integrated model > > user application [presentation layer] > components & services layer > application data layer > common data layer > > or in a little more detail > > > my integrated portal thingy me bob [bod 2] > | > bod tetra | sakai tetra | ioportal tetra > | | | > bod_db sakai_db ioportal_db > | | | > | > common core > > *schema > If I was going to propose a common core to begin with then it might be > based on LDAP / Enterprise hybrid but I'm not proposing the schema, jus= t > asking if the topic was aired. > perhaps the LDAP schema is to generic for us and we need to extend that > to cope with other common considerations in e-learning. > but common core all about calling a spade a spade and reuseability. > > Cheers > > Sel > > > > > > > > Peter Crowther wrote: > >>>From: Selwyn Lloyd >>>did the idea of a common schema for an abstraction layer get aired? >>> >>>we figured that a common core gives us more ways to integrate >>>different >>>developemnt models, i.e. spring, struts, portlets, web services and >>>other models can sit side by side if we had a common storage model >>>for a core e-learning schema >>> >>> >> >>Intuitively this feels even harder to standardise than common >>interchange formats, and feels like standardisation at the wrong level >>to boot. People expect interchange formats to be lossy, and there can >>be more than one of them for a given area. By contrast, multiple >>storage models are beggars to integrate. >> >>What would you propose to standardise? How would you propose to let >>developers innovate in the presence of a common core (or is one of the >>goals to put a lid on unwanted innovation)? Would you expect a >>table-based or hierarchical storage model? >> >> - Peter >> >> >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> >> > > -- > Selwyn Lloyd > Phosphorix > tel: 07979240124 > irc://irc.ionode.org > channel: #ionode > web: http://www.phosphorix.co.uk > forum: http://forum.ionetwork.ac.uk > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
