Martin,
Here is a little bit of input you can chew
on:
First, in trying to answer the question you are
raising "Why do we need SOA?",
it is worth to define the “we”. Depending on who is the “we” in your question,
you will get various answers that may be complete opposites. For example, the
“we” could be the big corporations such as Microsoft, IBM and the like (who
are not interested in participating in the standardization of SOA-related
things),
[JMC]
I think you may have missed the announcement for the new WS-RX TC,
not to mention WSS and other TCs :)
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
or the “we” could be the standard community that could
be made up of individuals and/or small-to-medium companies. The “we” could
also be the IT marketing groups worldwide, or the “we” could simply be the
members of the SOA-RM TC, etc…
Concerning the sentence below (Quoting: “I agree that
SOA is shaped by more than the Internet”), I do think that the Internet is The
playground of SOA. It’s like the soccer field. Where would you play soccer?
You may say “soccer is shaped by many things other than the soccer field, but
then when it comes to play soccer, there is only one place, and that is the
soccer field. If you are interested by the historical aspect of SOA (like from
where it came, what caused it, and what it wants to accomplish?), it suffices
it to only know this:
Fifteen years before the advent of the Internet, if
somebody were to tell us about the Internet and how it is as we know it, it
would have been hard to believe. The thing is that, even though the Internet
seems sophisticated, it is only at its beginnings (like a baby who needs to
grow up). One of the major goals of SOA is about the next generations of the
Internet.
[JMC]
Some may say that that is too strong a statement, and that the
Semantic Web fits that bill.
Object-Orientation technology helped a lot in the
design of applications that are enterprise-scoped (does not span beyond an
enterprise boundaries). However, as successful as it is, Object-Orientation
has its limits and is unable to go beyond the enterprise scope,
[JMC]
I see these as orthogonal - in fact, one may have a service-oriented
system (using Duane's suggested terminology - thanks Duane) that is
object-oriented behind-the scenes, and the objects are layered by components,
which are then layered by services, which may span enterprise boundaries. If
anything, I would replace "Object-Orientation" above with "EAI".
and certainly not the instrument to drive the next
generations of the Internet (which is by definition of bigger scope). A
convergence of many ideas and technologies experienced with in the past
(especially in the area of EAI,
[JMC]
OK - I see you've mentioned EAI here
:)
Joe
Joseph Chiusano
Booz Allen Hamilton
and event-driven models) helped in shaping a new IT
revolution named SOA which is the instrument by which the next generation of
the Internet will be constructed.
Hamid.
-----Original Message-----
From: Smith, Martin
[mailto:Martin.Smith@DHS.GOV]
Sent: Monday, May 09, 2005 8:04 AM
To:
Rex Brooks; soa-rm@lists.oasis-open.org
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
>
>
>
>