Mixing the menu

Service-oriented architectures can tie disparate programs together to share data and change the way agencies work

If there were ever a technology that seemed tailored to the needs of government, it's service-oriented architecture. With thousands of disparate systems needing to share information across organizational boundaries'particularly homeland security information'SOA offers agencies an attractive shortcut to their data-sharing goals.

SOA is a method by which organizations can share the data within (and the business logic of) their applications with other applications, either within the same organization or across divisions, by publishing them as Web services. Because these services can use the same protocol used by Web applications (HTTP or Secure HTTP), they can also be configured for use behind the firewall or across firewalls.

Because it uses a standard set of protocols, defined by organizations such as the Organization for the Advancement of Structured Information Standards (Oasis) and the Web Services Interoperability Organization (WS-I), SOA can be used to tie together the functionality and data from widely disparate applications. Agencies can use tools from a number of software companies to connect Web services to nearly any existing information system, including mainframe 'green-screen' applications. Market analysts at Gartner Inc. in Stamford, Conn., estimate that by 2008, 80 percent of all new software projects will be based on SOA.

The Defense Department, through its Defense Information Systems Agency, has begun to move forward with a significant cross-service SOA, Net-Centric Enterprise Services. NCES is part of DOD's Global Information Grid effort, and will, as DISA describes it, 'empower the edge user to pull information from any available source, with minimal latency, to support the mission.'

Data as driver

'There are many different drivers in the federal government for SOA,' said Ian Bruce, director of marketing of Systinet Corp., an SOA management tools vendor whose products are being used in the NCES effort by integrator Merlin Technical Solutions Inc. of Greenwood Village, Colo. Systinet recently merged with Mercury Interactive Corp. of Mountain View, Calif.

'The primary driver is information sharing,' Bruce said. 'After 9/11, there was a lot of introspection about what we could do better. With NCES' net-centric data strategy, we have the ability to make data visible [to everyone who needs it], and have everyone at the edge pull instead of having data pushed to a select few.'

Fulfilling that goal requires the reliability, security and flexibility to connect to a wide range of data sources and clients. In many respects NCES is the perfect fit for an SOA.

But regardless of your mission and your resources, SOA is not a silver bullet. While SOA does ease many integration issues, key standards that would speed its adoption within government'especially surrounding security'are still emerging.

Although a general lack of consistent standards makes SOA interoperability less than automatic, the current generation of tools is breathing new life into applications that might otherwise have been roadblocks to an integrated enterprise architecture.

'Over the last year, we've seen a lot of increased maturity in the standards,' Bruce said. 'There's been a lot less concern about [interoperability] today than there was a year or two ago. Now the issues are around lifecycle management and governance.'

At the most basic level, an SOA consists of a set of Web services based on a standard protocol such as Simple Object Access Protocol or ebXML (Electronic Business using eXtensible Markup Language). These services are registered in a directory based on the Universal Description, Delivery and Integration standard that identifies the services and includes information on how to connect to the services using the Web Services Definition Language.

In theory, an agency could publish an interface to one of its applications on a shared UDDI directory, and others could use the WSDL to connect their applications to that interface without having to know what operating system or environment the application was running in.

But many SOA solutions go further, using business process logic, such as the Business Process Execution Language, to combine multiple Web services together behind a single interface. Software AG, Oracle and other vendors use BPEL to pull together collections of services into whole new services. In the case of Software AG's new Crossvision SOA suite, those orchestrated services can even be pulled into interactive Web applications based on the emerging Ajax development language.

Lifecycle management

SOA suite vendors generally also provide tools to not only deploy these services, but manage their lifecycles. Beyond just serving up information on what services are available, these software tools ensure that service providers don't make changes to underlying services that break the applications that 'consume' the services.

But although there are plenty of standards to help guide the creation of Web services, there's a lot of work to be done in the way of interoperability between the products of 'standard-compliant' vendors. While the standards coming out of groups such as WS-I and Oasis are certainly more mature than they were a few years ago, progress on many of the standards is slow.

'I will concede that it is taking longer than I might like to drive the specifications through the standards process,' said Chris Ferris, chairman of the WS-I Basic Working group (and a senior IBM technical staffer), in a recent blog posting. Ferris was responding to comments about the poor interoperability of some Web services implementations.

'However,' Ferris continued, 'the reality is that standards take time to mature and vendors rarely implement until the standard is established...and the market pressures are brought to bear.'

The weakest link

One of the weakest links in those standards is security. While a number of vendors have implemented Oasis and WS-I's WS-Security standards, those implementations aren't necessarily interoperable'or even secure, for that matter.

'Most Web services implementations are inside the firewall,' said Jeremy Epstein, senior director of product security for WebMethods Inc. of Fairfax, Va. 'And people are incorrectly assuming that they're safe'even though we know, statistically, that most attacks on services come from inside the firewall.

'And for outside the firewall, people are saying, 'I'll encrypt with SSL and only deal with trusted partners,' ' Epstein said. 'That's something of a sticking-head-in-the-sand approach. If a partner gets compromised, you're compromised as well.'

Even when Web services are running 'securely' with a WS-Security-compliant system, current SOA standards aren't designed to handle things like multilevel security. The WS-Security Exchange working group is currently discussing ways to implement Security Assertion Markup Language as part of that emerging standard, but for now security still needs to be managed at the application level on both ends, or through some other hardware or software product.

So far, few SOA integration products have received security certification themselves. WebMethods' Fabric 6.5 was the first, earning a Common Criteria EAL2 certification from the National Information Assurance Partnership. WebMethods uses Entrust's FIPS-140-2-certified cryptography for its SSL and S/MIME encrypted messaging.

The Web services gateway

One security solution that many SOA vendors and integrators are turning to is a secure application gateway for Web services, also known as Web services firewalls. Last fall IBM acquired one of the leading vendors of those gateways, DataPower Technology Inc. of Cambridge, Mass. DataPower's SOA appliances are hardware-based products that filter, route and encrypt Web services messages.

Reactivity Inc. of Belmont, Calif., and Vordel Ltd. of Dublin, Ireland, also offer SOA security appliances, which can be deployed in front of Web services hosts and clients to enforce security of message traffic.

And Software AG has partnered with Forum Systems Inc. of Sandy, Utah, another major SOA gateway provider, to package its firewall with Software AG's SOA tools. Forum offers a mix of software-based and appliance-based products. Its Sentry product is a hardware-software combination designed to add WS-Security to Web services without having to modify applications.

Software AG's Crossvision software itself is aimed primarily at addressing another weakness of Web services and SOA: the issue of managing services once they're deployed, both in terms of maintaining service levels to consumers and managing changes that could break consuming applications. SOA offerings from WebMethods, Tibco Software Inc. of Palo Alto, Calif., Systinet, IBM and Oracle, also place a premium on Web services management.

Because different Web services implementations often vary in terms of which WS-I specifications they've implemented, multiple versions of a Web service must often be deployed to account for the differences. And organizations must track the interdependencies of various Web service consumers. 'If you don't have that, you may not know who the users are, what they're doing to it, and what will break if a Web service changes,' said Systinet's Bruce.

At this point in the evolution of SOA, broken Web services may simply be a fact of life. But as the tools get better and agencies gain more experience deploying services, they'll change the way groups share data and resources'for the better.

inside gcn

  • artificial intelligence (ktsdesign/Shutterstock.com)

    Machine learning with limited data

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group