Re: [soa-rm] another possible SOA diagram (revised)

[Duane Nickull <dnickull@adobe.com>]

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™.
> >
> > 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
> >>>>>
> >>>
>
>