Re: [soa-rm] Architectural Scope of Reference Model

[Ken Laskey <klaskey@mitre.org>]

I tend to think of things in terms of their metadata and the diagram in  
the document I submitted has service metadata as a central concept.  I  
would be interested to see how you would modify it or do you have a  
very different idea?

Ken

On Apr 14, 2005, at 4:21 AM, Gregory A. Kohring wrote:

> I am not sure about the inclusion of "Service Descriptions".  If by
> this you mean "describes what the service does", then this is just
> one facet of a larger set of metadata associated with a service.
> In this large set I would include quality guarantees, policy
> statements, "contract" (in the sense used in the
> "programming by contract" communities) and "contract" (in the sense
> used by the legal community).
>
> Perhaps "Service Metadata" would be a better choice for encompassing
> these more general concepts...
>
> -- Greg
>
> Duane Nickull wrote:
>> I would like to use the term "advertising" for now as a placeholder,  
>> knowing full well we may all agree another term may be substituted  
>> later.   I think that we all conceptually agree that the premise is  
>> "to make the existence of a service known to all consumers on a  
>> fabric" or some variation and that "advertising" may or may not be  
>> the best term to represent the abstract concept.
>> To recap, it seems that this concept is one of the pillars of SOA.   
>> It's implementation may take many forms {(pull, push)  
>> (publish/subscribe) (multi-cast, unicast, broadcast, point  
>> cast)(...)}.
>> That means that we have reached consensus (correct me if I am  
>> mistaken) that the SOA RM contains the following elements:
>> 1. Services
>> 2. Service Descriptions
>> 3. Advertising/whateverwecallit - the ability to make the existence  
>> of a service and/or details thereof available to consumers on a  
>> fabric
>> 4. Datamodel/whateverwecallit (includes the abstract notion of a set  
>> of logical instances of data a.k.a. an abstract concept of a message,  
>> possibly includes the concept of semantics)
>> We have not all agreed to the following things, but have no  
>> substantial disagreement they are not in the SOA RM:
>> 5. Contract - is it really a policy?  Is it a core part of the  
>> reference model.  If it is a policy, does it imply the abstract  
>> functionality represented in the security component of a concrete  
>> architecture?
>> The next set if items are likely not included in the core RM, yet may  
>> be mentioned to illustrate functionality.
>> 6. Service consumer
>> I am very impressed by the progress to date (assuming I have not  
>> jumped too far to conclusions).
>> Duane
>> Smith, Martin wrote:
>>> Ken - -
>>>
>>> Register?  (implies some official or at least "well  known" place  
>>> where things are registered.)
>>> Publish?  (more general term without the commercial/spam connotation)
>>>
>>> To me, "advertise" implies "push"; register/discover and  
>>> publish/subscribe are "pull."  Advertise also implies use of a  
>>> variety of communications methods, including registration (e.g., in  
>>> the Yellow Pages) but also product placement, spam, etc. that might  
>>> be considered dysfunctional.
>>> However, I have no problem putting aside this issue until (much)  
>>> later.
>>>
>>> Martin
>>>
>>> ________________________________
>>>
>>> From: Ken Laskey [mailto:klaskey@mitre.org]
>>> Sent: Mon 4/11/2005 9:28 PM
>>> To: Breininger, Kathryn R
>>> Cc: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org;  
>>> scott@justiceintegration.com; Francis McCabe
>>> Subject: Re: [soa-rm] Architectural Scope of Reference Model
>>>
>>>
>>>
>>> I am of two minds as I compose this email.  The first is could we  
>>> replace "advertise" with something like "communicate the service  
>>> description"?  The second is let's call it advertise for now, see  
>>> what it actually means, and then rename it if desirable later.
>>>
>>> Take your pick :-)
>>>
>>> Ken
>>>
>>> On Apr 11, 2005, at 4:06 PM, Breininger, Kathryn R wrote:
>>>
>>>
>>>> I also wonder about the term "advertising", especially given the
>>>> audience we are targeting for the high level document.   
>>>> "Advertising"
>>>> has an implied meaning to the average audience, whereas "Discovery"
>>>> implies I have found something through some means, often a search or
>>>> browsing or serendipity or even word of mouth (using the big picture
>>>> here that agents include humans).  Does "advertising" limit the  
>>>> ways in
>>>> which I (or an agent) become aware of and use a service?
>>>>
>>>>
>>>> Kathryn Breininger
>>>> Boeing Library Services
>>>> 425-965-0182 phone
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>>>> Sent: Monday, April 11, 2005 12:54 PM
>>>> To: Ken Laskey
>>>> Cc: Duane Nickull; Chiusano Joseph; scott@justiceintegration.com;
>>>> soa-rm@lists.oasis-open.org
>>>> Subject: Re: [soa-rm] Architectural Scope of Reference Model
>>>>
>>>>
>>>> Is discovery of the essence or advertising? If I discover how to use
>>>> your service by some kind of reverse engineering -- you did not
>>>> advertise it but I discovered it -- and can therefore use it! Frank
>>>>
>>>> On Apr 11, 2005, at 12:00 PM, Ken Laskey wrote:
>>>>
>>>>
>>>>> Quick, write that down some place we won't lose it.  :-)
>>>>>
>>>>> Ken
>>>>>
>>>>> At 02:42 PM 4/11/2005, Duane Nickull wrote:
>>>>>
>>>>>> Ken:
>>>>>>
>>>>>> "Advertising" is an abstract concept.  I would define it as "a
>>>>>> methodology to convey awareness of (the existence of) a  
>>>>>> service(s) to
>>>>>>       all consumers on a fabric".  Does this sound like a good  
>>>>>> place holder
>>>>>>       for the glossary?
>>>>>>
>>>>>> Discovery is an aspect facilitated by advertising.  A consumer
>>>>>> "discovers" a service because the service's existence was  
>>>>>> advertised
>>>>>>       to the consumer or the service description was inspected by  
>>>>>> the
>>>>>> consumer.
>>>>>> Discovery does not automatically imply a right to use the service.
>>>>>>
>>>>>> There are multiple ways to implement a mechanism for discovery.   
>>>>>> 811g
>>>>>> uses a radio signal broadcast, web services uses UDDI, ebXML uses
>>>>>> CPP's accessed via an ebXML registry-repository, CORBA uses an  
>>>>>> ORB,
>>>>>> J2EE uses RMI Registry, Windows uses a registry.....
>>>>>>
>>>>>> Duane
>>>>>>
>>>>>>
>>>>>> Ken Laskey wrote:
>>>>>>
>>>>>>
>>>>>>> How a capability is provided is a design issue but that a  
>>>>>>> capability
>>>>>>> exists is certainly in the purview of the RM. While I might for  
>>>>>>> RM
>>>>>>> sake indicate a vaguely defined box that needs more definition to
>>>>>>> ever see software, that vaguely defined box must be in the RM or  
>>>>>>> we
>>>>>>>         lose that aspect and have an incomplete description. I  
>>>>>>> can give you
>>>>>>>         a half dozen ways to do discovery, but is a discovery  
>>>>>>> box that can
>>>>>>> notionally support all of these an elementary necessity for the  
>>>>>>> RM?
>>>>>>>
>>>>>>> Ken
>>>>>>>
>>>>>>> P.S. I'm still struggling over discovery vs. advertising, so  
>>>>>>> please
>>>>>>> read the above with whichever one makes most sense to you.
>>>>>>>
>>>>>>> On Mar 31, 2005, at 7:32 AM, Chiusano Joseph wrote:
>>>>>>>
>>>>>>>    <Quote>
>>>>>>>    I suspect when we get to specifying what gives a service  
>>>>>>> unique
>>>>>>>    identity,
>>>>>>>    </Quote>
>>>>>>>
>>>>>>>    Will we ever reach that point? That is, is the question of
>>>>>>> whether
>>>>>>>    or not a service has a unique identity within the scope of a  
>>>>>>> RM?
>>>>>>>    My take is no - it's a design issue, and potentially an
>>>>>>>    architecture issue depending on how such a unique identity  
>>>>>>> needs
>>>>>>>    to be generated/maintained (i.e. may have an "identity engine"
>>>>>>>    component in an architecture - not to be confused with  
>>>>>>> identity
>>>>>>>    management for security).
>>>>>>>
>>>>>>>    Kind Regards,
>>>>>>>    Joseph Chiusano
>>>>>>>    Booz Allen Hamilton
>>>>>>>    Visit us online@ http://www.boozallen.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    From: Scott Came [mailto:scott@justiceintegration.com]
>>>>>>>    Sent: Wednesday, March 30, 2005 12:44 PM
>>>>>>>    To: soa-rm@lists.oasis-open.org
>>>>>>>    Subject: Re: [soa-rm] Architectural Scope of Reference Model
>>>>>>>
>>>>>>>    Hello everyone, I've been lurking so far, but let me jump in  
>>>>>>> on
>>>>>>>    this one...
>>>>>>>
>>>>>>>    Thomas' key question, as I read his post, was not whether
>>>>>>> messages
>>>>>>>    should be part of the RM, but whether service requestors  
>>>>>>> should
>>>>>>>         be.
>>>>>>>
>>>>>>>    In my view, having services without service requestors doesn't
>>>>>>>    make a lot of sense. So I would like to suggest that service
>>>>>>>    requestors are a proper element in the RM.
>>>>>>>
>>>>>>>    If you grant that, then the relationship between a service
>>>>>>>    requestor and a service implies the exchange of some  
>>>>>>> information
>>>>>>>    (in the general case). We might not call that a "message", but
>>>>>>>
>>>>
>>>> it
>>>>
>>>>>>>    does exist. Is there another, more appropriately abstract,  
>>>>>>> name
>>>>>>>    for the elements of the service's interface that specify the
>>>>>>>    structure of information exchange that occurs between  
>>>>>>> requestor
>>>>>>>    and service?
>>>>>>>
>>>>>>>    Looking at it another way (and forgive me if this is getting
>>>>>>> ahead
>>>>>>>    of where we should be)...I suspect when we get to specifying
>>>>>>>
>>>>
>>>> what
>>>>
>>>>>>>    gives a service unique identity, it may well be a (perhaps
>>>>>>>    qualified) name plus a set of interface elements
>>>>>>>    (operations/behaviors, if you will, and the "signature" of  
>>>>>>> those
>>>>>>>    operations). If so, then we'll need a name for the elements  
>>>>>>> that
>>>>>>>    represent the input and output parameters (again, forgive the
>>>>>>>    "concrete" terminology) of each operation.
>>>>>>>
>>>>>>>    Regards...
>>>>>>>    --Scott
>>>>>>>
>>>>>>>    Scott Came
>>>>>>>    President and Principal Consultant
>>>>>>>    Justice Integration Solutions, Inc.
>>>>>>>    Olympia, Washington
>>>>>>>    scott@justiceintegration.com
>>>>>>>    http://www.justiceintegration.com
>>>>>>>
>>>>>>>
>>>>>>>> Thomas:
>>>>>>>>
>>>>>>>> Thank you for this very elegant summary!
>>>>>>>>
>>>>>>>> I think the answer may be in the definition of a "reference
>>>>>>>>
>>>>>>>
>>>>>>>    model" vs.
>>>>>>>
>>>>>>>> "architecture". I think case studies will help clear up this
>>>>>>>> confusion. A reference model will normally not contain
>>>>>>>>
>>>>>>>
>>>>>>>    "messages" as a
>>>>>>>
>>>>>>>> component.
>>>>>>>>
>>>>>>>> 1. Please look at the OSI Reference model. This is a
>>>>>>>>
>>>>>>>
>>>>>>> communication
>>>>>>>
>>>>>>>> stack yet it does not contain messages:
>>>>>>>> http://www.scit.wlv.ac.uk/~jphb/comms/std.7layer.html
>>>>>>>>
>>>>>>>> This does not contain any "message" although messages will
>>>>>>>>
>>>>>>>
>>>>>>> occur in
>>>>>>>
>>>>>>>> implementations using the reference model
>>>>>>>>
>>>>>>>> 2. The ITA Reference Model likewise does not have "messages":
>>>>>>>> http://www.ewita.com/earlywork/itarefr.htm
>>>>>>>>
>>>>>>>> 3. RCS Reference Model
>>>>>>>> http://www.isd.mel.nist.gov/documents/messina/euro_cast.pdf
>>>>>>>>
>>>>>>>> Again - no messages even though there is an element marked
>>>>>>>> "Communications" in figure one.
>>>>>>>>
>>>>>>>> The reference Model should not contain "messages" as a
>>>>>>>>
>>>>>>>
>>>>>>>    component. That
>>>>>>>
>>>>>>>> belongs in architecture or implementations based on the
>>>>>>>>
>>>>>>>
>>>>>>> reference
>>>>>>>
>>>>>>>> model. I have never encountered one reference model with
>>>>>>>>
>>>>>>>
>>>>>>>    concrete terms
>>>>>>>
>>>>>>>> in it. If it had such, it would not be abstract.
>>>>>>>>
>>>>>>>> We must think abstract, not concrete.
>>>>>>>>
>>>>>>>> Duane Nickull
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thomas Erl wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Some thoughts regarding the on-going discussion of whether a
>>>>>>>>>
>>>>>>>
>>>>>>>    message
>>>>>>>
>>>>>>>>> element should be part of our reference model:
>>>>>>>>>
>>>>>>>>> As per our chosen definition of architecture, in order to
>>>>>>>>>
>>>>>>>
>>>>>>> describe
>>>>>>>
>>>>>>>>> service-oriented architecture we need to:
>>>>>>>>> 1. Define elements that comprise the structure of a system.
>>>>>>>>> 2. Define external properties of these elements.
>>>>>>>>> 3. Define relationships between these elements.
>>>>>>>>> 4. Define the overall structure of the system.
>>>>>>>>> (not necessarily in this order)
>>>>>>>>>
>>>>>>>>> Starting with the first point, different element collections
>>>>>>>>>
>>>>>>>
>>>>>>>    have been
>>>>>>>
>>>>>>>>> proposed in the two position papers submitted so far. As has
>>>>>>>>>
>>>>>>>
>>>>>>> been
>>>>>>>
>>>>>>>>> discussed, the MacKenzie/Nickull paper does not identify a
>>>>>>>>>
>>>>>>>
>>>>>>> message
>>>>>>>
>>>>>>>>> element, whereas Kohring's does.
>>>>>>>>>
>>>>>>>>> A related difference I noticed when reviewing these papers is
>>>>>>>>>
>>>>>>>
>>>>>>> that
>>>>>>>
>>>>>>>>> Kohring's establishes a broader range of SOA elements.
>>>>>>>>>
>>>>>>>
>>>>>>>    Specifically,
>>>>>>>
>>>>>>>>> both service provider and requestor (consumer) roles are
>>>>>>>>>
>>>>>>>
>>>>>>>    separately
>>>>>>>
>>>>>>>>> identified and described. As mentioned in item #3 above, we
>>>>>>>>>
>>>>>>>
>>>>>>> are
>>>>>>>
>>>>>>>>> required to define the relationship between the elements we
>>>>>>>>>
>>>>>>>
>>>>>>>    define.
>>>>>>>
>>>>>>>>> Therefore, it makes sense that this paper includes a separate
>>>>>>>>>
>>>>>>>
>>>>>>>    element
>>>>>>>
>>>>>>>>> (message) that can be used to help describe the relationship
>>>>>>>>>
>>>>>>>
>>>>>>>    between a
>>>>>>>
>>>>>>>>> service and its requestor.
>>>>>>>>>
>>>>>>>>> The elements identified in the MacKenzie/Nickull paper are:
>>>>>>>>> - Service
>>>>>>>>> - Service Description
>>>>>>>>> - A form of advertisement to facilitate discoverability.
>>>>>>>>> - Service Contract
>>>>>>>>> - Data Model
>>>>>>>>> These elements form a narrower architectural scope, leading
>>>>>>>>>
>>>>>>>
>>>>>>> to a
>>>>>>>
>>>>>>>>> proposed architecture that revolves primarily around the
>>>>>>>>>
>>>>>>>
>>>>>>>    service (or a
>>>>>>>
>>>>>>>>> service assuming the provider role). Because a service
>>>>>>>>>
>>>>>>>
>>>>>>>    requestor is
>>>>>>>
>>>>>>>>> not explicitly identified as a separate element, it makes
>>>>>>>>>
>>>>>>>
>>>>>>> sense
>>>>>>>    that
>>>>>>>
>>>>>>>>> an element representing some unit of communication (message
>>>>>>>>>
>>>>
>>>> or
>>>>
>>>>>>>>> otherwise) is also not identified. Within this model's scope,
>>>>>>>>>
>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>>> definition of a relationship between a service and its
>>>>>>>>>
>>>>>>>
>>>>>>> requestor
>>>>>>>
>>>>>>>>> (beyond details implied by description, contract, data model,
>>>>>>>>>
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>>> advertisement elements) is not a requirement.
>>>>>>>>>
>>>>>>>>> I believe that in order to address the issue of whether a
>>>>>>>>>
>>>>>>>
>>>>>>>    message is a
>>>>>>>
>>>>>>>>> legitimate element within the reference model, we should
>>>>>>>>>
>>>>
>>>> begin
>>>>
>>>>>>>>> by clearly defining the scope of our abstract architecture.
>>>>>>>>>
>>>>>>>
>>>>>>>    Given that
>>>>>>>
>>>>>>>>> we are establishing core elements that are expected to be
>>>>>>>>>
>>>>>>>
>>>>>>>    present in
>>>>>>>
>>>>>>>>> all forms of SOA, this raises the question: Does an
>>>>>>>>>
>>>>>>>
>>>>>>> architecture
>>>>>>>
>>>>>>>>> require the presence of both a service provider and a service
>>>>>>>>> requestor (the coffee shop and the patron) in order to be
>>>>>>>>>
>>>>>>>
>>>>>>>    classified
>>>>>>>
>>>>>>>>> "service-oriented"? If yes, we must define this relationship.
>>>>>>>>>
>>>>>>>
>>>>>>> To
>>>>>>>
>>>>>>>>> properly do so, we very well may need to further identify and
>>>>>>>>>
>>>>>>>
>>>>>>>    define a
>>>>>>>
>>>>>>>>> separate element to represent an abstract unit of
>>>>>>>>>
>>>>>>>
>>>>>>> communication
>>>>>>>    passed
>>>>>>>
>>>>>>>>> between them.
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --  
>>>>>>>> ***********
>>>>>>>> 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
>>>>>     /
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> ---
>>>>
>>>>> -----------
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------- 
>>> ---
>>> ------------------
>>> Ken Laskey
>>> MITRE Corporation, M/S H305     phone:  703-883-7934
>>> 7515 Colshire Drive                        fax:        703-883-1379
>>> McLean VA 22102-7508
>>>
>>>
>>>
>>>
>>>
>
>
> -- 
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
>
------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508