The Coast Guard - part of the US Department of Homeland Security -
started looking at SOA in early 2007, as a way to address growing
requirements to be able to share information not only across its own
various units, but with federal, local and international agencies
concerned with keeping an eye on vessels entering and leaving US shores.
I recently had the opportunity to speak with Jim Jennis, chief
technology officer for the US Coast Guard Operations Systems Center,
and Steve Munson, SOA branch chief for the US Coast Guard, about the
department's growing roster of service-orientation initiatives.
"We had the same conundrum of silos of excellence that many IT
organizations have - IT systems tailored in stovepipes within lines of
business," says Munson. Prior to its SOA implementation, the Coast Guard relied on slower
and more manual methods of data sharing with its port partners. "It
would either be some form of composed file that would be potentially
handed over, or many times, a hard-copy printout or phone call," Munson
relates.
To address these requirements, the Coast Guard implemented an enterprise service bus-centered SOA that enabled asynchronous messaging from Fiorano Software Technologies. The solution was employed in the Coast Guard's Long Range Identification and Tracking (LRIT) system, which at any given time, is tracking up to 6,000 vessels moving toward or in US waters as well as vessels anywhere else in the world. LRIT tracks signals emitted from vessels every six hours. "That information is running entirely on the Coast Guard's SOA framework in production," says Munson. As a result, the Coast Guard SOA requires extremely high-volume services, "processing thousands of messages per second."
A second system, the Nationwide Automated Identification System (NAIS), relies on a second transponder on ships exceeding 300,000 gross tons, broadcasting navigational information for ships of 300 gross tons or more at three-second intervals. These broadcasts from US territorial waters result in about 2,000 messages per second received in the NAIS system. The Coast Guard is currently protoyping various data services around this system for maritime domain awareness, Munson says.
The 25 or so services that the Coast Guard currently has in production or soon to be in production are built on the REST protocol, versus the heavier SOAP-based Web services, Munson says. Internally, Munson points out, the prevailing standard is POX, or Plain Old XML for message exchange. "We do not subscribe to the extra wrappers and envelopes and overhead that's required to serve out SOAP-based services."
"What we have found within the Coast Guard is that the Web services model, particularly the traditional RPC-style Web services, are not suitable for implementation in the Coast Guard's architecture," he explains. "Our architecture is fundamentally message based. Where we do implement Web services interfaces, they're all document-driven Web services for external users, where those kinds of interfaces are required."
While the Coast Guard is also seeing some reusability in its SOA-aware services, particularly for lower-level services. However, Munson cautions, "we certainly don't want to oversell that yet." That's because the SOA team is still wrestling with the technical aspects of service governance. "The issue around SOA governance is still a challenge for us as it is with any organization," he explains. "We have not implemented, for example, any formal service registry or automated service discovery. Were continuing to look at how we want to do that."
The issue with registry and repository solutions on the market, he says, is that they are oriented toward the traditional SOAP-based Web services. "Most of them are still tailored to the Web services approach," he says. "Many of them don't have good answers for non-WS-* type of registration."
The Coast Guard soon intends to make some services available to other federal agencies and its port partners. For example, the Coast Guard is participating in an inter-agency program called Watchkeeper, in which data is provided as part of a homeland security system. "We have probably a dozen or more services that are in testing that will be deployed as part of that system," Munson says.
Data security is another challenge for the Coast Guard's SOA team, and this is holding back the ability to offer services to port partners and other outside parties. "One of the challenges in an enterprise service bus, and an SOA architecture in and of itself doesn't solve this, are all the security challenges surrounding data services, particularly once you get outside of your organization," Munson says. Internally, within the Coast Guard organization, the security around services is pretty straightforward. But starting with sharing with external partners at any level, security rapidly becomes a challenge for us. Like other folks, were still looking at how to crack that nut, and we still don't have a silver bullet for that yet."















Leave a comment