[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] another possible SOA diagram (revised)
Greg,
This is back to the question of how abstract we can remain vs. when is
something more specific needed vs. when is it too specific to be
included. I think just saying Contract is too abstract, partly because of
the context most people would usually attach. "Constraint" is probably a
better term.
BTW, even in your discussion, wouldn't a service interface be a policy
rather than a contract? Further, if a service interface exposes
information/constraint/policy/... and a consumer invokes the interface, do
we have to say a contract is established if there are no attached
restrictions other than the limits of the exposed data model?
Ken
At 10:24 AM 5/24/2005, Gregory A. Kohring wrote:
>Ken,
>
>I think you missed my point. The "Service Interface" is a concrete
>concept. Its abstraction is "Contract".
>
>The "service interface" should tell me what operations are supported,
>what data the operations work with and what faults might occur. This
>behavior is subsumed in the notion of "Contract"; hence it need not
>be mentioned explicitly, expect perhaps as a subbox within
>"Contract".
>
>-- Greg
>
>
>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
>
>--
>======================================================================
>G.A. Kohring
>C&C Research Laboratories, NEC Europe Ltd.
>======================================================================
--
---------------------------------------------------------------------------------
/ 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]