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
with
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
1520
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
______________________________________________________________________
_________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Wiki:
--
_________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Wiki:
------------------------------------------------------------------------------------------