I chose "advertising" very carefully in recognizance that finding a
service is not always an explicit operation on the part of a consumer.
I do feel that we need to explain advertisement carefully so that
readers understand that discovery, surprisingly, is covered by
advertisement.
-Matt
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:]
>Sent: Monday, April 11, 2005 12:54 PM
>To: Ken Laskey
>Cc: Duane Nickull; Chiusano Joseph; ;
>
>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:]
>>>> Sent: Wednesday, March 30, 2005 12:44 PM
>>>> To:
>>>> 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
>>>>
>>>> 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
>>
>>
>
>
>
>> /
>>
>>
>>
>>
>-----------------------------------------------------------------------
>
>
>>-----------
>>
>>
>>
>>
>
>
>
