[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
<Definition> Reference Model - A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.=20 </Definition> This definition does not state that only "mandatory" concepts are included, but rather implies it through its reference to "a small number of unifying concepts". I recommend that at this point, since our definition of "reference model" is being used as a filter for everything - and so many things are (perhaps justifiably!) being "kicked out" of it - we gain consensus on what we believe "reference model" means.=20 I bring this up because I have seen cases where reference models are not as restrictive as the one that we are heading toward (but maybe they should be?). I am also (frankly) concerned that we might be developing something that is - and I don't mean this in a pejorative sense - too "academic" and not implementable in real-world settings. I would like to see us create something that is more inclusive than exclusive, so it can have the maximum utility for developing service-oriented architectures, rather than making folks think about why fundamental aspects - such as security - were left out of it. I also wonder if it might be more valuable process-wise to concentrate on concrete architectures, and then determine from among those concrete architectures what concepts are mandatory, what are optional etc. - that is, to build our reference model from outward-in, instead of the opposite which I believe is our current process. Thoughts? Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com =20 > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Monday, April 11, 2005 9:02 PM > To: Matthew MacKenzie > Cc: 'Frank McCabe'; Duane Nickull; > soa-rm@lists.oasis-open.org; vikas@sonoasystems.com; Chiusano Joseph;=20 > 'Andrew Nash' > Subject: Re: [soa-rm] Definition of "Service Consumer" >=20 > Let's leave this as an open issue, if we may. Except for a very=20 > simple, very closed system, I cannot imagine a viable SOA in a real=20 > environment without security. I am willing to be educated about=20 > situations where security can legitimately be skipped, but I don't=20 > think it can be left out of a useful RM. >=20 > Ken >=20 > On Apr 11, 2005, at 3:32 PM, Matthew MacKenzie wrote: >=20 > > I don't believe that all SOAs do or will have security. I think we=20 > > should simply not mention it. This is, after all, an abstract=20 > > reference model. We can produce the warmNfuzzy that having > a security > > component adds in our own SOA designs that are identifiable > with the > > SOA-RM. > > > > -matt > > > > On 11-Apr-05, at 12:28 PM, Duane Nickull wrote: > > > >> Ken: > >> > >> I am not 100% sure about this. I would like to research this on a=20 > >> more philosophical basis. Not all SOA's use explicit security=20 > >> protocols (the internet doesn't). The fundamental philosophical=20 > >> question may be " does the explicit statement conveying > the absence > >> of any security still imply a security model"? > >> > >> The danger in saying "yes" is that it opens the door for more=20 > >> "things" to be part of the RM. > >> > >> I would like to mull this over and do some research. I am > sure Matt > >> has a good answer ;-) > >> > >> Duane > >> > >> Ken Laskey wrote: > >> > >>> Moreover, the question is whether all SOAs SHOULD have > security and > >>> whether that needs to be captured in the RM. As noted, > secuirty is > >>> often just tacked on and that may not be sufficient for > *any* SOA to > >>> be successful. > >>> > >>> Ken > >>> > >>> At 02:27 PM 4/11/2005, Duane Nickull wrote: > >>> > >>>> The RM does not support security models. A reference > model is used > >>>> to guide the design of architecture that may include specific=20 > >>>> security protocols or models. Our requirement must be to ensure=20 > >>>> that nothing we place in the RM makes any specific > security model a > >>>> requirement (since not all SOA's have security) and to > ensure that > >>>> we do not preclude a specific type of security model from being=20 > >>>> used. > >>>> Duane > >>>> > >>>> Vikas Deolaliker wrote: > >>>> > >>>>> I think the question should be how many different types of=20 > >>>>> security models will this RM support? > >>>>> Vikas > >>>>> > >>>>> -- > >>>> > >>>> -- > >>>> *********** > >>>> Senior Standards Strategist - Adobe Systems, Inc. -=20 > >>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -=20 > >>>> http://www.unece.org/cefact/ Adobe Enterprise Developer > Resources > >>>> - http://www.adobe.com/enterprise/developer/main.html > >>>> *********** > >>>> > >>> > >>> -- =20 > >>>=20 > -------------------------------------------------------------------- > >>> - > >>> ------------ > >>> / Ken Laskey =20 > =20 > >>> \ > >>> | MITRE Corporation, M/S H305 phone: 703-883-7934 | > >>> | 7515 Colshire Drive fax: =20 > 703-883-1379 =20 > >>> | > >>> \ McLean VA 22102-7508 =20 > =20 > >>> / > >>> =20 > >>>=20 > -------------------------------------------------------------------- > >>> - > >>> ------------- > >>> > >>> > >> > >> -- > >> *********** > >> Senior Standards Strategist - Adobe Systems, Inc. -=20 > >> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -=20 > >> http://www.unece.org/cefact/ Adobe Enterprise Developer > Resources - > >> http://www.adobe.com/enterprise/developer/main.html > >> *********** > >> > > > > > -------------------------------------------------------------- > ---------- > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-883-7934 > 7515 Colshire Drive fax: 703-883-1379 > McLean VA 22102-7508 >=20 >=20 >=20
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]