Andrew and Cory, thank you for the wonderful communications. (01)
Dear Colleagues, (02)
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. (03)
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. (04)
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. (05)
See: http://www.bcngroup.org/area3/pprueitt/book.htm (06)
for the second school's extended take on this metaphor and references to
scholarly literature. (07)
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). (08)
In this sense, the SOA is a localization of a common field experience of
social/technical/economic reality BY a specific "community" of individuals. (09)
You said: (010)
"SOA is not about distributed objects." (011)
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) . (012)
The BCNGroup (Behavioral Computational Neuroscience Group) Road map
addresses this task directly. (013)
Ok, so I have said this before in this forum. (014)
What I wanted to say this morning, respectful of the audience; is that
localization issues are THE core open questions of modern science. (015)
These issues are hard issues, perhaps because localization requires (016)
1) measurement
2) memory of invariance
3) agility (017)
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. (018)
The second school proposition is simple. (019)
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. (020)
It is observed by several of us that this transformation is essentially a
cultural one (Mind map of BCM lays this out nicely) (021)
www.businesscentricmethodology.com (022)
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. (023)
Paul S Prueitt (024)
-----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 ) (025)
Hi Cory, (026)
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. (027)
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. (028)
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. (029)
>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. (030)
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. (031)
community -- a pair of roles interacting for some purpose (032)
role -- a task or responsibility within a community (033)
interaction -- the means of communication between a role (034)
community contract -- the constraints and manner of interaction between
a pair of roles using specified service interfaces (035)
specification -- codification of a given community contract (036)
SOA -- an architecture consisting of the following core elements:
- people and organizations
- roles and responsibilities
- interactions between roles
- community contract (037)
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) (038)
collaboration -- interactions between roles to realize a business
process (039)
integration -- the combination of all of the elements defined by the SOA
(above) to enable a collaboration (040)
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) (041)
There are also a few terms that I'm not sure I understand from your
usage. (042)
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_"? (043)
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. (044)
If the above are right, or even close, I am now starting to see why
we've not been effectively communicating. :( (045)
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. (046)
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: (047)
SOA is not about distributed objects. (048)
This is a pretty fundamental notion on which we seem to differ, but I'll
get to this in more detail as I go. (049)
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. (050)
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. (051)
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. (052)
This example seems to map to your definitions as the following: (053)
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 (054)
Using this simple scenario again, here's how I would define the various
bits (more-or-less from the WSA/WSG): (055)
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 (056)
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. (057)
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). (058)
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. (059)
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. (060)
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. (061)
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. (062)
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. (063)
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: (064)
- agreement or following a published business choreography
- agreement on the message data (or any transformations)
- standardized or commoditized transport (065)
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. (066)
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? (067)
ast (068)
[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/ (069)
_________________________________________________________________
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 (070)
|