OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Noted.  This may be a rathole we can avoid.

Ken

At 12:00 PM 5/24/2005, 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                                              /
     ---------------------------------------------------------------------------------- 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]