I’ll
admit that I certainly need time to digest all that is in this email.
What I find quite interesting is that the discussions on SOA have taken a
course through such a variety of disciplines. This parallels the
experience of the Face to Face meetings of the SOA Reference Model TC.
During these meetings, we spent a good deal of time talking about philosophy, linguistics,
religion and other seemingly non-related topics. However, to truly reach
a consensus of what, fundamentally are the core concepts and relationships of
SOA, we needed to walk through this web of relationships.
Rebekah
Rebekah Metz
Associate
Booz Allen Hamilton
Voice: (703) 377-1471
Fax: (703) 902-3457
-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Paul Prueitt
(ontologystream)
Sent: Wednesday, March 29, 2006 3:30 PM
To: 'Service-Oriented Architecture CoP'
Cc: psp@xxxxxxxxxxxxxxx
Subject: RE: [soa-forum] Business Need for SOA (Was SOA Semantic Variation )
Andrew and Cory, thank you for the wonderful communications.
Dear Colleagues,
I found this communication, from Andrew, and the recent ones to be
highly
revealing of core issues that are being addressed in refinement,
synthesis
and extension of the OASIS SOA and BCM specifications. One
take home
message from Andrew's note (below) is that (process) methodology is not
(fully) provided in SOA (Service Oriented Architecture). I
have the
opinion that BCM (business centric methodology) goes a long way towards
a
SOA methodology.
Knowledge Management suffers from some of the same
"localization" issues as
does SOA, and BCM. One can observe that the BCM
specification comes close
to localization in the extensive development of the notion of choice
point.
If one sees, as the second school does, a decision (natural decision
made by
real humans) as being a localization phenomenon; then one sees why
there is
a metaphor between the physical science of
quantum-theory/cognitive-mechanisms and SOA process modeling - as seen
in
the BCM specification.
See: http://www.bcngroup.org/area3/pprueitt/book.htm
for the second school's extended take on this metaphor and references
to
scholarly literature.
The collapse of the wave, to use this metaphor, related to the design
of
web-services (defined as Andrew's representation of Cory's usage)
occurs in
the mind of those few of use involved in developing international
standards
or in the development of (mainly) OWL (description logic based RDF
_expression_).
In this sense, the SOA is a localization of a common field experience
of
social/technical/economic reality BY a specific "community"
of individuals.
You said:
"SOA is not about distributed
objects."
And you are really very correct. Your perspective, as is mine, is
shaped by
your repeated engagement of the pattern recognition and interpretation
tasks
(often called "semantic extraction" since patterns are
recognized and then
given meaning using algorithms and/or human interpretation)
.
The BCNGroup (Behavioral Computational Neuroscience Group) Road map
addresses this task directly.
Ok, so I have said this before in this forum.
What I wanted to say this morning, respectful of the audience; is that
localization issues are THE core open questions of modern science.
These issues are hard issues, perhaps because localization requires
1) measurement
2) memory of invariance
3) agility
And, in the BCM terms usage, choice points. The second school
claims that
these issues are only properly addressed if one has a stratification
theory... as discussed in my work.
The second school proposition is simple.
We wish to move the origin of design (of information structure and
meaning
that might attach to distributed information structure) from where it
is
today to a new place.
It is observed by several of us that this transformation is essentially
a
cultural one (Mind map of BCM lays this out nicely)
www.businesscentricmethodology.com
The questions before the OASIS Technical Committees is about how the
choice
point methodology can be specified so that information structure is
produced
by non-IT specific viewpoint. We call this Human-centric
Information
Production or HIP.
Paul S Prueitt
-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S.
Townley
Sent: Tuesday, March 28, 2006 5:21 PM
To: Service-Oriented Architecture CoP
Subject: Re: [soa-forum] Business Need for SOA (Was SOA Semantic
Variation )
Hi Cory,
After spending considerably more time on this today than I planned
(when
it wasn't interrupted by "real" work and meetings), I
honestly think
we're trying to accomplish the same goals. However, I think there
are
currently two things which are possibly preventing clearer
communication.
First, I think we have a bit of a terminology impedance which is
actually caused by the second: different starting points to SOA
which
may have resulted in different perspectives. I believe that we
can get
around these issues. What I will do is walk through some of the
points
from the conversations over the last few days and then see if I managed
to catch the correct babel fish. However, there are still some
things I
don't understand. Please forgive me if I'm just being thick.
Based on your past published work [1,2,3], it is quite clear that
you've
put a lot of thinking into where you are now. It's also pretty
clear
that you've an extensive background with CORBA, UML and MDA.
>From what you've said, I think that this has had a distinct impact
on
how you view SOA. As you also said, you have seen and been a part
of
several SOA solutions implemented in CORBA.
If I understand what you've been saying over the last few emails, I
understand you to have the following definitions. I'm trying to
nail
these down so that I'm sure what you mean, and I don't make the wrong
assumptions. I realize you may think I'm silly, but I really
think it's
important to get straight.
community -- a pair of roles interacting for some purpose
role -- a task or responsibility within a community
interaction -- the means of communication between a role
community contract -- the constraints and manner of interaction between
a pair of roles using specified service interfaces
specification -- codification of a given community contract
SOA -- an architecture consisting of the following core elements:
- people and organizations
- roles and responsibilities
- interactions between roles
- community contract
service interface -- a set of methods exposed by a distributed object
(as exemplified by middleware technologies like RMI/IIOP, CORBA, DCOM,
.NET remoting and SOAP)
collaboration -- interactions between roles to realize a business
process
integration -- the combination of all of the elements defined by the
SOA
(above) to enable a collaboration
interoperability -- the level to which a role and service interface
conform to the interaction contract of the community within a
collaboration (implying some sort of shared context between the two
roles)
There are also a few terms that I'm not sure I understand from your
usage.
agility -- this is a term which has a number of different meanings,
depending on your context. Can you explain to me what you mean
by: "how
things work together for a common purpose while retaining
_agility_"?
architecture -- I think it's the environment in which all of the above
interactions take place, but I'm not really 100% sure from your usage.
If the above are right, or even close, I am now starting to see why
we've not been effectively communicating. :(
I have done a few distributed computing projects as well, including
some
with J2EE, CORBA, DCOM, .NET remoting and even some simple PDO things
under NEXTSTEP, XML-RPC and basic SOAP/1.1. So I am pretty well
versed
with the paradigm.
However, for the last 18 months, I've been implementing part of an
on-going SOA project based nearly exclusively on asynchronous
messaging. Based on this experience, and from reading everything
I
could find about Web services, loose coupling, messaging, ESB and SOA,
I've come to the distinct conclusion:
SOA is not about distributed objects.
This is a pretty fundamental notion on which we seem to differ, but
I'll
get to this in more detail as I go.
Even though I'm not in 100% agreement with all it says, the W3C Web
Services Architecture [4], along with the W3C Web Services Glossary
[5],
provide some useful, public definitions of terms. Like design
patterns
enable communication of architectural design concepts between software
architects and developers, it is useful to have a baseline vocabulary
when discussing these things. And for everyone in the wings with
a
semantics & ontology background, in case you were wondering, I
haven't
missed the irony of that last sentence. :) I have tried to make
the
terminology I use consistent with these definitions.
I'll not go into all of them, but, to me, SOA is about
"business"
services, but, like most things, what a "business" service
actually is
depends on your point of view. If you're part of the process that
implements or is responsible for the desired outcome, you probably see
all of the little steps required to carry it out. If you are not
part
of the process, you see the entire process as the service. This
is just
natural human abstraction when they don't know or don't really care
about the details.
For example, you (the requester) are hungry. Not knowing any
better,
you pull through the drive-up at McDonald's (the provider) and order a
value meal, pay your money (send a complex message), pull up to the
next
window and wait. Eventually, someone appears at the window with
your
cholesterol bomb (receipt of a complex message), and you drive away
happy.
This example seems to map to your definitions as the following:
you (the requestor) -> role #1
McD's (the provider) -> role #2
you + McD's -> the community
hanging out your car window and talking -> the interaction
giving your order (including the money) + receipt of food ->
community
contract
McD's window + your order + money + bag o food -> service interface
you ordering food from McD's -> collaboration
all of the above -> SOA
Using this simple scenario again, here's how I would define the various
bits (more-or-less from the WSA/WSG):
you -> the requestor
McD's -> the provider
ordering food -> the service
hanging out your car window and talking -> the transport
your order + money -> request
food -> response
send (any order for food + money); receive (food) -> service
interface
roads + traffic laws + houses + shops + fast food places -> SOA
Just to clarify some of these key differences a bit more. The way
I see
SOA is the environment in which a service exists. This service
can be
big or small, but it provides the same sort of granularity, regardless
of the business process being achieved--it is a business service.
Also, services can be complex or simple. If we were in the pub,
and I
asked you to go get me a burger, I'd give you my order plus some money
and get a burger back from you. I wouldn't care if you needed to
go to
three different places to find what I wanted (except that it might be
cold).
In this case, this would be a complex service (degenerate
case--specifically an intermediary) because you needed to do things on
my behalf. Later, I might also want to go to McD's directly, or I
could
ask you again. If life was really good, I could use the same data
in
both cases, e.g. both you and McD's would provide the same service
interface--enabling interoperability between service providers.
The SOA part kicks in when I can drive from McD's, to BK, to Wendy's to
Arby's, or wherever, and send the same message and expect the same
response. In W3C-speak, ordering food is the abstract service and
each
of the fast food places is a concrete implementation of that service
(an
agent). The SOA tells me how I can get from point to point, what
rules
I must follow, and maybe even gives me directions. It may also
allow me
to get fuel, buy a candy bar or even a newspaper--if those messages
existed and there was an agent implementing a service providing them.
The way I understand Web services and SOA is that they provide these
higher-level interfaces to business services, the invocation mechanism
and the messages exchanged. You get the interoperability because
you
*can* place the same order at all those places and expect, with minor
variations, to get the same thing back. If you don't, they don't
implement the same service interface.
I know these things sound very similar to what I suspect you
understand,
but to me, they are very different. Messages are not parameters
to
remote methods, and WSDL is not IDL. While you can use them that
way,
this doesn't buy you anything over any other type of distributed
objects
except unmolested access through port 80/443.
The business processes are the interactions between the requester and
provider (through their agents implemented in software), if they're
RPC-style interactions, one-way interactions, or a complex, long
running
choreography involving messages going from A -> B -> C -> D
-> A as a
directed graph. The business processes can be modeled on any
meaningful
level, but the type of centralized architectural view via MDA as I now
understand it (after today's research) isn't really there.
Yes, you have auditing and governance as part of the architecture, but
it's as a peer to peer set of interactions between organizational
entities. Only the provider *needs* to have a service interface,
because the requester can send the request and then ask for the
asynchronous response. They aren't objects.
Interoperability at that
point boils down to:
- agreement or following a published
business choreography
- agreement on the message data (or any
transformations)
- standardized or commoditized transport
If I want to book a flight, I provide the same information over the
phone, on the Web or in person to a travel agent. They all
implement
the same service interface, but the transport and agents are different.
To me, this is where you get the power of SOA, and the flexibility to
exchange messages with parties that weren't there yesterday.
I know you all now probably think I'm crazy, but does this make sense?
Is it the same or different than what your understanding is?
ast
[1]
http://www.idealliance.org/papers/xml02/dx_xml02/papers/03-02-04/03-02-04.pd
f
[2] http://www.semanticcore.org/requirements/InterfaceAdaptation.pdf
[3]
http://colab.cim3.net/file/work/SICoP/2006-02-09/Presentations/CCasanave0210
2006
[4] http://www.w3.org/TR/ws-arch/
[5] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
_________________________________________________________________
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP