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™.
>
>   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
>>>>>
>>>

soa-rm message