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 Cory Casanave
Sent: Wednesday, March 29, 2006 12:50 PM
To: 'Service-Oriented Architecture CoP'
Subject: RE: [soa-forum] Business Need for SOA (Was SOA Semantic Variation )
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.
[->]
Let me take it one step farther. SOA is about the alignment between the need
and the capability. I hesitate to concur with the statement that SOA is about
the Business Architecture only because it is only implicit within the statement
that business is encompassing of the enablers such as process, people and
technology assets. Therefore, to follow your example, the business
architecture identifies the need and the capabilities which may satisfy the
need. However, there must also be consideration given to how the environment
(I use context) is arranged to identify such needs and capabilities. It may organize
technology assets, it may organize in/out baskets, it may organize bicycle
messengers, or something else that we haven’t thought of yet. The tools
that are organized are independent of those needs, but the architecture is
incomplete with consideration of them.
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.
[->]
OK. I should have read this paragraph before I typed the last one. I agree!
>
> 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
[->]
Even in very concrete technology terms, a Web Service request already involves
multiple participants: the requester, the service provider, the application
stack performing on behalf of the service provider, any intermediaries (who are
all those SOAP Headers intended for anyway?), and the infrastructure which
allows the requester and provider to connect.
> 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
[->]
interaction -- mutual or reciprocal action or influence. Looking at the
physics definition is also quite illuminating: “Any
of four fundamental ways in which elementary particles and bodies can influence
each other” The word interaction is a nonification of the word
interact. It is a way for us to process an action as a discrete thing with
boundaries rather than something more continuous. I have found it important to
return to the understanding that it is actually a verb.
> 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
[->]
Well, there is a specification of an offer to do something for someone else. There
is also a specification of a need which someone else may perform. Finally,
there is a specification of the agreement between these two as a 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
[->] These map
fairly well to the constructs in the OASIS SOA Reference Model. What’s
missing here is the recognition that SOA has some dynamic aspects “What
you Do” and some static aspects “What you Need.” These are
both necessary and sufficient aspects. I would claim that you aren’t
really talking about SOA if you don’t consider both aspects.
> 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.
[->]
Its also very specific to technology and tends toward treating a service as a
thing which is separate from a capability.
>
> 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 roles on both the consuming and providing side of a service. The
discussion of which is completely orthogonal to the interaction or exchange patterns
that can be observed.
Interoperability - the ability for business units, people or systems to
exchange information in support of a common purpose.
[->]
I like the recognition of tiers of interoperability and the correlation to non-technical
concepts.
>
> 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.
[->]
Why not just go with the IEEE definition and recognize that systems are not limited
to technology implementations.
-----------
So, now it is clear we are BOTH crazy! I wonder if anyone else is
still
listening?
[->]
I am! With both ears even.
-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