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