As deployments of service-oriented architectures grow more complex, the need for federated information management and governance is emerging -- areas for which an ebXML registry is particularly well suited, according to proponents. As such, the OASIS ebXML Registry Technical Committee is hitting the virtual road this month with webinars aimed at educating attendees on the features and capabilities of the ebXML Registry v3.0, which OASIS approved as a standard in May.
Use of an ebXML registry is also "an obvious next step for people looking to migrate from EDI [electronic data interchange]," said Carl Mattocks, consultant and project leader, asset inventory process improvement for Metropolitan Life Insurance Co. in Bridgewater, N.J., and a member of the technical committee (TC). Among vertical industries, Mattocks said e-government and health care are early implementers and, he predicted, "are obvious places where you'll see growth."
Vertical industry groups that have implementations of ebXML Registry include the Integrating the Healthcare Enterprise (IHE) initiative, the Data Interchange Standards Association (DISA), and the National Institute of Standards and Technology (NIST). "NIST has created a registry to help people register artifacts across the Web," Mattocks said.
The ebXML Registry v3.0 specification incorporates both a registry and a repository, which differentiates it from a UDDI (universal description, discovery and integration) registry. In February, a separate OASIS UDDI TC approved UDDI version 3.0.2 as a standard. According to Kathryn Breininger, chair of the OASIS ebXML Registry TC and CENTRAL project manager, emerging technologies for Boeing Library Services at The Boeing Company, there is no formal liaison between the two groups.
ebXML's origin was an initiative between OASIS and the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) to create a framework for e-business. UDDI began as an effort among IBM, Microsoft and Ariba to create a registry standard.
"As [ebXML] has evolved, it added features/functions to enable other types of uses, such as registering Web services," Breininger said. "ebXML includes a repository piece to access whatever is being registered; UDDI doesn't include a repository for artifacts."
The ebXML and UDDI registries have different design centers, said Farrukh Najmi, a member of the ebXML Registry TC and the original author of the ebXML Registry specification. Najmi is also a federated information management architect at Sun Microsystems. "The design center of the ebXML Registry standard is federated information management. UDDI was designed strictly as a lightweight registry to hold basic information. In SOA, we're seeing an increasing recognition that a lightweight registry is not practical for the rising complexity of SOA deployments."
In particular, a registry/repository model is necessary for governance, Najmi said. "In our [registry] deployment experience [at Sun], we validated a strong need for governance to enforce organizational policies on the artifacts involved. Wherever you store them is where you govern them; you can't govern in UDDI because [the related artifacts] are stored outside UDDI."
Sun rolled out its registry/repository product earlier this year, a productized version of the freebXML Registry. FreebXML is an open source initiative that Sun has been heavily involved with. Sun's registry supports both UDDI and ebXML.
"We believe that everything anybody would want to do in a SOA deployment requiring a registry would be covered by the ebXML registry, but we recognize that customers have existing applications written to UDDI," Najmi said.
"What a number of implementers have done with the ebXML registry/repository is make sure it can link to information in UDDI in a federated model. Version 3 is explicitly designed to support federation of information," Breininger said. Infravio Inc., for example, supports both UDDI and ebXML in its X-registry product.
However, Systinet Corp., Burlington, Mass., which has built its business around UDDI, has no plans for ebXML at this time, said David Butler, vice president of marketing. "The SOA and Web services industry has built a set of standards that UDDI is part of. From the perspective of SOA Web services platforms, being [Microsoft] .NET Indigo, [BEA] AquaLogic, IBM, they do not include ebXML, even at the protocol level, as any component of the platform."
Butler does agree that the need for SOA governance and lifecycle management has emerged. And, he said, "the trend is to add more repository capability to the SOA environment." Systinet's recently announced Blizzard platform has a repository at its core that is not based on ebXML.
"The true definition of SOA is understanding how the lower-level services map or link to the business capabilities that organizations like MetLife is putting in place to support its customers," Mattocks said. MetLife has not implemented an ebXML registry to date, Mattocks said. Boeing does have a registry based on ebXML and internal requirements, Breininger said.
Which type of registry, or both, organizations standardize on will ultimately be up to customers. "It helps that two [OASIS] groups are thinking along the same lines," Mattocks said. "SOA might actually happen when that's the case."