| [higgins-dev] RE: M4 Architecture |
|
I actually like the API layer on top that provides a common developer view of Matcher and Selector. Just would like to have Matcher, H-Tag Manager and STS talk to IdAS(API) on the bottom and not to CPI (SPI).
-Baber >>> "Paul Trevithick" < paul@xxxxxxxxxxxxxxxxx > 4/1/2006 6:18:28 pm >>> Baber and Raj, Yes I did make the change that Baber referred to. In Provo we were moving very fast and the diagram was evolving quickly. The current architecture http://spwiki.editme.com/ArchitectureM4 does reflect my latest, best understanding. I have not yet been able to split out as a single unit these three: {Matcher, Digital Identity Selector UI support and H-Tag Manager} and make them their own layer above what is currently drawn in as the API. I agree vehemently that if things can be cleanly separated and split out, they should be. As these components come into more focus we'll be able to see more clearly if and where the cut can be made. -Paul -----Original Message----- From: Nataraj Nagaratnam [mailto:natarajn@xxxxxxxxxx] Sent: Saturday, April 01, 2006 8:01 PM To: Baber Amin Cc: Anthony Nadalin; Duane Buss; Dale Olds; higgins-dev@xxxxxxxxxxx ; Igor Tsinman; Jan Camenisch; John Calcote; Jim Sermersheim; Juan Carlos Luciani; 'Mary Ruddy'; John Merrells; Michael McIntosh; Paul Trevithick; Pat Felsted; Tom Doman; Valery Kokhan Subject: Re: M4 Architecture Thanks for bringing this to attention/discussion, Baber. I didn't realize this change ... One liner is my view is -- IdAS is the API, CPI is the SPI. IdAS is a fundamental concept and important. That is what applications (including STS, etc) will know and use .. for those who are not identity provider savvy, all they need to know is the IdAS. If collaboration sites, transaction applications, need to use Higgins and they ask us what to do .. then we tell them that the programming model - IdAS is what you need to know about. They do not need to worry about context providers. For those site providers who need to participate in a given identity metasystem, then CPI is a way for them to plug into that system. Thus, in a framework provider model ... I see IdAS as the "API" that others (applications including STS, or other apps that need identity info, etc) can talk to. CPI is the pluggable "SPI" that allows providers to be plugged into a metasystem and thus accesible through an IdAS. -Raj ps: i am using the term metasystem loosely here ;) .. to get the point across about various contexts can be accessed through a system where those contexts are 'registered' in some sense. "Baber Amin" < baber@xxxxxxxxxx > 04/01/2006 07:17 PM To < higgins-dev@xxxxxxxxxxx >, "Tom Doman" < TDoman@xxxxxxxxxx >, Anthony Nadalin/Austin/IBM@IBMUS cc "Duane Buss" < DBuss@xxxxxxxxxx >, "Dale Olds" < DOlds@xxxxxxxxxx >, "John Calcote" < JCALCOTE@xxxxxxxxxx >, "Jim Sermersheim" < JIMSE@xxxxxxxxxx >, "Juan Carlos Luciani" < JLUCIANI@xxxxxxxxxx >, "Pat Felsted" < PFELSTED@xxxxxxxxxx >, "Igor Tsinman" < igor@xxxxxxxxxxxxx >, "Valery Kokhan" < valery@xxxxxxxxxxxxx >, "'Mary Ruddy'" < mary@xxxxxxxxxxxxxxxxx >, "Paul Trevithick" < paul@xxxxxxxxxxxxxxxxx >, "John Merrells" < merrells@xxxxxxxx >, Michael McIntosh/Watson/IBM@IBMUS, Nataraj Nagaratnam/Raleigh/IBM@IBMUS, "Jan Camenisch" < jca@xxxxxxxxxxxxxx > Subject M4 Architecture Hi Folks, the picture at the URL below has renamed IDAS to Context Provider Interface. They might perform the same function, but I feel that we need to have IDAS with a very thin CPI layer under it for the context providers to plug into. I see IDAS as a major Higgins component to be used on back-end services where we won't need anything above it. This is where IDAS and Higgins act as a identity normalization layer. Having just a CPI there feels empty. Even in the M4 picture, we see the top of CPI talking to STS. Since an STS is not a context provider it should not be talking to that interface, the top of the CPI should be IDAS. Do you agree Paul? Cheers -Baber http://spwiki.editme.com/ArchitectureM4 [attachment "higgins web integration 060315_1.JPG" deleted by Nataraj Nagaratnam/Raleigh/IBM] |