Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Web Services/SOA (was RE: XML 2004 weblog items?
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
