Lists Home |
Date Index |
- To: email@example.com
- Subject: Re: [xml-dev] Web Services/SOA (was RE: [xml-dev] XML 2004 weblog items?)
- From: Paul Denning <firstname.lastname@example.org>
- Date: Wed, 01 Dec 2004 09:50:36 -0500
- In-reply-to: <EAAD28446720174391E26A9A505854567FF4A0@MCLNEXVS02.resource.ds.bah.com>
- References: <EAAD28446720174391E26A9A505854567FF4A0@MCLNEXVS02.resource.ds.bah.com>
At 05:46 PM 2004-11-22, Chiusano Joseph wrote:
> > There was less about web services / SOA on the program this
> > year. Is the world just quietly using these technologies,
> > sick of hearing the hype, or what?
>I noticed that as well (it was especially evident to me, since my
>session last year was on Web Services standards:) Speaking on the US
>federal government space, the Department of Defense (DoD) is adopting
>SOA very heavily as part of its NetCentricity initiative. NetCentricity
>encompasses people, process, and technology, and SOA is the technology
>piece. The SOA portion is known as NetCentric Core Enterprise Services
>(NCES). On the civil side, there is not (yet) as heavy an emphasis, but
>I envision the existence of shared services in the civil space (as with
>the DoD space) in the not-too-distant future.
I don't get too hung up on the A in SOA being architecture as opposed to a
philosophy or strategy.
NCES is a shift away from a focus on platform-centric ideas embodied in the
DoD's Common Operating Environment (COE).
Within DoD, before COE, defense contractors would deliver "systems", which
have come to be known as "stovepipes". The systems included software as
well as the hardware upon which it ran. The operating system may have been
tuned or configured specifically for that system. The contractors had few
constraints about the platform they selected. In certain locations, like
Air Operations Centers, a number of such systems would be needed. When one
system sitting right next to another system could not easily communicate or
work together, you get the image of stovepipes.
Meanwhile, there was an emphasis on expeditionary forces, where people and
equipment "deploy" wherever and whenever needed rather than setting up
fixed bases around the world. When deploying, its nice to reduce the
number and size of the equipment that must be transported and setup in the
field. The DoD wanted to define a few common "platforms", and have
contractors deliver a disk with software that can be installed on a COE
rather than hardware and OS specifically tuned for only that software. COE
was about imposing some constraints on the contractors. The focus was on
getting the platform to work well, and getting the software to be
good-citizens when running in that environment. If someone needed some
capability, and suitably packaged software was available for one of the COE
platforms, then that software could be installed. The key was having a
common platform or COE, and building software for it. We call this
platform-oriented or platform-centric.
Well, that turned out to be hard too. So rather than install software on a
local machine, if I could reach back to a service across a network, then I
don't need to worry about having the right platform or tailoring the
software to run on it. Thick applications require trained admin to install
and configure them. Browser-based applications are better from the
standpoint of avoiding the problems with installing numerous thick clients
in deployed systems. With services, some may be accessible through a
browser, and some may require installation of a client piece, but hopefully
the client piece would rely more on services over the network than lots of
things installed on the local machine.
So when you see DoD talk about SOA with NCES, think of it in relative
terms. That is, if we focus on services available across a network rather
than getting applications to work on a common platform, then we don't need
to worry as much about the implementation environment. DoD wants to become
more service-oriented than platform-oriented.
From a service consumer point of view, we don't need to worry about the
implementation (too much). But the service provider does worry about the
implementation. DoD will be a service provider as well as consumer. They
will need to worry about the environments where services are implemented,
but perhaps will have more flexibility with regard to where those
implementations run when applications are more "Net-Centric".
Since this is xml-dev, oh yeh, XML is the format of choice across the
network. In many DoD situations, bandwidth is limited and connectivity may
be intermittent, so binary XML is of interest.
Anyway, this is my perception of SOA as I see it being discussed in DoD
One last word about constraints. They are good to limit choices and
hopefully be left with things that can interoperate. But DoD must be
careful about constraints that may favor one contractor or vendor over
another. Fair trade and all that ...