On Dec 22, 2006, at 5:23 AM, Andrew S. Townley wrote:
Hi Ken,
With references back to Brad's granularity discussion, I still find the
idea of the W3C WSA's abstract and concrete services very useful in
practice when you're trying to address the ideas of interoperability,
QoS and functionality vs. a particular implementation of that
functionality. I'm not that big on a lot of the rest of the document,
but I think this is very good once you are talking about implementing a
business service as an IT deliverable.
However, I don't think "SOA service" is the best name for what you've
described. I'm not too sure what is at the moment, but I'll give it a
bit more thought. Off the top of my head, maybe "IT service" or
"technology service" or something like that. Like I said, I'll give it
more thought, but I don't think there's a clear enough link from "SOA
service" to "IT artifact" based on many of the underlying assumptions in
people's heads about what SOA means to them, based on where they are and
what they're trying to do with it.
I think it's also fair to say that things like QoS metrics can also be
applied to people-oriented or at least interactive human/machine
business processes as well, e.g. "The turnaround for a customer callback
after receiving a support request email must be within 1 hour", so I'm
not sure that's a sufficient enough differentiator either. In the above
case, if there's not enough people to support the volume of calls,
you're going to add more people, not technology to improve the QoS of
the business service. I know you know this, but I think it's important
to reiterate.
However, I do agree that there needs to be a good way to determine where
the line is between the abstract and the concrete IT implmentation based
on some agreed definition. I'm just not sure that you'll get much
traction with "SOA service".
I haven't had a chance to look at the ontology yet, but I hope to get a
chance to do this over the Christmas break.
Cheers,
ast
On Fri, 2006-12-22 at 00:49, Ken Laskey wrote:
One thing not addressed in the OASIS RM is to specifically
differentiate between a "business service" and a "SOA service". I
have a draft white paper on this that I never quite get around to
finishing but in general it appears useful:
- to use the OASIS RM idea of a SOA service to provide access to a
capability, and
- to relate the business service with the capability to which the SOA
service provides access.
In particular,
A business service is the functionality invoked in using a capability
designed and implemented to address certain needs, i.e. the solution
to a business problem. It implies actions. The real world effects of
using a business service are changes to the public aspects and/or the
user’s private aspects of the world in a way that has some positive
impact on those needs. The user may not be aware of private impacts
on others.
A SOA service is an IT artifact (i.e. a thing) that makes possible the
efficient connectivity between consumer needs and provider
capabilities. It provides a mechanism to access the capability of a
business service and to realize some subset of the real world effects
gained by interacting with the SOA service to access the business
service. As implied, the SOA service is not required to enable access
to all of the underlying capability’s potential real world effects. In
operational use, the SOA service is the entity that must conform to
such things as quality of service (QoS) metrics and the thing to be
fixed if these metrics are not met.
Comments welcome.
Ken
On Dec 21, 2006, at 9:20 AM, Brad Cox, Ph.D. wrote:
definitions of SOA are currently broadening to the point where
they
are not particularly useful any more.
The same debate raged in the 90's as to the 'real' meaning of
'object'. Of course the term is just as ambigious in everyday life
where the term originated and where it means quite different things
at different levels of granularity (subatomic, atomic, molecular,
biological, astronomical, etc).
Seems to me we could add a lot of clarity by specifying what level
of granularity "service" is being applied to. The article applies it
at the enterprise level so service = an organizational capabilitiy.
Several levels below that is the application level, where it means a
network-resident computer program; the meaning most technical folk
have in mind. Below that are the POJO objects from which
applications are usually composed these days (locally accessible
objects that are not on the network).
PS: I once tried to get traction on applying hardware engineering
terminology in software but that never caught on. Gate-level objects
= plain C functions, chip-level = C++/Java objects, card-level = SOA
services, and so forth. So it goes...
Joshua Lieberman wrote:
Dr. Harding,
Your interest in feedback for an SOA ontology is appreciated, but
taking a quick look at the definition of SOA on which it is based,
I have to raise the question why it includes only two of the three
legs on which service-based architecture was developed. The role
of service discovery, trading, and matching is conspicuously
absent. Indeed, this makes the ontology perfectly suitable for
modeling any application stovepipe and fails to explain why
efforts at interoperability, in fact at the information-hiding
aspects of services at all, are important.
It would certainly be very interesting to learn whether this
omission is deliberate or represents an intermediate stage of
ontology development. It might also be a good topic for SICoP
discussion. There is some question whether definitions of SOA are
currently broadening to the point where they are not particularly
useful any more.
Regards,
Joshua Lieberman
Principal, Traverse Technologies Inc.
tel +1 (617) 395-7766
fax: +1 (815) 717-981
On Dec 21, 2006, at 5:16 AM, Chris Harding wrote:
Hello -
The Open Group is developing a formal ontology for SOA, and we
have
now reached the stage where we have a draft that we would like
to
share with other organizations that are working on SOA, in order
to
obtain feedback and comment. We believe that a common ontology
for
SOA can be a very valuable resource for everyone to use, and we
therefore wish to receive input from as wide a constituency as
possible.
I think that this will be of interest to the SICoP as well as
the
SOACoP, and we would appreciate input from both groups. This
call for
input is going to both lists, and we would appreciate comments
from
all members of them, either directly to me
or to one or both of the lists. (Comments to both lists will
generate
the best debate!)
The current draft is draft 0.6 and is available from our web
page at
some
simple example ontologies that import it. Perhaps the best
starting
point is the presentation at
which I delivered at the recent OMG meeting. This explains the
ontology and how we think it will be used.
We will produce a new draft in January, and will address the
comments
in that draft.
All the best for Christmas and the New Year!
Regards,
Chris
+++++
========================================================================
Dr. Christopher J. Harding
Forum Director for SOA and Semantic Interoperability
THE OPEN GROUP
Thames Tower, 37-45 Station Road, Reading RG1 1LX, UK
Enterprise Architecture Practitioners Conference
Marriott Mission Valley, San Diego, CA, January 29 - 31, 2007
Member Meetings: January 29 - February 2, 2007
========================================================================
TOGAF is a trademark of The Open Group
_________________________________________________________________
------------------------------------------------------------------------
_________________________________________________________________
<bcox.vcf>
_________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Wiki:
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
______________________________________________________________________
_________________________________________________________________
--
_________________________________________________________________