Francis:
I am not comfortable with that term either. I can establish a service
without advertising it. Establishment is a metric or state of
existentialism IMO.
The concepts are (sort of):
- announce (not suitable as a word since this implies a push method)
- make known the existence of. ( this is the real intent)
- to make discoverable
- make visible to all consumers on a fabric.
Does this summarize the concepts?
Anyone have a word that summarizes those?
Anyone care to try and make that into one or two sentences?
Duane
Francis McCabe wrote:
> 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
>> ***********
>>
>
--
***********
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
***********
