-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
Sent: Thursday, March 30, 2006 9:48 AM
To: Service-Oriented Architecture CoP
Subject: RE: [soa-forum] Business Need for SOA (Was SOA Semantic Variation )
Ok, some sleep helped a little. I think the answer is to figure out
what SOA *really* is (as I believe was suggested eralier).
Advance warning: I'm not really going to be talking about technology
at
all, and I'm going to relate a few things which some may find a bit
tangential. However, I think if we can solve this, the rest is going
to
be a lot easier.
[->] <snip
for proximity of reply to the top of the message>
When the system is working correctly, very little interaction with the
codified principles of legitimacy within the community (laws) is
necessary by the participants. I'm sure not many of us could, from
memory, list the exact details of the laws that exist in a locality,
let
alone on a larger scale such as a state or a nation, but that fact does
not generally prevent us from going about our daily business. Thus, I
posit that this is primarily because we subscribe to the legitimacy
principles of the communities in which we participate.
[->]
Actually, I’m wondering about the interaction you discuss here. A few
thoughts come to mind:
1) It
isn’t that there is very little interaction. Rather, it is that the
interaction is already implicit in their actions. As you mentioned above, “People
who understand legitimacy in a community normally don't have to be told what is
right and what is wrong for every decision they make. When implemented
properly, everyone's actions generally reinforce the legitimacy of the
community, thus contributing to the reinforcing system described above.” Of
course, assuming some semblance of democracy within a community – i.e.,
the codified legitimacy of the community represents with reasonably accuracy what
the participants in the community internally value as legitimacy.
2)
This leads to complex systems whereas the behavior of the overall system
emerges from interaction of all the behaviors of the individual participants
within community. This is somewhat a fuzziness factor. Therefore, it may be
that the community within which we participate exemplifies the principles of
the participants. Your statement suggests a more concrete choice and I’m
not 100% convinced that is the only way to look at it.
If this is accepted, then what are the outcomes of the community? The
main one is that the members of the community are fairly autonomous.
Either implicitly or explicitly, they understand the context in which
they operate, altering their behavior to conform to the legitimacy
principles required for the various communities in which they
participate. Before long, this alteration happens automatically,
without conscious thought from the participants. Do you talk to your
mother the same way you talk to your friends? (I do, because I have a
cool mom, but most people probably don't. This behavior is an example
of what I'm talking about).
One of the largest benefits of autonomy is the ability to work
co-operatively to accomplish a larger goal. However, this
"directed" or
"cooperative autonomy" is only effective if everyone fully
understands
what they are supposed to do and have the ability to do it.
[->]
I agree with your assertion of directed vs. cooperative autonomy. I believe
there is a continuum between these two extremes. I would liken the first to
the hierarchical structure of the military and the second to a think tank or
research institution. What we see though is that there are a range of
organizational (community) structures that work in between these extremes. My
sense is that within those various organizational structures; not everyone
fully understands what they are supposed to do, nor do they have the ability to
fully do it. Nevertheless, the overall organization can be successful. Essentially,
the community becomes self-healing.
Bringing all this back a little closer to the topic at hand, the degree
of autonomy in a system is directly proportional to the scalability of
that system. I have elaborated on this concept from a messaging point
of view [3]. However, what struck me this morning when I was thinking
about this conversation was this relationship:
scalability => autonomy => legitimacy
Or, that in a system, scalability implies a certain amount of autonomy,
but that this autonomy is only possible if the autonomous entity has an
awareness of and subscription to the legitimacy principles of the
community in which they are participating.
[->]
This seems to track fairly well with the concept of Execution Context in the
SOA Reference Model from OASIS. Really, the legitimacy principles only help to
set the context for a particular interaction – hence adaptability and
flexibility – two of the sexy SOA terms we see much pontificating around,
but are still working on how that translates into executing SOA.
Bringing this back even closer to the current discussion, my use of the
road metaphor in the earlier mail was a better of example of this
thought than I realized. I said:
> > 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 execution context, the policy and the service description tell you these
things. I agree that the agent is actually the implement. However, we need to
be careful (lexically speaking) about phrasing and words which conceptualize a
service as an independent entity. Service is both a verb and a noun. The way
the word is used often causes semantic mismatch in how the listener understands
the usage. SOA as a technical discipline should really be though about in
terms of how the ‘active’ and ‘actual’ come together as
part of an approach to organizing technical assets into capabilities which meet
business needs.
Relating the architecture of the SOA back to the society in which we
live and adding in the concept of legitimacy, the traffic laws say
where
and when we can drive from point to point. Mostly, people obey these
laws, but I would say that the most fundamental ones (speed limits
don't
count here :D) are "obeyed" less because they are laws, but
more because
they resonate with our innate sense of fairness.
[->]
What I like about your train of thought is the recognition that SOA encompasses
both a technical and a ‘business’ (I use the word real) aspect. In
fact, SOA is about dualities (technical, business); (need, capability); (verb,
noun) and (conceptual, physical) to name a few.
So, these are the reasons that I actually don't agree with you that
requestor/provider roles/concepts are too low-level within the context
of the SOA. To me, these provide the power of the SOA. This leads me
to conclude that the architectural constraints of the SOA define the
legitimacy principles of the environment, in a similar manner to the
way
Whitworth and de Moor say that the programmer is ultimately defining
the
legitimacy principles of the social interaction systems they design and
build [1].
If a framework for what is and is not legitimate within the SOA
community is defined, the participants within that community are free
to
be autonomous within that community as long as they follow the rules.
This autonomy within the community allows the community to scale in the
same manner as the Internet [3].
[->]
In my mind, this is the essence of the execution context (description, policy,
etc) because it defines the rules that apply.
Note as well that these rules of legitimacy are not restricted to the
software agents acting within the community. It also applies to the
manner in which the human participants interact with each other and
with
the software agents as part of the community. This is a model that has
been proven to work (to various degrees) in both computer systems (the
Internet) and society. Managing autonomy is harder than some of the
alternatives, however it is the only way to provide sufficient
scalability within the community to accomplish anything meaningful.
The
balancing system at work here is dealing with those that don't conform
to the legitimacy principles. Once these cases are identified, steps
are taken to augment the framework, and life goes on.
[->]
One of the discussions I like to have regarding SOA is in a similar vein: SOA
is about applying the rules of reality to technology. I use the following example:
the emergence of the trading system. This works well for me in a number of
different ways. First, it reinforces how much time we as a human race have spent
evolving this system. Sometimes, when we talk about the evolution of SOA, the organic
time perspective can be lost. Second, it recognizes the invisible infrastructure
that we almost take for granted today – e.g. routine maintenance on
docks, the trucking industry, the banking industry, the check clearing and
money transfer industry, etc. All of these capabilities are necessary and
without which the ability to bring together a product (say an iPod) or a action
(say a manicure) as a capability to respond a particular need. Third, it speaks
to the role of globalization and boundaries. We have trade agreements,
treaties, zones, laws, legislation, process and so on which support the relatively
free flow of goods and services across boundaries. In the ‘real world’
we often think of these boundaries in a political sense. There are other
legitimate boundaries such as language boundaries. That said, there is time,
effort and expense in reaching a common understanding on both sides of the
boundary to allow that boundary to be crossed. It doesn’t require that
each side have exactly the same understanding, only that the understanding on
each side is compatible with the others.
This is exactly what happens between government and the governed. If
one sees the other violating the community's legitimacy principles past
a tolerance point, action is taken--in either direction--to re-balance
the environment. I believe that this is the model that SOA must follow
if it is to be successful.
[->]
Yes! SOA is about more than just the technology, it’s also about process
and intent.
In large deployments with hundreds of services, thousands of people and
millions of messages, it has to have the ability to adapt on its own
behalf--within the framework that defines the architecture of the
community. When this behavior does not occur, the scalability, and
therefore the effectiveness of the architectural style, becomes
constrained. If that happens, we'll be here in another 5-10 years
arguing about the "next big thing" vs. "the last big
thing" because we
will have reached a point where the SOA model is no longer useful.
[->]
It may be that we’re working on the next big technology model, but the
service based model has proven itself out quite well in the real world and
think that over time we’ll see the technology realization of this model
evolve in a similar way – slowly and based on economic need, personality,
and sometimes randomness =)
As the Internet has proven, I think it is possible for this type of
community architecture to exist. We just can't repeat some of the
mistakes of the Web which did not consider the legitimacy concerns of
the participants and which has led to some of the issues we have
today's
society (e.g. widespread identity theft and fraud).
[->] But we’re
also not starting from scratch each time either. We build upon what we learn
and have internalized as knowledge.
By allowing the business processes and roles (as you use the term) to
fully participate in this community *as peers*, I believe that SOA is
an
architectural style which can achieve the business needs of
collaboration, integration and agility. We just have to create the
right community.
[->]
And align our technical assets to the objectives of that community.
ast
[->]
Now that I’m reading backwards into the thread, I may have additional
thoughts on earlier statements as well. That said, this has been an interesting
and insightful dialogue. I look forward to jumping in with more frequency in
the future.
Rebekah
[1] http://www.starlab.vub.ac.be/staff/ademoor/papers/bit03.pdf
[2] http://atownley.org/published/2005/06/ISB1005AST.pdf
[3]
http://atownley.org/2006/03/self-directed-messages-the-key-to-scalable-soa/
On Wed, 2006-03-29 at 18:49, Cory Casanave wrote:
> Andrew,
> Thanks for your comprehensive response, we are certainly
attempting to
> realize the same goals, perhaps with slightly different
terminology and a
> few different conclusions. I'm going to pick out a couple of your
> statements to reply to directly...
> >
> > SOA is not about distributed objects.
> >
> Absolutely and violently agree. It actually disturbs me that you
think I
> think it is, I will have to look back on the prior communications
to see
> where this came from.
> >
> > 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.
> >
> Absolutely agree - SOA is the business architecture (where the
business is
> understood as providing and using business services). This
business
> architecture MAY be realized with distributed objects or with an
event
> service or with paper flowing between in/out baskets.
> We MAY map the business interactions to one of these
technologies. People
> who DO think if architecture in terms of technology services are
looking for
> something like an Corba-IDL or WSDL interface - to map business
interactions
> to this paradigm we talk about "service interfaces" as
the way these
> paradigms MAY be used to REALIZE the SOA architecture.
> >
> > 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
> >
> Don't agree - the requester/provider mindset if to low-level for
business
> interactions - it really comes from the OO think we are both
trying to rise
> above. Business interactions are inherently bi-directional,
asynchronous
> (as you have said) and long-lived. Information flow may be
initiated from
> either side, within the constraints of the choreography of that
interaction.
> They are frequently complex and composed of finer grain
interactions. There
> are roles in these interactions and you can frequently identify
one as the
> "initiator", but expecting a request/reply paradigm is
not business centric.
> As said above, we may MAP the business centric interaction to one
or more
> request/reply service interfaces.
>
> Since you took the time to write down some great definitions I
have provided
> some corrections (since you said they were my definitions).
> >
> > community -- a pair of roles interacting for some purpose
> >
> community -- a set of roles interacting for some purpose
>
> > role -- a task or responsibility within a community
> >
> role -- a logical grouping of a set of responsibilities within a
community
>
> > interaction -- the means of communication between a role
> >
> interaction -- the means of communication between actors playing
roles
>
> > community contract -- the constraints and manner of
interaction between
> > a pair of roles using specified service interfaces
> community contract -- the purpose, constraints and manner of
interactions
> within a community
>
> > Specification -- codification of a given community contract
> Specification -- codification of a given contract
>
> >
> > SOA -- an architecture consisting of the following core
elements:
> > - people and organizations
> > - roles and responsibilities
> > - interactions between roles
> > - community contract
> >
> >
> SOA -- an architectural style for achieving collaborative work
that can be
> specified using a community contract containing the following core
elements:
> - roles and responsibilities
> - interactions between roles
> - business rules and constraints
> - a model (or ontology) of the domain
>
> > 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)
>
> This is ok, but is a possible derivative of the SOA, not the
subject of the
> SOA.
>
> >
> > 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)
>
> Interoperability - the ability for business units, people or systems
to
> exchange information in support of a common purpose.
>
> >
> > 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_"?
>
> Agility - the ability for new objectives, whether driven by
business,
> mission or technology, to be realized quickly and inexpensively.
>
> >
> > 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.
> >
> Architecture - the design of systems; where systems may be
organizational,
> legal, physical, processes or processing systems.
>
> -----------
> So, now it is clear we are BOTH crazy! I wonder if anyone else is
still
> listening?
>
> -Cory
>
> > -----Original Message-----
> > From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
> > bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> > Sent: Tuesday, March 28, 2006 8: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.pdf
> > [2]
http://www.semanticcore.org/requirements/InterfaceAdaptation.pdf
> > [3] http://colab.cim3.net/file/work/SICoP/2006-02-
> > 09/Presentations/CCasanave02102006
> > [4] http://www.w3.org/TR/ws-arch/
> > [5] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
> >
> > On Mon, 2006-03-27 at 23:20, Cory Casanave wrote:
> > > Andrew,
> > > One think I suspect we can all agree on is that there
are multiple
> > > applications for SOA. Perhaps a little more background
on the kinds of
> > > problems we are trying to solve would be appropriate,
below is our
> focus.
> > >
> >
> > > Business Need; Collaboration and integration
> > >
> >
> > > The idea of an isolated company, organization, mission
or application
> > has
> > > become the exception. It is simply impractical to think
of what you or
> > your
> > > organization offers without considering the environment
in which it is
> > > offered and performed. Businesses have their supply
chains, value
> > chains
> > > and business processes. Defense has joint missions and
collaborative
> > > forces. Applications require integration and
interoperability.
> > >
> >
> > > In each case the problem is; how to all these things
work together? The
> > > problems is also that how it works together is a dynamic
environment as
> > > parts and pieces get outsourced, insourced, or
modified. The problem is
> > > also that most solutions to enabling these things to
work together get
> > tied
> > > to particular processes, information or technologies
such that it
> > becomes
> > > brittle and inflexible.
> > >
> >
> > > This is the problem we wish to address - how things work
together for a
> > > common purpose while retaining agility. This problem
exists at many
> > levels,
> > > from a worldwide scale where there is collaboration
between countries
> > and/or
> > > major organizations to how people work together within a
department.
> > These
> > > "big" collaborations are realized by smaller
and still smaller
> > > collaborations - until you have a small group executing
their specific
> > > "business process" on their specific
information to realize their part
> > in
> > > the larger picture.
> > >
> >
> > > A community may be small or large, the smallest being a
pair of roles
> > > interacting for some purpose, the most common example
being a retail
> > > purchase - buyer and seller. But communities are often
large, such as
> > the
> > > financial management community of a large enterprise.
> > >
> >
> > > Where people, organizations, missions or countries work
together for a
> > > common purpose - there must be some element of
agreement, some implicit
> > or
> > > explicit understanding of how they are going to work
together for that
> > > purpose. That agreement may be a simple sales agreement
to a complex
> > > multi-lateral collaboration of many parties. We express
this by saying
> > that
> > > people and organizations are actors playing roles with
given
> > > responsibilities within a community and they enact their
common purpose
> > by
> > > behaving and interacting according to the contract of
that community.
> > > This is the architecture of that community.
> > >
> >
> > > We can also look at this community of actors playing
roles as each
> > providing
> > > a service to the community - this is the
"larger" view of service, more
> > akin
> > > to a business service - like maintaining a fleet of
vehicles. Thus the
> > > architecture of the community is the business view of
the "Service
> > Oriented
> > > Architecture".
> > > Note: This kind of business service of an actor playing
a role in a
> > > community is related to, but not the same as the service
interfaces one
> > > finds in middleware technologies, such as web services.
> > >
> >
> > > Between these actors playing roles there are
interactions - these
> > > interactions are frequently bi-directional,
asynchronous, choreographed
> > and
> > > long-lived. They represent the
"conversations" between the parties
> > playing
> > > the roles. Each of these conversations generally correspond
a pair of
> > > service interfaces, one for each side of the
conversation. These
> > service
> > > interfaces can be instrumented in technology, and when
they are, you
> > have
> > > provided a vehicle for that community to operate more
efficiently and
> > > openly. You have provided a way for the "business
process" of the
> > community
> > > to happen without any special monitor or control, but as
the natural
> > > progression of actors playing their role based on the
community process.
> > >
> >
> > > So for us, from the perspective of a
"community" the interesting
> > > architecture is how all of these actors work together,
and by extension,
> > how
> > > all the services work together for a business purpose.
A single
> service,
> > > out of context, can provide value - but an architecture
of a community
> > of
> > > roles and services can transform an enterprise or
influence a society.
> > >
> >
> > > It is this kind of community we would like to
demonstrate - how it can
> > be
> > > described, architected and realized with SOA. The
paradigm we use to do
> > > this brings together standards based collaboration
modeling (Based on
> > > OMG-EDOC), information modeling (Based on UML) and
process modeling into
> > a
> > > cohesive architecture for a community.
> > >
> >
> > > A specific example is an architecture we have just done
for the GSA'a
> > CFO
> > > for their Financial Management Line of Business - how
can GSA organize
> > to
> > > provide financial management services within GSA and
externally. This
> > is
> > > what we would consider an SAO in that it describes these
communities,
> > the
> > > roles and interactions, the information models and
processes. (You may
> > also
> > > consider that this is more than an SOA in that it also
shows how some of
> > the
> > > roles are implemented, but at the top is the SOA). This
SOA does not
> > > mention any systems, middleware or technology - it is
how the business
> > is
> > > understood as collaborating business services. We then
derive (Using
> > MDA),
> > > how middleware services interfaces can help realize and
implement these
> > > communities. There are about 60 roles and hundreds of
service
> > interfaces in
> > > this architecture (not monolithically, they can be
understood in smaller
> > > pieces).
> >
> > >
> >
> > > So, this kind of architecture for a community where the
goal is to
> > > understand how roles interact using service interfaces
to achieve a
> > common
> > > purpose is a great way to utilize SOA. It allows
different actors,
> > > technologies, systems and processes to be used
"under the covers" to
> > help
> > > the actors play their role. This kind of community
simply does not
> > function
> > > without some agreement of this kind, without a community
contract. You
> > > can't do "financial management" one WSDL
interface at a time.
> > >
> >
> > > This kind of community architecture can be
differentiated from
> > applications
> > > where a single "web service" can supply a
unique capability without this
> > > kind of context. These, of course, exist and can
provide value - it is
> > > another application of SOA. But the architecture here
is focused on the
> > > individual service interface, less so on the environment
or community.
> >
> > >
> >
> > > The demo outline we presented is a minimalist and simple
community, but
> > > intended to show this community effect based on the
business need for
> > > collaboration and integration. You could, of course,
come up with any
> > > number of communities to demo. Another kind of demo
could be based on
> > other
> > > business needs or approaches to applying MDA - I think
some of the other
> > > ideas are more along this line. Our business
stakeholders should help
> > guide
> > > us on what kind of problem will resonate with the
business community.
> > >
> >
> > > Regards,
> > > Cory Casanave
> > >
> >
> > > > -----Original Message-----
> > > > From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-
> > > > bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S.
Townley
> > > > Sent: Saturday, March 25, 2006 12:03 PM
> > > > To: Service-Oriented Architecture CoP
> > > > Subject: Re: SOA Semantic Variation ( was RE:
[soa-forum] RE: SOA
> > > > CommunityDemoCon Call)
> > > >
> >
> > > >
> >
> > > > Hi folks,
> > > >
> >
> > > > I've combined some of the points from both Cory and
Ken into one
> > > > response. Please see in-line.
> > > >
> >
> > > > On Fri, 2006-03-24 at 22:32, Cory Casanave wrote:
> > > > > It is this contract of interaction that is the
essence of SOA, this
> > is
> > > > what
> > > > > allows multiple actors to play roles as
providers or users of
> > services.
> > > > It
> > > > > is the glue.
> > > >
> >
> > > > Absolutely correct, but so is Ken's point here
> > > >
> >
> > > > On Sat, 2006-03-25 at 05:02, Ken Laskey wrote:
> > > >
> >
> > > > > The essence of SOA is not that we have
architected solutions
> > > >
> >
> > > > > but that we have the power to architect the
hooks for solution
> > modules
> > > >
> >
> > > > > that deal with areas which make
interoperability difficult now. The
> > > >
> >
> > > > > essence of SOA is we can add new services to
fill those voids as
> > > >
> >
> > > > > technology and knowledge grows, and we can
keep multiple solutions
> > > >
> >
> > > > > around as long as these are useful. The
essence of SOA is that we
> > can
> > > >
> >
> > > > > interoperate (to some extent) with people who
moments ago we did not
> > > >
> >
> > > > > know existed.
> > > >
> >
> > > > What Ken pointed out is why the S of SOA is so
important. The
> > community
> > > > is defined by the services that are provided to
it. The interaction
> > > > models of the services themselves define the
interaction models of the
> > > > architecture. This is also where you can get
explosive complexity if
> > > > things within the architecture aren't managed
correctly. So Cory's
> > > > point about the "contract of interaction"
is correct, but it exists
> > only
> > > > between a requester and provider.
> > > >
> >
> > > > The architecture defines how these two agents can
communicate, with
> > what
> > > > data models and under what constraints, but it
cannot do more than
> > > > that. Satisfying those constraints and being able
to participate in
> > the
> > > > community require the business relationships that
are the glue that
> > Cory
> > > > mentioned.
> > > >
> >
> > > > > How you get to satisfy that contract is
another matter. This is
> > almost
> > > > > always a facade on another system or component
or service. How you
> > map
> > > > from
> > > > > this "community" specification to
your "internal" specification is
> > > > > interesting and important, but it is not
important to the community.
> > > > This
> > > > > is your business (So for the demo, this can be
a differentiation
> > point
> > > > for
> > > > > the implementers). I think some of the
conversation has been how to
> > > > achieve
> > > > > this façade mapping, which is not then NOT
something we have to
> > agree on
> > > > but
> > > > > is a great thing to demonstrate.
> > > >
> >
> > > > Actually, if this is in relation to my comments,
then this comes from
> > > > the way I expressed it. I was actually not talking
about this type of
> > > > mapping at all. This is what we refer to as
"behind the service
> > > > boundary", and it is, as you said, only really
relevant to the service
> > > > provider and not to the community of requesters.
I'll come to more of
> > > > what I meant below.
> > > >
> >
> > > > > The reason we like MDA is it gets us from the
business model
> > (providing
> > > > > context and definition for the processes and
messages) to the
> > contract
> > > > of
> > > > > interaction (E.G. WS-* and other technologies)
with full tracability
> > and
> > > > a
> > > > > lot of automation. Just this is a big win -
far beyond the current
> > > > common
> > > > > practice. Having the business model in the
picture tackles many of
> > the
> > > > > "what does this tag mean" questions
without a full ontology.
> > > >
> >
> > > > True, but doesn't that pretty-much imply
point-to-point interactions
> > and
> > > > limited re-use of commonalities through
standardized message types?
> > > >
> >
> > > > These standardized message types may be used by
multiple business
> > > > processes. This way you can attempt to define the
message fragment
> > > > (e.g. a complex element using XML) and state what
that message type is
> > > > intended to be. This says what it is in the
context of the entire SOA
> > > > community. Once you have this done, the service
model for each
> > service
> > > > specifies the context for how it is actually
interpreted by that
> > > > service.
> > > >
> >
> > > > The best example of this sort of thing is an
address. You can specify
> > > > the structure of an address and how the elements
should be populated
> > (by
> > > > profiling, rolling your own, or pulling in xAL),
but that in one case
> > > > the address data returned from the yellow pages is
for a business and
> > in
> > > > another case the one returned from the white pages
is for a residence
> > is
> > > > dependent on the service creating the message. It
may be represented
> > by
> > > > the content model as type="business", but
ultimately, the context is
> > > > provided by the service model and the business
process it represents.
> > > >
> >
> > > > >From what I've seen of MDA from Cory's XML'02
paper "Enterprise
> > > > Distributed Object Computing" and his
referenced presentation, it
> > > > doesn't really look like MDA can handle this very
well. MDA seems to
> > > > provide higher levels of abstractions to support
more generalized
> > > > process modelling, but it's still dealing with an
object-oriented
> > > > approach once you get down to the information
model. Once this
> > happens,
> > > > you've defined a representation of the concept and
you start getting
> > > > into trouble.
> > > >
> >
> > > > I am not convinced that SOA is about objects. Yes,
you need a way to
> > > > ship data around, but the power of shared concepts
does not come from
> > a
> > > > particular representation. It comes from a shared
understanding of
> > the
> > > > concept. If you have this, why not have a shared
representation as
> > > > well?
> > > >
> >
> > > > > So the specification we described in the straw
man is only the
> > community
> > > > > contract, with full expectation that
interesting approaches will be
> > used
> > > > to
> > > > > adapt this community contract to systems and
other SOA models. But
> > the
> > > > > community contract would be our anchor point.
The important point
> > here
> > > > is
> > > > > that "SOA", as an
"architected" solution (the A in SOA) does not
> > need or
> > > > > expect semantic variation in the contract.
But realizing SOA
> > contracts
> > > > will
> > > > > be much easier if semantic approaches are
available.
> > > >
> >
> > > > The other thing is: once you have a community, you
must have some
> > sort
> > > > of governance of that community (even if it's
'none'). This
> > governance
> > > > model decides how and when shared data models can
change. It isn't
> > > > about semantic adaptation at the service boundary,
it's about changing
> > > > or extending a data model used by many services in
the community. You
> > > > can't cause everyone to change their agent
implementations because
> > > > someone has a legitimate need for including more
information into a
> > > > common model. I believe that this issue is what
both Ken and I were
> > > > trying to highlight (Ken, please feel free to
correct me if I'm wrong
> > > > here).
> > > >
> >
> > > > What worries me about what I've seen and read thus
far about semantic
> > > > negotiation across ontologies is that this is
really trying to provide
> > a
> > > > technical solution to a community problem. It goes
back to the
> > > > governance thing I mentioned above. If you have a
community, you must
> > > > have some shared understandings within that
community. Yes, there
> > will
> > > > always be intersections and touchpoints between
communities, but this
> > > > can be resolved by putting the semantic negotiation
at those
> > > > intersection points.
> > > >
> >
> > > > The fact that within a single community you can
have a nearly infinite
> > > > variation in the way the data for an operation is
structured and what
> > > > the operation to use it is called is *not* a good
thing. Sure they're
> > > > all "semantically equivalent" because
what they are supposed to do is
> > > > the same, but how you invoke it should be agreed
within the community.
> > > >
> >
> > > > Just because I can define them all in WSDL and
figure out how to map
> > > > them does not make it legitimate.
> > > >
> >
> > > > Within a community, there has to be some level of
shared sense of
> > > > legitimacy or there is no community. We can't
drive on whichever side
> > > > of the road we want to just because we have a car.
The community says
> > > > that you drive on the right, so you drive on the
right, If you could
> > > > drive from New York
to London,
you'd need to make some slight
> > > > modifications when you cross the community
boundary, but once you're
> > in
> > > > the UK,
you drive on the left. If you don't agree, e.g. establish
> > > > legitimacy, there is chaos because everyone's
trying to do their own
> > > > thing.
> > > >
> >
> > > > In an SOA, there isn't one contract, there are many
contracts; each
> > one
> > > > defined by the service provider's interaction with
a requestor. What
> > > > tools you use to hook those two together is not a
problem for the SOA.
> > > >
> >
> > > > The SOA says that you can do it and provides the
structure to make it
> > > > happen. The architecture is relatively
straightforward; the services
> > > > are the hard part.
> > > >
> >
> > > > ast
> > > > --
> > > >
> >
> > > > Join me in Dubrovnik,
Croatia on May
8-10th when I will be speaking at
> > > > InfoSeCon 2006. For more information, see
www.infosecon.org.
> > > >
> >
> > > >
> >
**************************************************************************
> > > > *************************
> > > > The information in this email is confidential and
may be legally
> > > > privileged. Access to this email by anyone other
than the intended
> > > > addressee is unauthorized. If you are not the
intended recipient of
> > this
> > > > message, any review, disclosure, copying,
distribution, retention, or
> > any
> > > > action taken or omitted to be taken in reliance on
it is prohibited
> > and
> > > > may be unlawful. If you are not the intended
recipient, please reply
> > to
> > > > or forward a copy of this message to the sender and
delete the
> message,
> > > > any attachments, and any copies thereof from your
system.
> > > >
> >
**************************************************************************
> > > > *************************
> > > >
_________________________________________________________________
> > > > 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
> > >
> >
> > >
_________________________________________________________________
> > > 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
> > --
> >
> > Join me in Dubrovnik,
Croatia on May
8-10th when I will be speaking at
> > InfoSeCon 2006. For more information, see www.infosecon.org.
> >
> >
**************************************************************************
> > *************************
> > The information in this email is confidential and may be
legally
> > privileged. Access to this email by anyone other than the
intended
> > addressee is unauthorized. If you are not the intended
recipient of this
> > message, any review, disclosure, copying, distribution,
retention, or any
> > action taken or omitted to be taken in reliance on it is
prohibited and
> > may be unlawful. If you are not the intended recipient,
please reply to
> > or forward a copy of this message to the sender and delete
the message,
> > any attachments, and any copies thereof from your system.
> >
**************************************************************************
> > *************************
> >
_________________________________________________________________
> > 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
>
> _________________________________________________________________
> 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
--
Join me in Dubrovnik,
Croatia on May
8-10th when I will be speaking at
InfoSeCon 2006. For more information, see www.infosecon.org.
***************************************************************************************************
The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended addressee
is unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If
you are not the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments, and any copies
thereof from your system.
***************************************************************************************************
_________________________________________________________________
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