[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] another possible SOA diagram (revised)
Understood. This is very much what I had in mind by a resource. The problem may have been with my representation :-) Ken At 04:56 PM 5/24/2005, you wrote: >Well, I would not have done it precisely this way. > >The representation here seems like the realization of something. > >My take would be something like: > >resource: something that can take a set of numbers and return me the sum > >identifier: www.addnumbers.org > >representation: precondition: input is a list of numbers, effect: >output is their sum > >However, as with any resource, there are any number of possible >representations. (Just like you can have a photograph of RF's car, a >classified ad mentioning it, its VIN number, etc.) > >If we needed to layer services over resources, then the service >descriptions are representations of the service. > >One of the deep paradoxes of semantics is that you have to write down >something that is, by definition, not expressible. When saying that >the resource is "something that can take a set of numbers..." it is >not the string that we are trying to capture but the (fictional) real- >world entity that the string refers to. By definition, you cannot >write down resources; you can only describe them or otherwise point >to them. > >BTW, I think that this is the reason that the first logicians do in >modeling the world is to pretend it doesn't exist. (C.f. standard >models v.s. actual examples). > >Frank > >On May 24, 2005, at 1:40 PM, Ken Laskey wrote: > >>So am I correct in the following example: >> >>concept - something that can take a set of numbers and return me >>the sum >> >>identifier - www.addnumbers.org >> >>representation - >> sum = 0 >> until list is empty >> get next >> add next to sum >> repeat until >> send back result >> >>Ken >> >>At 04:26 PM 5/24/2005, Francis McCabe wrote: >> >>>We developed a resource model as part of the W3C WSA. That, in turn >>>was based on the REST architecture (abstracted a bit) by Roy >>>Fielding. >>> >>>However, at its heart, the resource model is both simple and subtle: >>>it is trying to nail down something that has been the source of a lot >>>of confusion (and superstition): the relationship between the names >>>of things and the things themselves. >>> >>>There are three concepts that, together, form the resource >>>conception: the concept of a resource, the concept of an identifier >>>(a.k.a. symbol, URL, bag'o'bits, etc.) and the concept of a >>>representation (a.k.a. image, sensation etc.). >>> >>>Once nailed down, you can then attach other properties to particular >>>kinds of resources: at one end you have ownership and at the other >>>end you have boulders, Web Services, and pictures of Roy Fielding's >>>car. (Sorry, in-joke). >>> >>>Frank >>> >>>On May 24, 2005, at 11:59 AM, Greg Kohring wrote: >>> >>> >>>>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 >>>>>>>>> >>>>>>> >>>> >>>> >>> >> >>-- >> >>---------------------------------------------------------------------- >>----------- >> / 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]