[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] RE: Definition of Reference Model (Was RE: [soa-rm] Definition of "Service Consumer")
Hi Ken and Duanne,
This discussion is very useful for the less initiated/experienced members
like myself to understand the consensus view of what is in scope and what is
not for a SOA-RM.
Your approach of listing the commonalities across SOA implementations is a
good way forward. I propose that we categorize the enumeration (whenever
done) under three headings:
1. Pre-requisites (must have in place without which a SOA cannot be
implemented)
2. Invariants (every SOA has these invariants -- the minimal set of common
features, characteristics and core services that may be implemented in more
than one way)
3. Options (and specializations that can be removed without breaking the
minimal set of SOA commonalities)
I am sure most of us have used this or similar categorization as part of a
Product Development Methodology and benefited?
Cheers,
=Ajay.Madhok
-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Monday, April 18, 2005 8:49 AM
To: Duane Nickull
Cc: Smith, Martin; Chiusano Joseph; soa-rm@lists.oasis-open.org; Thomas Erl;
Metz Rebekah
Subject: Re: [soa-rm] RE: Definition of Reference Model (Was RE: [soa-rm]
Definition of "Service Consumer")
Duane,
I think we need to consider what elements seem to have a significant
relationship to an SOA and at some point document our rationale for
what made it in and what didn't. I find the earlier discussion about
orchestration to be a good example. Orchestration sounds like
something that is intrinsic to the SOA cases most of us find most
interesting but is it something fundamental or just another service
that does, well, orchestration. Security may fit that same mold (but
something still tells me it's special). In any case, I think it might
be helpful if part of our eventual findings include a specific
discussion of what is in and how things on the outside are really
addressed by things on the inside. Otherwise, interested parties will
relive our debates without the benefit of knowing why we came to our
conclusions.
Ken
On Apr 14, 2005, at 1:14 PM, Duane Nickull wrote:
> Brings us back to the basic questions once more ;-)
>
> -- What elements are common in all implementations of SOA that make it
> SOA?
> (Paraphrased) What are the core things that make SOA service oriented?
> -How do we describe those as abstract concepts?
> -What relationships exist amongst those concepts?
> -How do we represent those concepts without referencing concrete
> implementations.
>
> I am preparing a set of slides for newcomers to the TC. I will post
> them by the end of the week for review by the TC. I want to make sure
> that everybody is in agreement with the content - it should be scoped
> to things we have reached consensus on. The purpose is to use it to
> get new TC members up to speed ASAP.
>
> Duane
>
> Thomas Erl wrote:
>
>> Martin,
>>
>> This brings us back to an earlier discussion about determining the
>> scope of our reference model. The definition of the term
>> "architecture" we have chosen for our charter makes reference to
>> "elements that comprise the structure of a system". To determine our
>> scope we need to start by setting the boundaries of and identifying
>> what constitutes a system within the context of an abstract RM.
>>
>> Thomas
>>
>> ----- Original Message ----- From: "Smith, Martin"
>> <Martin.Smith@DHS.GOV>
>> To: "Metz Rebekah" <metz_rebekah@bah.com>; "Chiusano Joseph"
>> <chiusano_joseph@bah.com>; "Duane Nickull" <dnickull@adobe.com>
>> Cc: <soa-rm@lists.oasis-open.org>
>> Sent: Tuesday, April 12, 2005 7:01 PM
>> Subject: RE: [soa-rm] RE: Definition of Reference Model (Was RE:
>> [soa-rm] Definition of "Service Consumer")
>>
>>
>> Rebeka - -
>>
>> Yes, I agree. And yes, I think we should consider the set of
>> "infrastructure services" that is required (or typically required) to
>> implement an SOA.
>>
>> After all, what we're (or at least I'm) interested in is not a
>> "service architecture" but a "services-oriented" application
>> architecture.
>>
>> Martin
>>
>>
>>
>>
>>
>> ________________________________
>>
>> From: Metz Rebekah [mailto:metz_rebekah@bah.com]
>> Sent: Tue 4/12/2005 8:00 PM
>> To: Smith, Martin; Chiusano Joseph; Duane Nickull
>> Cc: soa-rm@lists.oasis-open.org
>> Subject: RE: [soa-rm] RE: Definition of Reference Model (Was RE:
>> [soa-rm] Definition of "Service Consumer")
>>
>>
>>
>>
>>
>> Martin -
>>
>>
>>
>> What would be providing the orchestration, workflow, etc within the
>> SOA if not another service? If that is the case, the RM should really
>> abstract out to dealing with a service, which may or may not
>> orchestrate other services. That orchestration, however, would become
>> part of the functionality that is implied by the service contract or
>> shaped by the service policy.
>>
>>
>>
>> It seems like the real question is whether an orchestration concept
>> that is independent of the orchestrated services is a valid piece of
>> the RM.
>>
>>
>>
>> Rebekah
>>
>>
>>
>> Rebekah Metz
>>
>> Associate
>>
>> Booz Allen Hamilton
>>
>> Voice: (703) 377-1471
>>
>> Fax: (703) 902-3457
>>
>>
>>
>> ________________________________
>>
>> From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>> Sent: Tuesday, April 12, 2005 3:24 PM
>> To: Chiusano Joseph; Duane Nickull
>> Cc: soa-rm@lists.oasis-open.org
>> Subject: RE: [soa-rm] RE: Definition of Reference Model (Was RE:
>> [soa-rm] Definition of "Service Consumer")
>>
>>
>>
>> Joe - -
>>
>>
>>
>> I agree that all implementations shouldn't have to include all
>> elements, or, in other words, the RM should not be limited to
>> elements that are included in all implementations.
>>
>>
>>
>> I still think that both services composition (orchestration,
>> workflow, program logic, BPM . . . ) should be an element of the RM.
>> It's not going to be a very useful or interesting environment that is
>> limited to interactions with one service.
>>
>>
>>
>>
>>
>> I also think security should be a core element: it may not be
>> necessary to have security on trivial, free services, but all the
>> interesting cases will have it, and the RM should inform how that
>> element will interact with others.
>>
>>
>>
>> Also, I saw someone refer to our task as defining a RM for
>> "distributed systems" (or a particular style.) I think that is why we
>> are all here, and using that as the "it" we are trying to describe
>> would bring some focus, IMHO.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Martin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>> Sent: Tuesday, April 12, 2005 1:37 PM
>> To: Duane Nickull
>> Cc: soa-rm@lists.oasis-open.org
>> Subject: [soa-rm] RE: Definition of Reference Model (Was RE: [soa-rm]
>> Definition of "Service Consumer")
>>
>>
>>
>> Thanks Duane. Just to clarify, I was not questioning the fundamental
>> role and nature of reference models (i.e. it's understood that the
>> are not implementable directly, and that they do not go beyond the
>> level of detail than you specified below). What I was questioning was
>> our *interpretation* of that definition, in that our interpretation
>> may be considered as too restrictive.
>>
>>
>>
>> I also have not seen a univeral definition of reference model (or an
>> example of one) that states that something has to be absolutely
>> mandatory (even if it is related, such as security, messaging, etc.)
>> in order to be included in a reference model. IMHO, a reference model
>> that does not provide - well - value for reference because it is too
>> restrictive, or too abstract (too far from being implementable* in
>> the real world) is not a valuable reference model.
>>
>>
>>
>> As always, I really appreciate your insight.
>>
>>
>>
>> Joe
>>
>>
>>
>> Kind Regards,
>>
>> Joseph Chiusano
>>
>> Booz Allen Hamilton
>>
>> Visit us online@ http://www.boozallen.com <http://www.boozallen.com>
>>
>>
>>
>> *meaning in this case, for creating SOA architectures - not SOA
>> implementations directly - from it
>>
>> ________________________________
>>
>> From: Duane Nickull [mailto:dnickull@adobe.com]
>> Sent: Tue 4/12/2005 1:19 PM
>> To: Chiusano Joseph
>> Cc: soa-rm@lists.oasis-open.org
>> Subject: Re: Definition of Reference Model (Was RE: [soa-rm]
>> Definition of "Service Consumer")
>>
>> Joseph:
>>
>> We should not re-define what a reference model is. The term has
>> industry accepted connotations. A Reference Model is NOT implement
>> able
>> directly. It does not include the necessary level of detail to build
>> anything with other than architecture. If it did, then by definition
>> it
>> would not be a reference model. A reference model is also not
>> restrictive by nature. You may add more things to the core set as you
>> require them.
>>
>> Your email does bring up an interesting and recurring theme however.
>> Perhaps in addition to a reference model, it would be useful to
>> deliver
>> a user guide/framework for development. We may have to consider at
>> least a separate FAQ or similar as we progress. I do suspect however,
>> that most software architects understand how to use a RM.
>>
>> There will also be plenty of opportunity to build architecture in this
>> TC as a Sub TC. I had a request yesterday for a group to start a Sub
>> TC
>> within this TC to concentrate on a concrete architecture for a very
>> specific field, using the SOA RM as their guide. I hope that we have
>> at
>> least 2-3 of these as time goes on.
>>
>> Other comments inline:
>>
>> Chiusano Joseph wrote:
>>
>>> 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.
>>>
>> If something is not a unifying concept for all things SOA, it should
>> not
>> be in the RM however this does raise the chicken and egg question. How
>> do we determine if something is SOA before the RM is complete? There
>> is
>> no quantitative way to determine if something is or isn't SOA.
>> Accordingly, the types of discussions we are having are very healthy
>> IMO. I enjoy the fact that we have all types of opinions on this list
>> to consider.
>>
>>> 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.
>>>
>> A RM by definition is abstract, therefor you may correctly imply
>> "academic". It is very useful to those who develop architecture.
>>
>>> 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.
>>>
>>>
>> This is what we have been and should continue to do. We are scouring
>> all things claiming to be or perceived to be SOA and trying to
>> determine
>> what are the common elements in those, how to describe them in an
>> abstract manner and what the relationships amongst those things are.
>>
>> Duane
>>
>>> Thoughts?
>>>
>>> Joe
>>>
>>> Joseph Chiusano
>>> Booz Allen Hamilton
>>> Visit us online@ http://www.boozallen.com
>>>
>>>
>>>
>>>
>>>> -----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; 'Andrew Nash'
>>>> Subject: Re: [soa-rm] Definition of "Service Consumer"
>>>>
>>>> Let's leave this as an open issue, if we may. Except for a
>>>> very simple, very closed system, I cannot imagine a viable
>>>> SOA in a real environment without security. I am willing to
>>>> be educated about situations where security can legitimately
>>>> be skipped, but I don't think it can be left out of a useful RM.
>>>>
>>>> Ken
>>>>
>>>> On Apr 11, 2005, at 3:32 PM, Matthew MacKenzie wrote:
>>>>
>>>>
>>>>
>>>>> I don't believe that all SOAs do or will have security. I think we
>>>>> should simply not mention it. This is, after all, an abstract
>>>>> 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
>>>>>> more philosophical basis. Not all SOA's use explicit security
>>>>>> protocols (the internet doesn't). The fundamental philosophical
>>>>>> 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
>>>>>> "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
>>>>>>>> security protocols or models. Our requirement must be to ensure
>>>>>>>> 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
>>>>>>>> used.
>>>>>>>> Duane
>>>>>>>>
>>>>>>>> Vikas Deolaliker wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I think the question should be how many different types of
>>>>>>>>> security models will this RM support?
>>>>>>>>> Vikas
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> ***********
>>>>>>>> Senior Standards Strategist - Adobe Systems, Inc. -
>>>>>>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>>>>> /
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> --------------------------------------------------------------------
>>>>
>>>>
>>>>>>> -
>>>>>>> -------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> ***********
>>>>>> Senior Standards Strategist - Adobe Systems, Inc. -
>>>>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> ***********
>> Senior Standards Strategist - Adobe Systems, Inc. -
>> http://www.adobe.com
>> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>> Adobe Enterprise Developer Resources -
>> http://www.adobe.com/enterprise/developer/main.html
>> ***********
>>
>>
>
> --
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. -
> http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - 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-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]