Re: [xml-dev] Web Services/SOA (was RE: [xml-dev] XML 2004 weblog items?)

[Paul Denning <pauld@mitre.org>]

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 
circles.

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 ...

Paul