Duane,
Thanks for the reference and I will try to read it before it disappears
into the usual reading stack :-)
I am hesitant to enable a mechanism that looks like more advertising
spam but I guess it isn't up to me to make such judgments. It would be
interesting to think how this may interact with a notional
infrastructure element that would monitor the SOA for such things as a
service heartbeat.
More after I've read the WS-Discovery spec.
Ken
On Apr 19, 2005, at 11:21 AM, Duane Nickull wrote:
> Ken:
>
> I wanted to answer this one directly. Please excuse the time gap
> (traveling).
>
> It would not and must not preclude any model for discovery or any
> aspect of it. If there is a need, a service should be able to make
> the details available that allow the discoverer to determine if the
> service matches their needs.
>
> There is an interesting model in WS-Discovery where advertising is
> facilitated by a service or agent (on behalf of) sending out a "hello"
> message, essentially stating "I am here". Subsequently, the hello
> message recipient can query for further details. In that model, the
> information advertised for discovery may not use the same model for
> the entire process. It is a combination of many methodologies (Push,
> Parse, Pull, Parse).
> In other architectures, a model of publish subscribe that directly
> references all business materials facilitates the "need" part of
> discovery.
>
> This is worth a read too:
> http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-
> discovery.pdf
>
> Cheers
>
> Duane
>
>
> Ken Laskey wrote:
>
>> Does this preclude the case of making the need discoverable and
>> having the service find it?
>>
>> What about the entity/organization that uses advertising outside of
>> SOA to make itself known and expects others will find its services
>> by coming specifically to it? After that point, the SOA mechanisms
>> would come into play.
>>
>> Ken
>>
>> On Apr 12, 2005, at 7: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
>>> ***********
>>>
>>>
>> ----------------------------------------------------------------------
>> -- ------------------
>> Ken Laskey
>> MITRE Corporation, M/S H305 phone: 703-983-7934
>> 7515 Colshire Drive fax: 703-983-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-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
