[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
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:scott@justiceintegration.com]
>> Sent: Wednesday, March 30, 2005 12:44 PM
>> To: soa-rm@lists.oasis-open.org
>> 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
>> scott@justiceintegration.com
>> 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 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]