If you've read anything about the evolution of the Internet, you know that XML is the successor to HTML as the lingua franca of the Web. You know Microsoft supports XML in Internet Explorer 5.0. You may even know that XML can be used to provide data portability among applications.
But did you know XML might help you call your mom? Did you know it could define your virtual private networks (VPN)? Vendors are now saying you can use XML to do both these things.
XML replaces the idea of services being a part of big switches with the concept of a flexible set of service definitions that can be read by every device involved in creating and using a service. A service can be defined in an XML page that links to other XML pages in order to define features. Each feature XML page can define "behaviors" for each of the devices in the network that participate in creating or delivering that feature. The user, by modifying an access-to-service page, can define how a particular feature is requested or delivered.
The cooperative signaling that occurs in voice call forwarding or VPN server load balancing can also be defined in XML. The old, rigid Signaling System 7 approach is replaced by what we could call "SSX," a signaling system based on XML definitions. Each service message (including billing instructions) can be designed as an XML page and the structure definition stored where everyone who will need to read the signals can find it.
But for most of us, XML's greatest impact may be how it controls user-to-network relationships. With simple XML authoring tools now becoming widely available, users could change service profiles easily, deciding what code they want to dial for last-number-redial service or redefining just what kind of traffic is allowed onto a VPN.
Behaviors that affect a single user, such as how voice mail and e-mail relate to each other, could be created by users themselves or by service providers, developers and equipment vendors, with users picking the behaviors they like. Sound wild? Well, vendors are already offering this very thing.
The action started in the voice market. DTI, a provider of Class 5 switches, has announced call feature management using IP/Internet resources via what DTI calls Call Policy Markup Language (CPML). The company jokingly calls its approach "voice under IP" to reflect IP's role in feature delivery and coordination, rather than transportation.
Other vendors are giving chase. Newcomer ipVerse has announced an XML-based services architecture that would let service providers create custom features for users and also permit users to tune feature behavior to suit their business. Convergent Networks, a new-generation voice player, has announced that XML will provide some of the flexibility in its Service Enabling Architecture.
In the data VPN market, Abatis Networks announced an XML-based Service Definition Language to control how VPNs work. Features include control over customer access, quality of service and even the relationship between users and application service providers. LAN vendor Top Layer Networks announced it has adopted Manage.Com's XML-based problem management software. Cornice Communications, which plans to use XML as the basis for a far-reaching service brokerage architecture that would embrace data or voice, premises or service provider, is still being coy about product details, but it may have the most ambitious scheme of all.
But the XML story that users can apply most directly comes from Merlot Communications. Merlot offers the first voice-over-LAN architecture to be based on XML, via a definition it calls ServicePage. With this architecture, users can create custom LAN PBX features, control dial sequences used to trigger features and even link sites in a kind of cooperative Centrex. Merlot also says it will support service provider XML linkage and even sell its products through service providers as a kind of super-Centrex.
Of course, there are still issues to face. The use of common feature definitions doesn't guarantee interoperability; a standard service model is needed. Security must also be provided for the XML features. All these issues will surely be debated, and some of the benefits of XML-based services may be delayed. But at least debates about features make more sense than debates about convergence of technologies as an impetus to future network trends.
A features debate is exactly what XML will give us. By emphasising service rather than technology, XML is forcing the market to focus on what service providers should have been focusing on all along.