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