[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] another possible SOA diagram (revised)
I was planning to send this before Memorial Day weekend, but unfortunately got caught up in other things. Duane had asked me to provide information on OASIS Web Services Resource Framework (WSRF), and how it relates to our discussion on resources. In short, WSRF specifies a means for resources to be interacted with via Web Services. The WSRF TC[1] description states: "Defining an open framework for modeling and accessing stateful resources using Web services" Here are highlights from the most recent WS-Resource specification[2] (the primary WSRF specification): - The WS-Resource specification defines a WS-Resource, which describes the relationship between a Web service and a resource in the WS-Resource Framework. - It also defines the term "WS-Resource Access Pattern", the abstract concept of how resources are accessed through Web services, as well as several concrete embodiments based on various Web services referencing mechanisms. - The goal of WS-Resource is to standardize the terminology and concepts needed to express the relationship between Web services and resources. - A resource is a logical entity that has the following characteristics: * It MUST be identifiable; a resource has at least one resource identifier. * It MUST have a set of zero or more properties, which are expressible in XML infoset. * It MAY have a lifecycle. - A WS-Resource is a Web service through which a resource can be accessed. - An identifier of the resource MUST appear as part of any message to a WS-Resource to allow the WS-Resource to disambiguate the resource targeted by the message. - The term "WS-Resource Access Pattern" defines a concept describing how a Web service disambiguates which resource is targeted by a message to a WS-Resource. - The WS-ResourceProperties specification[3] standardizes the means by which the definition of the properties of a WS-Resource may be declared as part of a Web service interface. The declaration of the WS-Resource's properties represents a projection of or a view on the WS-Resource's state. - It also defines a standard set of message exchanges that allow a requestor to query or update the property values of the WS-Resource (i.e. GetResourceProperties, PutResourceProperties, InsertResourceProperties, UpdateResourceProperties) - An example of a "GetMultipleResourceProperties" message (p.9 of WS-ResourceProperties spec) specifies an interaction with a resource that is a disk drive, in which various properties such as the number of blocks on the disk drive are requested. Joe [1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf [2] http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-Resource-1.2-draft-03.pd f [3] http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-ResourceProperties-1.2-d raft-06.pdf Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Wednesday, May 25, 2005 11:34 AM > To: SOA-RM > Subject: Re: [soa-rm] another possible SOA diagram (revised) > > Joseph: > > Could you take the time to give us a brief synopsis of their > work and how it may fit? > > Duane > > Chiusano Joseph wrote: > > > We may want to check out what OASIS Web Services Resource Framework > > (WSRF) is doing in this regard. > > Joe > > > > > ---------------------------------------------------------------------- > > -- > > *From:* Greg Kohring [mailto:kohring@ccrl-nece.de] > > *Sent:* Tue 5/24/2005 2:59 PM > > *To:* Francis McCabe > > *Cc:* Ken Laskey; soa-rm@lists.oasis-open.org > > *Subject:* Re: [soa-rm] another possible SOA diagram (revised) > > > > 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(tm). > > > > > > 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]