[no subject]

Which leaves us with an interesting conflict of definitions with regard to
definition of service as something that is not a resource....!

-Peter

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: 01 June 2005 16:48
To: Chiusano Joseph
Cc: SOA-RM
Subject: Re: [soa-rm] another possible SOA diagram (revised)

I can't help a small chuckle at this definition of a resource. What is
something that has zero properties?

On May 31, 2005, at 4:22 PM, Chiusano Joseph wrote:

> I was planning to send this before Memorial Day weekend, but 
> unfortunately got caught up in other things. Duane had asked me to 
> provide information on OASIS Web Services Resource Framework (WSRF), 
> and how it relates to our discussion on resources.
>
> In short, WSRF specifies a means for resources to be interacted with 
> via Web Services.
>
> The WSRF TC[1] description states: "Defining an open framework for 
> modeling and accessing stateful resources using Web services"
>
> Here are highlights from the most recent WS-Resource specification[2] 
> (the primary WSRF specification):
>
> - The WS-Resource specification defines a WS-Resource, which describes 
> the relationship between a Web service and a resource in the WS- 
> Resource Framework.
>
> - It also defines the term "WS-Resource Access Pattern", the abstract 
> concept of how resources are accessed through Web services, as well as 
> several concrete embodiments based on various Web services referencing 
> mechanisms.
>
> - The goal of WS-Resource is to standardize the terminology and 
> concepts needed to express the relationship between Web services and 
> resources.
>
> -  A resource is a logical entity that has the following
> characteristics:
> *  It MUST be identifiable; a resource has at least one resource 
> identifier.
> *  It MUST have a set of zero or more properties, which are 
> expressible in XML infoset.
> *  It MAY have a lifecycle.
>
> - A WS-Resource is a Web service through which a resource can be 
> accessed.
>
> - An identifier of the resource MUST appear as part of any message to 
> a WS-Resource to allow the WS-Resource to disambiguate the resource 
> targeted by the message.
>
> - The term "WS-Resource Access Pattern" defines a concept describing 
> how a Web service disambiguates which resource is targeted by a 
> message to a WS-Resource.
>
> - The WS-ResourceProperties specification[3] standardizes the means by 
> which the definition of the properties of a WS-Resource may be 
> declared as part of a Web service interface. The declaration of the 
> WS- Resource's properties represents a projection of or a view on the 
> WS-Resource's state.
>
> - It also defines a standard set of message exchanges that allow a 
> requestor to query or update the property values of the WS-Resource 
> (i.e. GetResourceProperties, PutResourceProperties, 
> InsertResourceProperties, UpdateResourceProperties)
>
> - An example of a "GetMultipleResourceProperties" message (p.9 of 
> WS-ResourceProperties spec) specifies an interaction with a resource 
> that is a disk drive, in which various properties such as the number 
> of blocks on the disk drive are requested.
>
> Joe
>
> [1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf
> [2]
> http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-Resource-1.2-
> draft-03.pd
> f
> [3]
> http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-
> ResourceProperties-1.2-d
> raft-06.pdf
>
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
> Kind Regards,
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
>
>> -----Original Message-----
>> From: Duane Nickull [mailto:dnickull@adobe.com]
>> Sent: Wednesday, May 25, 2005 11:34 AM
>> To: SOA-RM
>> Subject: Re: [soa-rm] another possible SOA diagram (revised)
>>
>> Joseph:
>>
>> Could you take the time to give us a brief synopsis of their work and 
>> how it may fit?
>>
>> Duane
>>
>> Chiusano Joseph wrote:
>>
>>
>>> We may want to check out what OASIS Web Services Resource Framework
>>> (WSRF) is doing in this regard.
>>> Joe
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> -
>>
>>> --
>>> *From:* Greg Kohring [mailto:kohring@ccrl-nece.de]
>>> *Sent:* Tue 5/24/2005 2:59 PM
>>> *To:* Francis McCabe
>>> *Cc:* Ken Laskey; soa-rm@lists.oasis-open.org
>>> *Subject:* Re: [soa-rm] another possible SOA diagram (revised)
>>>
>>> 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(tm).
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>
>