If your SOA is silly enough to use reverse engineering as a preferred
method of advertisement (via discovery), then more power to you. Don't
expect much career wise though :-)
-matt
Francis McCabe wrote:
> 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 /
>>
>> -----------------------------------------------------------------------
>> -----------
>>
>>
>
