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:]
>>> 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
> ***********
>
