[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
I would like to use the term "advertising" for now as a placeholder,
knowing full well we may all agree another term may be substituted
later. I think that we all conceptually agree that the premise is "to
make the existence of a service known to all consumers on a fabric" or
some variation and that "advertising" may or may not be the best term to
represent the abstract concept.
To recap, it seems that this concept is one of the pillars of SOA. It's
implementation may take many forms {(pull, push) (publish/subscribe)
(multi-cast, unicast, broadcast, point cast)(...)}.
That means that we have reached consensus (correct me if I am mistaken)
that the SOA RM contains the following elements:
1. Services
2. Service Descriptions
3. Advertising/whateverwecallit - the ability to make the existence of a
service and/or details thereof available to consumers on a fabric
4. Datamodel/whateverwecallit (includes the abstract notion of a set of
logical instances of data a.k.a. an abstract concept of a message,
possibly includes the concept of semantics)
We have not all agreed to the following things, but have no substantial
disagreement they are not in the SOA RM:
5. Contract - is it really a policy? Is it a core part of the reference
model. If it is a policy, does it imply the abstract functionality
represented in the security component of a concrete architecture?
The next set if items are likely not included in the core RM, yet may be
mentioned to illustrate functionality.
6. Service consumer
I am very impressed by the progress to date (assuming I have not jumped
too far to conclusions).
Duane
Smith, Martin wrote:
>Ken - -
>
>Register? (implies some official or at least "well known" place where things are registered.)
>Publish? (more general term without the commercial/spam connotation)
>
>To me, "advertise" implies "push"; register/discover and publish/subscribe are "pull." Advertise also implies use of a variety of communications methods, including registration (e.g., in the Yellow Pages) but also product placement, spam, etc. that might be considered dysfunctional.
>
>However, I have no problem putting aside this issue until (much) later.
>
>Martin
>
>________________________________
>
>From: Ken Laskey [mailto:klaskey@mitre.org]
>Sent: Mon 4/11/2005 9:28 PM
>To: Breininger, Kathryn R
>Cc: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org; scott@justiceintegration.com; Francis McCabe
>Subject: Re: [soa-rm] Architectural Scope of Reference Model
>
>
>
>I am of two minds as I compose this email. The first is could we
>replace "advertise" with something like "communicate the service
>description"? The second is let's call it advertise for now, see what
>it actually means, and then rename it if desirable later.
>
>Take your pick :-)
>
>Ken
>
>On Apr 11, 2005, at 4:06 PM, Breininger, Kathryn R wrote:
>
>
>
>>I also wonder about the term "advertising", especially given the
>>audience we are targeting for the high level document. "Advertising"
>>has an implied meaning to the average audience, whereas "Discovery"
>>implies I have found something through some means, often a search or
>>browsing or serendipity or even word of mouth (using the big picture
>>here that agents include humans). Does "advertising" limit the ways in
>>which I (or an agent) become aware of and use a service?
>>
>>
>>Kathryn Breininger
>>Boeing Library Services
>>425-965-0182 phone
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>>Sent: Monday, April 11, 2005 12:54 PM
>>To: Ken Laskey
>>Cc: Duane Nickull; Chiusano Joseph; scott@justiceintegration.com;
>>soa-rm@lists.oasis-open.org
>>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: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
>>>
>>>
>>> /
>>>
>>>
>>>
>>>
>>-----------------------------------------------------------------------
>>
>>
>>>-----------
>>>
>>>
>>>
>>>
>>
>>
>------------------------------------------------------------------------
>------------------
>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
***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]