[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]