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