Title: | EDI, Corba--or something else entirely. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the communication formats in designing interfaces between incumbents and competitive local exchange carriers. Discussion on electronic data interchange (EDI) system and common object request broker architecture (CORBA) system; Importance of value-added networks on message confirmation; Comparison between CORBA and EDI systems; Commonly used interfaces. |
AN: | 2667918 |
ISSN: | 0040-2656 |
Database: | Academic Search Elite |
EDI, CORBA--OR SOMETHING ELSE ENTIRELY?
In designing interfaces from competitive to incumbent local exchange carrier operations support systems, developers not only have had to work with a huge volume of message formats that vary from one ILEC to another, but they also have had to implement a variety of communications formats.
The predominant format for communication between incumbents and CLECs is electronic data interchange (EDI). EDI, which has been around for about 20 years, is a little like e-mail. Traditionally, messages sent from one carrier to the other sit in a mailbox until someone checks for them. Unlike e-mail, however, many of today's systems operate in real time.
EDI delivery systems, known as value-added networks (VANs), have mechanisms in place to confirm when messages were received--a useful capability that can help prevent finger pointing when disputes arise. VANs also support shared delivery--a capability that Joseph A. Rogers, director of IT for Ameritech Information Industry Services, finds appealing. "When my system is down, the VAN pools messages, and when I'm operational, it pushes them to me," he says.
Some have argued that using the Internet, rather than a VAN, could eliminate the need for CLECs to order a dedicated line to the RBOC. But that approach would entail other trade-offs, he says. "If we used the Internet, I would have to build all that stuff," Rogers says, referring to the VAN's shared delivery and order confirmation capability. "We didn't want to spend all our time doing that. Also, I would have to teach EDI. Now [CLECs] learn that from the VAN."
Most RBOCs have taken the same approach as Ameritech, perhaps because they already had EDI in place to support communication with key vendors. A notable exception is BellSouth. Although that company's first interfaces were based on EDI, it now has shifted its development efforts to focus on CORBA. "We chose CORBA because it matches our view of how the world will work in five years," says Bill Stacey, operations vice president for interconnection services at BellSouth. The company has begun to heavily emphasize CORBA for its own internal systems.
Venkates Swaminathan, executive vice president and chief strategist for OSS gateway vendor Nightfire Software, compares EDI and CORBA: "EDI defines the content of the message. You can print it on a piece of paper. It's encrypted text. There are many ways to get it to the ILEC. You could e-mail it. You could create a file and [use file transfer protocol to send it over] or you can use a VAN. It's like sending e-mail, but it's proprietary."
"CORBA combines the content, which is created through objects, with the transport part. You can't print out an object. It's an abstract entity inside the computer. CORBA replaces the VAN and EDI. It's more a dialogue than a single message. It's easier to use and more well-structured."
Others argue that CORBA and EDI provide comparable performance. "There is no performance degradation between EDI or CORBA," says Phil Cavallo, senior vice president of worldwide sales and marketing for DSET.
Because no single standard interface exists, CLECs wanting to interconnect with multiple RBOCs may have to acquire EDI and CORBA capabilities--and that still only takes care of part of the equation. To achieve full interconnection, CLECs may need yet another type of interface to connect their internal OSS with their order interface gateway: In addition to CORBA, the interfaces most commonly used for that purpose include extensible markup language (XML) and the COMM (component object model) format, originally developed by Microsoft.
Mike Desey, product manager of regulated ordering for OSS vendor MetaSolv, is bullish on XML. "It's a data-based communications language," he says. "It provides independence from the data repository and it lets you run across the Internet so you might get away from fixed pipes."
Dale Quick, executive vice president and chief operating officer for gateway vendor Quintessent Communications, also sees advantages to XML. "XML can be rapidly modified by less skilled people, and you can modify the data without worrying about what you're doing to the [order] form."
To date, the Alliance for Telecommunications Industry Solutions, the group charged with selecting standards for OSS interconnection between ILECs and CLECs, has focused primarily on EDI. It is working on a CORBA interface for trouble ticketing, however, and may develop one for pre-ordering if carriers show sufficient interest. A request also has been made for the group to look at XML as an ordering interface.
Making decisions on whether to adopt any of these new communications formats will require carriers to weigh the pain of making a change against the potential benefits. One thing is clear, though: Like an office LAN, OSS interconnection will forever be a work in progress.
Swaminathan
DIAGRAM: OSS-TO-OSS INTERCONNECTION
~~~~~~~~
By Joan Engebretson and Tim McElligott