Re: [soa-rm] another possible SOA diagram (revised)

[Ken Laskey <klaskey@mitre.org>]

Understood.  This is very much what I had in mind by a resource.

The problem may have been with my representation :-)

Ken

At 04:56 PM 5/24/2005, you wrote:
>Well, I would not have done it precisely this way.
>
>The representation here seems like the realization of something.
>
>My take would be something like:
>
>resource: something that can take a set of numbers and return me the sum
>
>identifier: www.addnumbers.org
>
>representation: precondition: input is a list of numbers, effect:
>output is their sum
>
>However, as with any resource, there are any number of possible
>representations. (Just like you can have a photograph of RF's car, a
>classified ad mentioning it, its VIN number, etc.)
>
>If we needed to layer services over resources, then the service
>descriptions are representations of the service.
>
>One of the deep paradoxes of semantics is that you have to write down
>something that is, by definition, not expressible. When saying that
>the resource is "something that can take a set of numbers..." it is
>not the string that we are trying to capture but the (fictional) real- 
>world entity that the string refers to. By definition, you cannot
>write down resources; you can only describe them or otherwise point
>to them.
>
>BTW, I think that this is the reason that the first logicians do in
>modeling the world is to pretend it doesn't exist. (C.f. standard
>models v.s. actual examples).
>
>Frank
>
>On May 24, 2005, at 1:40 PM, Ken Laskey wrote:
>
>>So am I correct in the following example:
>>
>>concept - something that can take a set of numbers and return me
>>the sum
>>
>>identifier - www.addnumbers.org
>>
>>representation -
>>   sum = 0
>>   until list is empty
>>     get next
>>     add next to sum
>>     repeat until
>>   send back result
>>
>>Ken
>>
>>At 04:26 PM 5/24/2005, Francis McCabe wrote:
>>
>>>We developed a resource model as part of the W3C WSA. That, in turn
>>>was based on the REST architecture (abstracted a bit) by Roy
>>>Fielding.
>>>
>>>However, at its heart, the resource model is both simple and subtle:
>>>it is trying to nail down something that has been the source of a lot
>>>of confusion (and superstition): the relationship between the names
>>>of things and the things themselves.
>>>
>>>There are three concepts that, together, form the resource
>>>conception: the concept of a resource, the concept of an identifier
>>>(a.k.a. symbol, URL, bag'o'bits, etc.) and the concept of a
>>>representation (a.k.a. image, sensation etc.).
>>>
>>>Once nailed down, you can then attach other properties to particular
>>>kinds of resources: at one end you have ownership and at the other
>>>end you have boulders, Web Services, and pictures of Roy Fielding's
>>>car. (Sorry, in-joke).
>>>
>>>Frank
>>>
>>>On May 24, 2005, at 11:59 AM, Greg Kohring wrote:
>>>
>>>
>>>>Fank,
>>>>
>>>>I like the idea of importing an RM for "resource". Can you recommend
>>>>one we can use?
>>>>
>>>>Greg
>>>>
>>>>
>>>>Francis McCabe wrote:
>>>>
>>>>
>>>>>Aaarrrgh ....
>>>>>   This was a big debate in the Web Services Description WG (WSDL
>>>>>2.0). About there being a resource behind the service.
>>>>>   This is the entirely spurious but very seductive idea of the
>>>>>one  true resource™.
>>>>>   For *some* people, it is right and appropriate for their
>>>>>application to think of the one true resource represented by
>>>>>their  service. But it is certainly not the general case; many
>>>>>services have  the character of filters (e.g., unit conversion
>>>>>services, ATM  machines, encryption services) which are not
>>>>>primarily concerned with  their own resources. Other services are
>>>>>all about *combining*  resources e.g., selling and delivering
>>>>>books, subscription and  notification services.
>>>>>   From other perspectives (e.g., service management, policy
>>>>>enforcement, deployment, etc. etc.), the service itself *is* a
>>>>>resource that has an existence independent of other resources it
>>>>>manipulates. For example, resources are *things* that can be
>>>>>bought;  and a service certainly meets that criteria.
>>>>>  Personally, I believe that all of this stuff on resources does
>>>>>not  belong in a SOA RM; the reason: resources have their own
>>>>>modeling and  we can simply layer on top of the concept.
>>>>>Frank
>>>>>On May 23, 2005, at 3:28 PM, Ken Laskey wrote:
>>>>>
>>>>>
>>>>>>Greg - see below
>>>>>>
>>>>>>At 02:33 PM 5/23/2005, Greg Kohring wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Sorry, but this diagram has a few problems.
>>>>>>>
>>>>>>>1) A "Service Interface" is a concrete representation of some of
>>>>>>>the
>>>>>>>constraints detailed in the contract; i.e., it is too concrete
>>>>>>>for
>>>>>>>being mentioned so prominently in a reference model.
>>>>>>>
>>>>>>
>>>>>>The service interface is more a representation of the data model
>>>>>>than a constraint, and I am referring to an unambiguous
>>>>>>prescription of the interface and not the implementing code.  A
>>>>>>such, I'd see it no more concrete than the specification of a
>>>>>>policy.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>2) It is the service that is the resource, not the service
>>>>>>>description.
>>>>>>>
>>>>>>
>>>>>>It has been a while since I read WSA, so my apologies if my use
>>>>>>of  the terms is different.  I see the resource as being
>>>>>>something that  provides something I need, whether data or
>>>>>>processing.  I see the  service as a means to gain access to the
>>>>>>resource but the resource  exists independent of the service.
>>>>>>Many services may access the  same resource, e.g. for different
>>>>>>guaranteed quality of service.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>While it is certainly true that every service is a resource, the
>>>>>>>converse is not true.
>>>>>>>
>>>>>>
>>>>>>Again, this may go against past WSA work but I do not consider a
>>>>>>service to be a resource.  It is one means of accessing a
>>>>>>resource.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>You might even define an SOA is an architecture
>>>>>>>in which all resources are either themselves services or can
>>>>>>>only be
>>>>>>>accessed through services (i.e., they are part of the service's
>>>>>>>data
>>>>>>>model). Therefore, if your architecture only consists
>>>>>>>of services, you need not mention resources explicitly.
>>>>>>>
>>>>>>>-- Greg
>>>>>>>
>>>>>>>
>>>>>>>Ken Laskey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>The resource is the implementation that in many cases was
>>>>>>>>created  to satisfy needs outside the SOA and only becomes part
>>>>>>>>of a SOA  in the same way that any software package becomes
>>>>>>>>part of your  computer.  Opacity says you know there is a
>>>>>>>>resource but the only  thing you know about it is what is
>>>>>>>>exposed through the service  description.
>>>>>>>>Attached is a very quick attempt to include in Duane's last
>>>>>>>>diagram.
>>>>>>>>Ken
>>>>>>>>
>>>>>>>>On May 23, 2005, at 9:18 AM, Christopher Bashioum wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>  OK - that makes sense.  In fact, I remember a book on SOA
>>>>>>>>>patterns  that
>>>>>>>>>talks about this (forgot the title, but the author is Paul
>>>>>>>>>Monday).
>>>>>>>>>In his
>>>>>>>>>view, what you are referring to as a service he would refer
>>>>>>>>>to  as an
>>>>>>>>>architecture adapter.  I.e., the implementation (resource) is
>>>>>>>>>done in a
>>>>>>>>>particular architural style.  In order to adapt that
>>>>>>>>>implementation to  the
>>>>>>>>>SOA architectural style one would us an architecture
>>>>>>>>>adapter.   (at  least
>>>>>>>>>that's what I got from his book - I may have misunderstood).
>>>>>>>>>
>>>>>>>>>So ... A second question for you -  do you think we need to
>>>>>>>>>add a
>>>>>>>>>resource
>>>>>>>>>box to the diagram that Duane sent out?  If so, what would
>>>>>>>>>be the
>>>>>>>>>relationship between the resource and the service?
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Ken Laskey [mailto:klaskey@mitre.org]
>>>>>>>>>Sent: Monday, May 23, 2005 9:11 AM
>>>>>>>>>To: Christopher Bashioum
>>>>>>>>>Cc: 'SOA-RM'
>>>>>>>>>Subject: Re: [soa-rm] another possible SOA diagram (revised)
>>>>>>>>>
>>>>>>>>>The resource is the real thing out there that provides a
>>>>>>>>>capability --
>>>>>>>>>in the 07 draft, there is a discussion of data resources vs.
>>>>>>>>>processing
>>>>>>>>>resources.  In general, a resource does not have to be
>>>>>>>>>service- enabled.
>>>>>>>>>   However for SOA, the resource must have (we can continue to
>>>>>>>>>debate
>>>>>>>>>this) a service interface that is one of the things published
>>>>>>>>>through
>>>>>>>>>the service description, and that service interface is how
>>>>>>>>>you  connect
>>>>>>>>>the resource to the underlying service infrastructure.
>>>>>>>>>Additionally,
>>>>>>>>>the service infrastructure has to provide certain TBD
>>>>>>>>>capabilities and
>>>>>>>>>likely overlaps but is not necessarily the same as what is
>>>>>>>>>often  termed
>>>>>>>>>an ESB bus.
>>>>>>>>>
>>>>>>>>>Ken
>>>>>>>>>
>>>>>>>>>On May 23, 2005, at 8:53 AM, Christopher Bashioum wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Ken,
>>>>>>>>>>
>>>>>>>>>>Intuitively, I like this one.  One question: how is the
>>>>>>>>>>resource
>>>>>>>>>>different
>>>>>>>>>>than the service?  Also, for the TC to use, we may be able
>>>>>>>>>>to  identify
>>>>>>>>>>the
>>>>>>>>>>essential elements with a * and then the other optional
>>>>>>>>>>elements to
>>>>>>>>>>show
>>>>>>>>>>where they fit (for example, I see basic logging as non-
>>>>>>>>>>essential, but
>>>>>>>>>>this
>>>>>>>>>>diagram shows where it fits).
>>>>>>>>>>
>>>>>>>>>>The diagram may not show up in the actual RM doc, but it may
>>>>>>>>>>be  useful
>>>>>>>>>>for
>>>>>>>>>>us as a conceptual model.
>>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: Ken Laskey [mailto:klaskey@mitre.org]
>>>>>>>>>>Sent: Monday, May 23, 2005 12:43 AM
>>>>>>>>>>To: 'SOA-RM'
>>>>>>>>>>Subject: [soa-rm] another possible SOA diagram (revised)
>>>>>>>>>>
>>>>>>>>>>I played with the ideas in the sketch a bit more.  As noted
>>>>>>>>>>in the
>>>>>>>>>>previous email:
>>>>>>>>>>
>>>>>>>>>>I would not necessarily advocate it being used instead of
>>>>>>>>>>the  one  Duane
>>>>>>>>>>drew but given I had it, I thought I'd pass it around for
>>>>>>>>>>comments.
>>>>>>>>>>The 3D presentation may make it look too concrete but I was
>>>>>>>>>>looking  for
>>>>>>>>>>a way to show there was something SOA I was building
>>>>>>>>>>services  on and
>>>>>>>>>>there could be any number of services.  Note a resource could
>>>>>>>>>>be a
>>>>>>>>>>registry but even that would be exposed through services and
>>>>>>>>>>have
>>>>>>>>>>metadata.
>>>>>>>>>>
>>>>>>>>>>Ken
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>--------------------------------------------------------------- -- 
>>>>>>>>>-- ---- -
>>>>>>>>>------------------
>>>>>>>>>Ken Laskey
>>>>>>>>>MITRE Corporation, M/S H305     phone:  703-983-7934
>>>>>>>>>7515 Colshire Drive                        fax:
>>>>>>>>>703-983-1379
>>>>>>>>>McLean VA 22102-7508
>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>>--
>>
>>---------------------------------------------------------------------- 
>>-----------
>>   /   Ken
>>Laskey
>>\
>>  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
>>  |    7515 Colshire Drive                    fax:
>>703-983-1379   |
>>   \   McLean VA
>>22102-7508                                              /
>>
>>---------------------------------------------------------------------- 
>>------------
>>
>>
>

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------