[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Why do we need SOA? (proposal for Introduction text)
Rex - - Glad to have stimulated your input.
I agree that
SOA is shaped by more than the Internet. I thought about adding more, but
thought I'd first see if others would pick up on the basic premise that we could
use a bit of context for the RM.
Your formulation (in your message)is
good. Here's some of what has been in my head:
"SOA also draws on and
extends other sources of ideas on how software products can best be developed.
SOA uses the "object oriented" principle of encapsulation of "chunks" of
functionality, with the chunks connected by well-defined interface contracts.
This is in keeping with an even longer-term trend toward modularization or
componentization of software. The key benefit of modularization is that it
provides flexibility by limiting the interdependencies among the parts of the
overall system. This makes it easier to upgrade or change out one part without
recoding the entire system. The very powerful idea of interchangeable parts in
manufacturing has an even longer history - - at least back to Henry
Ford."
Martin
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent:
Sunday, May 08, 2005 9:37 AM
To: Smith, Martin;
soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Why do we need SOA?
(proposal for Introduction text)
Hi Martin,
This is a specific
topic that was among those I
tackled in a recent four-part series published
in
DMReview, for which I would be happy to supply
the urls, but which I
decided not to post to the
list simply because I frown on people
promoting
their own work in lists like this. However I can
post my opinion
about these issues, which I will
do inline.
At 12:24 AM -0400 5/8/05,
Smith, Martin wrote:
>List - -
>
>I sent essentially this same
message in the
>thread "[soa-rm] When Is An SOA Really An
SOA?"
>a while back, but got no response. Thought I'd
>try
again to see if no-one noticed it or no-one
>liked it . .
.
>
>I'm proposing we include something like the
>following in
the Introduction. As several
>people have observed, we all tended to
jump
>right in to the details of "what is an SOA"
>without nailing
down the answer to the "why
>should I [the reader] care?" question.
As we
>learned in the f2f discussion, many of us on the
>TC care
because it's our job to explain to
>others why we all seem to think we
need this
>'SOA' thing (other than that it keeps being in
>the
news!) I'm guessing that if we can
>understand why SOA has become a
buzzword, we'll
>clarify the "essential definition"
question.
>
>So, here's what I think is driving
SOA:
>
>"The SOA concept has emerged in response to the
>need
for an approach to application architecture
>that is well adapted to the
Internet
>environment. The Internet has revolutionized
>personal
communications with e-mail, and
>"B-to-C" transactions with the World-Wide
Web.
>Following the exploitation path of other
>technologies, the
Internet may be expected to
>have a similar revolutionary effect on
"B-to-B"
>transactions - - automating system-to-system
>exchanges -
- and this domain may eventually be
>several times larger in scale that
the "B-to-C"
>space.
I think the SOA concept actually harks back
to
the roots of Enterprise Architecture post Zachman
in the work that grew
out of his initial work,
paralleling the "Business Reengineering"
concepts
of the late 80s and early 90s, and also parallels
the movement
toward model driven architectures in
OMG with the advent of UML as a
practical tool.
The web makes it more imperative to develop
specific
architectural patterns adapted to web
services--however, I do think that the
primary
basis for SOA should be spelled out apart from
the Internet/Web
context because at a more basic
level, a Service-Oriented Architecture
develops
from the simple concept of reliable, repeatable
services, whether
that be a lemonade stand which
needs the back end of the orchard and
water
supply, as well sugar supply chain, or the
retail,
factory-franchised automobile showroom.
For the most part we are seeing
those structural
components for the web emerging in WSRP, WSS and
various
other more or less "structural"
specifications. Of course we do have
the
menagerie effect which the major vendors tend
throw up in ad hoc
fashion to see which
particular concept has "legs" as in WS-* and
others,
but it looks like OASIS is the major SDO
for this environment for this
activity, based on
XML. So, IMO, we are in the right place at the
right
time to provide the missing piece of this
puzzle--a formaliization of the
concept that sets
those patterns.
>The characteristics of the
Internet environment
>to which the SOA concept responds
are:
>
> 1.
Multiple management
>domains.--Business or other entities "on
the
>'Net" each have their own set of policies and
>procedures, and
they are legal peers so there is
>little or no "top down governance" in
the
>environment;
Nor should there be. This is the
uncentralized,
as opposed de-centralized structures we may need
to
encourage among previously centralized
structures, such as GSA, which
Congress, in its
illimitable wisdom is now seeking to
re-centralize in the
name of economic efficiency
(I think?--I use the question mark because I
have
yet to see published reasons for this reversal of
nearly a decade of
agency-centered IT
decision-making). The chief reason
uncentralized
governance works better for the future is simply
that it
will have less of a tendency to maintain
outworn policies and cause problems
when no
greater action is required than discontinuing
such a policy. If
Congress merely backs the
mandate issued by OMB Circular A-119
which
encourages adoption of "Voluntary Consensus
Standards" as opposed to
government-centric
proprietary standards developed by the
vendors
contracted to produce this or that component, we
would see more
coherent IT procurement and
integration
strategies.
>
>
2. Heterogeneous technologies, semantics and processes;
Exactly,
and developing vendor, OS, development
environment, and Language Independent
standards
is the best way to encourage the vendors to build
products which
"play better together in
the
sandbox."
>
>
3. A very large and dynamic
>"marketplace" of potential service
providers and
>consumers.--Unlike the environment within a
>single
organization, there may be many
>alternative providers of a computing
service,
>and available services may change on a
>minute-by-minute
basis;
Amen. Glad to see that at least someone DHS is
aware of this,
though I know you are not alone in
understanding this pervasive
predicament.
>
4. Lack of standard context.--Within a
>single organization, there
is normally a body of
>"well-known" information about what
resources
>are available, how they may be obtained, what
>standards
or conventions they follow, specific
>interface details, reliability of
the resource,
>payment requirements, if any, etc. In
the
>environment of a single computer, the unknowns
>are even
fewer. Because of the size and
>diversity of the Internet, obtaining
this
>information is a much larger problem.
So providing an basic
understanding of the
underlying architectural principles ought to
lend
weight to the argument that vendors and service
providers ought to
develop to open standards
where ever
possible.
> 5.
Lack of infrastructure
>services.--The Internet provides some
basic
>services, but on a "best-efforts" basis. Thus
>issues like
quality-of service and security
>require must be addressed more explicitly
than
>in single-computer or local-network environments.
Again,
Amen.
>Application architectures that call themselves
>"SOA"
provide a solution to these issues of the
>Internet environment. There is
nothing to
>prevent implementing an SOA within a local
>network, on
a single computing platform, or even
>in a non-technical environment like
a human
>household, but the need for SOA is driven by
the
>opportunity for exploiting the worldwide
>connectivity provided
by the Internet."
One specific thought I have pondered long on
in
connection with this Reference Model Activity is
that I see SOÅ as
applying to software "patterns"
such that when one buys a set of service
modules,
one should be free to adapt them to other
subsystems such
as HR or CRM even if the specific
purchase was for a SCM component, and that
such
components should be available throughout the
purchasing enterprise.
This is not actually a
fundamentall different SOA pattern than having
sets
of Provider/Consumers and discrete, named
services that apply to specific
business or
enterprise processes.
>Martin
Thanks for
giving me a chance to express these
notions, Martin. My original intention
was to
bring them up earlier, but I did not want to slow
the process that
would lead to point where it
would again be appropriate to bring
these
concepts up. If I had had the time to be a part
of the run-up to
starting the TC, I would have
brought up such foundational concepts then,
but
under the circumstances, and having some
experience with TCs, it
seemed wiser to wait, or
to hold off altogether, if no one else
provided
an opening into which I could insert these
concepts. I do think
there is a "there" here, and
that if, if needs be, we may want to make
a
distinction between a service that is provided
"as-is" with the
stipulation that the core code
not be changed or adapted, (as if such a
thing
was ultimately enforceable) and services that are
provided as
"service software
patterns."
Ciao,
Rex
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]