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
> /
>
> -----------------------------------------------------------------------
> -----------
>
>
