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:]
>>Sent: Monday, April 11, 2005 3:54 PM
>>To: Ken Laskey
>>Cc: Duane Nickull; Chiusano Joseph; ; soa-
>>
>>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
>>> /
>>>
>>>
>>>
>>>
>-----------------------------------------------------------------------
>
>
>>>-----------
>>>
>>>
>>>
>>>
>
>
>
--
***********
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
***********
