[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] another possible SOA diagram (revised)
Sure Duane - I'll tackle that this evening. Stay tuned... Joe 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]