So much promise, so much challenge

If ever a technology seemed tailored to the needs of government, it is service-oriented architecture. SOAs link disparate systems, but still make federal agencies think.

If ever a technology seemed tailored to the needs of government, it is service-oriented architecture. With the need for thousands of disparate systems to share information, particularly for homeland security, across organizational boundaries, SOA offers agencies an attractive shortcut to their data-sharing goals.SOA lets organizations share their applications' data and business logic with other applications, either in the same organization or across divisions, by publishing them as Web services. Because these services can use the same protocol used by Web applications, they also can be configured for use behind a firewall or across firewalls.And because SOA uses a standard set of protocols, defined by organizations such as the Organization for the Advancement of Structured Information Standards, and the Web Services Interoperability Organization, IT can be used to tie together the functionality and data from widely disparate applications. Agencies can use tools from several software companies to connect Web services to nearly any information system, including mainframe "green-screen" applications.The Defense Department, through its Defense Information Systems Agency, has begun to move forward with a significant cross-service SOA, Net-Centric Enterprise Services. Market analysts at Gartner Inc. in Stamford, Conn., estimated that by 2008, 80 percent of all new software projects will be based on SOA."There are many different drivers in the federal government for SOA," said Ian Bruce, marketing director at Burlington, Mass.-based Systinet Corp. SOA management tools from Systinet, which recently merged with Mercury Interactive Corp. of Mountain View, Calif., are being used in the NCES effort by integrator Merlin Technical Solutions Inc., Greenwood Village, Colo."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' 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 a SOA.But regardless of your customer's mission and resources, SOA is not a silver bullet. It eases many integration issues, but key standards that would speed government's adoption of it, especially surrounding security, ? are just emerging even as others, such as lifecycle management, are falling into place.bumps in the roadA lack of consistent standards makes SOA interoperability less than automatic, but the current generation of tools extends the life of 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, SOA is 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 (UDDI) standard that identifies the services and includes information on how to connect to the services using the Web Services Definition Language (WSDL).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 (BPEL), to combine multiple Web services behind a single interface. Software AG Inc., Oracle Corp. and other vendors use BPEL to unite collections of services to create new services. In 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.SOA suite vendors generally provide tools not only to deploy these services, but also to 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.There are plenty of standards to help guide the creation of Web services, but a lot of work remains to be done to achieve interoperability between the products of "standard-compliant" vendors. The standards coming out of groups such as WS-I and the Organization for the Advancement of Structured Information Standards are certainly more mature than they were a few years ago, but 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 Corp. technical staffer, in a recent blog posting. Ferris was responding to comments about the poor interoperability of some Web services implementations."However," Ferris wrote, "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."One of the weakest links in those standards is security. Some vendors have implemented Oasis and WS-I's WS-Security standards, but those implementations aren't necessarily interoperable or even secure."Most Web services implementations are inside the firewall," said Jeremy Epstein, senior director of product security for WebMethods Inc. of Fairfax, Va. "People are incorrectly assuming that they're safe, even though we know statistically that most attacks on services come from inside the firewall."For outside the firewall, people are saying, 'I'll encrypt with Secure Sockets Layer and only deal with trusted partners,' " Epstein said. "That's something of a sticking-your-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-complaint system, SOA standards aren't designed to handle multilevel security. The WS-Security Exchange working group is discussing ways to implement Security Assertion Markup Language as part of that emerging standard, but for now, security must be managed at the application level on both ends, or through some other hardware or software.So far, few SOA integration products have received security certification. 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 Secure/Multipurpose Internet Mail Extensions encrypted messaging.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 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 and hardware 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 maintaining service levels to consumers and managing changes that could break consuming applications. SOA offerings from IBM, Oracle, Systinet, Tibco Software Inc. of Palo Alto, Calif., and Reactivity also place a premium on Web services management.S. Michael Gallagher, a Maryland network manager, writes about computer technology.

RFP CHECKLIST: 10 points every systems integrator should cover

1. When seeking a tool set, ask vendors about their interoperability with:


  • Web Services Definition Language 1.1

  • Universal Description, Discovery and Integration versions 2.0 through 3.0.2

  • Simple Object Access Protocol versions 1.1 and 1.2

  • Extensible Markup Language schema 1

2. For enterprise SOAs, consider the WS-Reliability standard, a SOAP protocol for guaranteed delivery of SOAP messages with no duplicates. This is especially important for transactional systems.

3. If planning to let individual client devices, as well as trusted applications on servers or mainframes, plug into the SOA, ask vendors if their SOA solutions can integrate with your particular authentication systems, whether it's the Defense Department's public-key infrastructure or another authentication system.

4. Ensure the SOA platform supports these security standards:

  • WS-Security

  • Web Services Security SAML

5. Make sure vendors can meet National Institute of Standards and Technology FIPS-140-2 encryption requirements at a level appropriate to your application.

6. If dealing in larger, more structured datasets, such as electronic data interchange transactions, look for an SOA that can support electronic business using eXtensible Markup Language messages as well as SOAP.

7. Ask vendors about their interoperability with any already installed, major system elements that you will plug into the SOA. In some cases, there may be alternative ways to link systems into the SOA that overcome problems of matching standards.

8. If you have data in legacy applications that aren't directly integrated with a .NET, Java Enterprise Edition or another application server with Web services capabilities, you'll need legacy-to-Web services that can connect terminal-based applications or other systems, such as Customer Information Control System, into your SOA.

9. Depending on what systems are integrating into the SOA, you may require support over protocols other than H T T P. For legacy systems, this might include File Transfer Protocol.

10. Ask vendors what performance and monitoring tools they provide for SOA services. Ask also about the availability of ways to manage service level agreements for availability, which is critical if your customer is planning on serving services to other agencies or hooking into someone else's SOA.

Michael Bechetti




































The weakest link











Web services gateway