Re: [soa-rm] Sub Comittee and/or User guide

[Duane Nickull <dnickull@adobe.com>]

Joseph:

Our definition of reference model is basically the industry definition 
of reference model. The items proposed are in alignment with the concept 
of a reference architecture. Architecture != Model. Enterprise 
architects can and do use reference models to facilitate a common 
understanding of a concept. The reason I suggested it is that there have 
been suggestions to write something that is not a reference model and 
call it a reference model. To me, that would negate the acceptance of 
our work by most software architects. However, I can see that having a 
reference architecture accompanying the RM is a good idea based on 
perceptions and expectations.

It would be a grievous error to make a RA and call it an RM. That would 
make things much more difficult for those who work with architecture and 
RM's. An RM is abstract and will not contain items that one usually sees 
in architecture or infrastructure. We were very clear about this in our 
charter from day one.

I believe the proposal to work on both answers the needs of all involved.

Duane



Chiusano Joseph wrote:

> Duane,
>
> Respectfully, I wonder if we’re splitting hairs here. IMHO, many would 
> consider “reference model” and “reference architecture” to be 
> synonymous. If they are not, it begs the question: How many steps does 
> one *really* need to go through to finally implement a 
> service-oriented architecture? Are we really making this easier for 
> the world, or more difficult? I say the latter.
>
> For this reason, I (as only one member of this TC) would not support 
> the notion of a new SC to tackle a more useful and actionable product 
> than the one it seems we are heading toward. I would recommend that we 
> revisit our interpretation of the definition of “reference model”, and 
> – if necessary – call a vote to determine what the TC members really 
> believe the end product of this TC should be. My concern is that this 
> is becoming more of an academic exercise than a practical one (but I 
> would very much like to be proven wrong).
>
> Some (hopefully) supporting points:
>
> - The description of this TC on the OASIS site is: “Developing a core 
> reference model to guide and foster the creation of specific, 
> service-oriented architectures”. According to how abstract our 
> reference model is turning out to be, I don’t believe that we are 
> fulfilling that description (“guide and foster”)
>
> - Here is the definition of Reference Model in our charter, reproduced 
> here for emphasis: “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.”
>
> IMHO, I for one do not believe that including the concepts of “service 
> consumer” and “service producer” would violate this definition – 
> however, I do recognize that the definition is subjective.
>
> - I’ve searched the Web for some reference models that exist – here 
> are some, along with my comments :
>
> (1) NASA CCSDS Reference Model for an Open Archival Information System 
> (OAIS): http://www.ccsds.org/documents/650x0b1.pdf
>
> - From p.10: This reference model:
>
> o provides a framework for the understanding and increased awareness 
> of archival concepts needed for Long Term digital information 
> preservation and access;
>
> o provides the concepts needed by non-archival organizations to be 
> effective
>
> participants in the preservation process;
>
> o provides a framework, including terminology and concepts, for 
> describing and comparing architectures and operations of existing and 
> future archives;
>
> o [etc.]
>
> - Note second bullet above “provides the concepts needed”.
>
> - Also, from p.30: See Figure 2-4: IMO, this figure provides enough 
> details to make the reference model useful and actionable.
>
> (2) WfMC Workflow Reference Model:
>
> http://www.wfmc.org/standards/model.htm
>
> - This figure includes components such as: Workflow Client 
> Application, Invoked Applications, Process Definition etc. According 
> to what I’ve been hearing up to now by some, these would be “too 
> concrete”. Please clarify then if you believe this WfMC model is in 
> your opinion truly a reference model. IMHO, it seems to be highly 
> useful and actionable.
>
> (3) Also the OSI Model: I know that we’ve been making repeated 
> references to this model (pardon the pun), but many people do believe 
> that the OSI model failed and TCP/IP triumphed (not sure if that 
> changes our perspective). Also, I don’t believe that the OSI model was 
> intended for the same type of purpose as we are intending here. The 
> OSI model’s mission was quite narrowly scoped, while ours – by virtue 
> of the fact that we are about service-oriented architecture – is much 
> broader. Different treatments for different missions
>
> So in summary, I would very much like us to consider loosening the 
> constraints on our reference model just a bit, to be able to include 
> (or at least consider at length) useful components such as security, 
> orchestration, messaging, etc. Let's make our product (a) useful and 
> (b) actionable.
>
> My $0.02 :)
>
> Joe
>
>
> ------------------------------------------------------------------------
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Mon 4/18/2005 5:23 PM
> To: SOA-RM
> Subject: [soa-rm] Sub Comittee and/or User guide
>
> All:
>
> I have read through the last batch of email. There are a couple of
> things I would like to propose for comments. Please read this entire
> email before replying.
>
> 1. I will concede that many members of the public will likely have the
> same kinds of trouble interpreting a reference model vs. a reference
> architecture vs a specific architecture as seems to be pervasive on this
> list. If we have the problem in our context, it is likely to be present
> outside of this list.
>
> 2. We cannot redefine what a "reference model" is or what it includes.
> If we tried to change the industry definition of reference model to one
> that has concrete items in it or things that are not part of SOA (which
> is tricky since it is still undefined), it will not be a true reference
> model and hence not accepted by industry.
>
> 3. Service provider and service consumer are not part of a reference
> model. They are roles visible only in a runtime or infrastructure views
> of a specific architecture. To prove this point, please look once again
> at the OSI reference model. It is a communications stack RM yet does
> not contain notions of a message sender and message receiver.
>
> 4. We cannot mix abstract concepts and "things people can chew on"
> (implying concrete items) in our work. Such does run adverse to
> accepted architectural conventions.
>
> SOLUTION:
>
> One way forward is to probably create a sub committee to work on a
> reference architecture for SOA. A Reference Architecture could be
> developed in parallel to the reference model and is fair game to
> illustrate things like security, consumers, providers, agents etc. It
> is within our charter to do such.
>
> After reading through some older emails, I would assert that such a
> thing is probably essential along with some sort of white paper or user
> guide that explains the relationships between the RM, the RA and other
> architecture.
>
> Reference Model
> (is a guide for developing a)
> [ Reference Architecture || * Architecture ]
>
> There are several people on this list who also have stated specific
> needs for what they see in SOA. Perhaps this may be a good Sub
> Committee (SC) consideration also.
>
> Government Service Oriented Reference Architecture???
> etc.
>
> I can already see there are many of you who could lead such an effort as
> a sub committee.
>
> Comments?
>
> Duane
>
> --
> ***********
> 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
***********