[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] another possible SOA diagram (revised)
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 >>>>>> >>>>>> >>>> >>>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]