The market for IP services is huge, perhaps as much as $300 billion in service revenues over the next 10 years, according to CIMI Corp. (www.cimicorp.com) estimates. Everyone--network service providers (NSPs), ASPs, service portals and technology suppliers--wants a piece of the action. However, until access to services is dynamic, simple and secure, advanced IP services will never be truly consumable. New architectural frameworks designed to achieve these goals are already being deployed. In more instances, the underlying technology that binds the architectural pieces is extensible markup language (XML). It's the glue that facilitates rapid creation, subscription and delivery of advanced IP services.
What is XML?
The World Wide Web Consortium (W3C, www.w3.org) proposed XML as a new, improved alternative to HTML, the current tool for web publishing. XML goes far beyond HTML. It is a metalanguage designed to support a variety of applications, not just publishing and formatting.
XML-based vocabularies already are used for e-commerce, retail sales, and other business and financial transactions. For example, Microsoft Corp. (www.microsoft.com) and Ariba Inc. (www.ariba.com) together have integrated Microsoft's BizTalk with Commerce XML (cXML), an emerging standard for business-to-business e-commerce, in an attempt to standardize business communications and electronic commerce transactions. The Voice XML (VXML) Forum is promoting its vocabulary to create voice-enabled web content and services. The goal is for users to access web-based information by speaking into the phone.
Not surprisingly, XML is starting to find a place in the telecom world, as well. Current telecom developments include Cisco Systems Inc.'s (www.cisco.com) initiative managing SLAs via XML-based management interfaces and a call policy markup language (CPML) version of XML from DTI Networks Inc. (www.dtinetworks.com), a Class 5 switch vendor (see "XML: Mighty Muscle for Next-Gen IN?" Feb. 2000, X-CHANGE). CPML decouples the switch software from the hardware, enabling a web-based user to program and easily implement customized voice feature sets.
XML for IP Service Delivery
XML also will play a key role in service delivery initiatives. That is, XML-based vocabularies will be the key to enabling on-demand IP services such as video-conferencing, software rental and web hosting. Picture it: A common vocabulary that lets you define individual service offerings. Both business and technical characteristics are incorporated into the service-specific definition. Because of the common XML framework, the service definition can be readily exchanged between the new breed of telecom service portals, ASPs and NSPs. This paves the way for a realizable consumer/retailer/wholesaler model for on-demand IP services.
The Exponential API Nightmare
Of course, network providers and enterprises have long been working on implementing rapid service delivery. The big issue with rolling out new services is the codependencies between multiple operations systems. Efforts to integrate these systems can often derail implementations. This torturous process can be described as "the exponential API nightmare."
Let's do the math. For every two systems that need to be linked, as many application programming interfaces need to be developed so the disparate systems can talk to each other. Now, extend the number of OSS applications to, say, five. Each system is matched with an API and each must communicate with the others in a mesh topology. Five systems equal 10 integration projects (see "The Exponential API Nightmare" diagram, below), while 10 disparate systems result in 45 individual integration projects to get flow-through service activation, monitoring, billing and so on. This nonlinear problem quickly spins out of control and creates a very brittle OSS environment with lots of codependencies. Making even the smallest change becomes difficult, time-consuming and prone to errors.
Chart:The Exponential
API Nightmare
Information exchange would be vastly simplified if all systems spoke the same language, at least for specific tasks. With one common language stored in a single repository, publication of and subscription to advanced IP services would be vastly simplified and on-demand activation would get one giant step closer to realization. The Esperanto in this scenario could be XML, or, rather, an XML-based vocabulary specifically geared to the services delivery environment.
XML provides a common way to represent data from disparate systems. When linked with a common database in which to store all the data elements, XML presents the solution to the exponential API nightmare. Each system publishes information into the repository and each selects, or subscribes to, the information it needs from the same place. The application subscribing to the data is indifferent to the source; that is, the subscriber doesn't need to know who the publisher (producer) is, thereby immediately reducing the level of complexity. The application also doesn't need to know where the source is. Mesh integration is replaced by a hub-and-spoke configuration effectively limiting the number of integration projects to the number of systems.
The Delivery Chain
Several technology suppliers and industry consortia have already recognized the value of XML-based service delivery solutions. They are forging ahead with developments that address specific aspects of the service delivery chain (see "Simplified Service Delivery Using XML" diagram, below).
Chart:Simplified Service
Delivery Using XML
Metered service information exchange (MSIX) is an XML-based protocol originally developed by NetCentric Corp. (www.netcentric.com) and Compaq Computer Corp. (www.compaq.com) that allows network elements to send billing information to billing systems. MSIX provides billing-oriented service definitions, reporting of billing information based on a service definition and a request-response protocol that controls operations. When the network elements handle a call, MSIX is used to generate a session record that contains the billing information for the call. This record is then sent to the billing system.
MSIX is easy to understand and use. It provides the means to exchange information needed to bill for services--that is, to create a billing service definition. The network vendor may define a billing service definition independently of the network service provider. In addition, MSIX has been submitted to the Internet Engineering Task Force (www.ietf.org) and is backed by several XML and billing industry players.
Cisco is using XML as a tool to exchange data related to monitoring and reporting on SLAs. Its service level management (SLM) suite uses XML-based interfaces to collect and exchange data between different vendors' systems, which then enables end-to-end monitoring of SLAs. More than 30 vendors have signed up as partners, including Computer Associates International Inc. (www.cai.com), Hewlett-Packard Co. (HP, www.hp.com) and XACCT Technologies Inc. (www.xacct.com).
XML-based management interfaces enable the network service provider or IT manager to collect service-level metrics from a variety of systems that are part of, or connected to, the network. Problems can be detected and reported with actionable information about whether the problem is in the network, the hosted application, or the client. Partners can use the XML-based interface to control and retrieve service-level information collected by the Cisco SLM product suite to better control their applications.
Abatis Systems Corp. (www.abatis-sys.com) has taken the plunge into developing a comprehensive language that considers all aspects of IP service delivery to bring on-demand IP services to life. Called XML/Services, it covers the business and network requirements as well as the billing requirements for service setup and activation. Abatis has combined this new XML vocabulary with a publish-and-subscribe mechanism to allow ASPs, ISPs, NSPs and service portals to exchange service description and subscription information. Abatis believes XML will be to network-based services what HTML is to Internet publishing.
Any ASP with an application to offer publishes it using XML/Services. Any interested service portal will receive notification of the new service offering via XML/Services. The service portal now can add the service offering to its retail portfolio. When a customer surfs the portal and purchases an application, XML/Services is used to create the subscription. Now the NSP and/or ASP will receive notification, via XML/Services, of this service request. The ASP then provisions the necessary resources to provide the application to the new customer while the NSP provisions the network to ensure that the application is delivered with its required QoS, security level and statistics.
An XML/Services Scenario
Despite great strides, videoconferencing remains a "killer app wannabe" because it's still relatively pricey and complex. So, why not apply the same model that has been used for value-added voice features? Use the customer's desktop equipment, add in the enhanced features and reliability of a network-based application, and guarantee sufficient bandwidth and performance over the company's existing local access. In other words, set up a high-quality service that's as easy to use as a voice application, in a pay-as-you-play manner.
The advent of XML/Services, as well as the underlying Abatis architecture, makes this possible. The ASP uses XML/Services to define the service in terms of bandwidth, jitter, delay, IP address of bridge, setup charge, charge per hour and other requirements. XML/Services data gathered from the subscriber includes customer identification, participants' IP addresses, billing information, conference date, time and duration. The service portal communicates the order details to a device called the Abatis Network Services Contractor (NSC), utilizing XML/Services. The Abatis NSC then translates these details into service, provisioning and billing requirements, maps them to the network and automatically configures the network edge devices. It virtually links service portals, application service vendors, service providers and the network and dynamically activates service channels with unique performance, bandwidth and security characteristics.
Now service providers can move to a new services model, one analogous to the cable TV model. In this services paradigm, corporate subscribers order service channels such as a videoconferencing channel or a software rental channel from their service portal with the same ease and simplicity as ordering a sports channel or a pay-per-view movie. In this analogy, the videoconferencing scenario described earlier can be likened to the pay-per-view movie--a one-off situation. Alternatively, longer, or even indefinite, duration applications, such as VPNs, are analogous to the sports channel selection.
With an XML-based language as the underlying technology, and the exponential API nightmare solved, both on-demand IP services and collaborative service delivery become possible. Each of these brings significant value to the table shared by NSPs, ASPs, service portals and technology suppliers. As network providers, CLECs in particular stand to benefit: On-demand applications services translate into significant new revenue opportunities, and collaborative delivery (with national carriers, for example) extends the CLEC's service footprint with minimal integration effort.
XML-based solutions make it possible to offer a broad portfolio of network and applications services on demand. With XML-enabled service delivery, carriers can rapidly design and sell innovative and targeted services. XML's openness and flexibility allow carriers to exploit the advantages speed offers: speed to market, rapid service deployment, and real time subscription and activation. An end customer can get what he wants, when he wants it, for however long he wants it, and at a price he can afford. That kind of speed and responsiveness translates into customer retention and new cus-tomer acquisition.
XML-based vocabularies can electronically link all the players in the service delivery chain. Collaboration becomes not only possible, but also mutually attractive.
ASPs now have a tool to cost-effectively publish network-enabled applications. Web-based service portals can package these new application services to cover more of their customers' business needs. Network service providers can easily deliver these services on demand through their existing infrastructures.
While the scenario above describes three distinct functions, it's not a given that three distinct entities must be involved. As the network provider, the CLEC, for example, is well positioned to assume more than one role. It can partner to create expansive and robust service portfolios, even outside its own territory. The ability to exchange XML-based service information with other carriers extends their service footprint to new locations and simplifies resale.
Exploiting new technologies such as XML holds the promise of on-demand pay-as-you-go advanced IP services. The IP services industry is leading the charge. This industry will depend on XML-based vocabularies to provide a common framework and to facilitate the rapid creation, subscription and delivery of advanced IP services. With XML and the emerging architectures, service providers are poised to take advantage of an IP-based wholesale/retail/consumer system and to bring to market new portfolios of advanced IP services--from software rental to application outsourcing and on-demand videoconferencing--making 2000 the year of services.
Adam Lorant is co-founder of Abatis Systems Corp. (www.abatis-sys.com). He can be reached at Alorant@abatis-sys.com.
