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)


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                                              /
     ---------------------------------------------------------------------------------- 





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