[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Duane:
I think that there is one major thing missing from your list; I am not
sure currently how to properly characterize it but I am referring to
the document centric processing model. Perhaps this fits in with your
datamodel; I am not sure.
One of the major constraints and drivers for scalability is the idea
of large grained communication or service invocation (however that it
done :))
Without this, SOA reduces to a generic distributed system.
Being more precise about document centric processing is difficult; but
I think it is something like there not being 1-1 mapping between
service requesters and service providers. In general it is 1-many; or
many-1 or even many-many; all held together by a common document.
In Web Service land, this was where intermediaries came in to play.
But, in reality what we are talking about is a separation between the
data that is communicated and the service(s) applied to it. That leads
to a concept of service composition, choreography, etc. etc.
Frank
On Apr 11, 2005, at 7:54 PM, Duane Nickull wrote:
> 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]