OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Perhaps the word that you are looking for is *establishment*. When  
something is established, it becomes *real* and, perhaps, useable.
Frank

On Apr 12, 2005, at 4:54 PM, Duane Nickull wrote:

> I think to me, the definition of advertising is "to make  
> discoverable".  Does this make sense?  I am still not sure if it is  
> the right word to use.
>
> Duane
>
> Metz Rebekah wrote:
>
>> Taking Frank's statement one step further:
>> Discovery presumes that the service did nothing to announce to a
>> consumer/agent/entity etc of its existence.  That was done  
>> independently
>> by that entity in some way (and potentially unbeknownst to the  
>> service).
>>
>>
>> If discovery is via a registry, we start bleeding over into the realm  
>> of
>> advertising.  The registry is just a middleman, a broker if you will.
>> That registry serves as targeted advertising.  Broadening the reach of
>> advertising, the service could just broadcast its availability (or
>> existence) and assume that broadcast will reach the targeted service
>> consumers.  Taking a page from cable television advertising, the
>> advertising could select the appropriate channels; methods; etc to
>> increase its chances of hitting the desired target audience, but it
>> really comes down to announcing itself independently of any knowledge  
>> of
>> who it is announcing itself to.
>>
>> What is common to both of these is the concept of a service and a
>> consumer locating one another.
>>
>> Rebekah
>>
>> Rebekah Metz
>> Associate
>> Booz Allen Hamilton
>> Voice:  (703) 377-1471
>> Fax:     (703) 902-3457
>>
>>
>>
>>> -----Original Message-----
>>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>>> Sent: Monday, April 11, 2005 3: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
>>>> /
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------- 
>> -
>>
>>>> -----------
>>>>
>>>>
>>>>
>>
>>
>
> -- 
> ***********
> 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
> ***********
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]