Standards Watch : Java Awakens OSS Interoperability

When it comes to network inventory, service provisioning, order entry and billing, service providers have faced a fragmented OSS market filled with proprietary systems that cannot interoperate effectively without costly and time-consuming integration work. According to industry figures, more than 50 percent of spending goes toward non-reusable integration work.

Working toward innovative OSS standards for 3G wireless applications, a group of network manufacturers, middleware providers and OSS- and billing-focused companies are combining efforts to make Java technology the de facto standard platform for service provider applications.

“Whether you are an incumbent or an emerging player, at the end of the day, whether you own your infrastructure or not, you always own the OSS and BSS system; that is what differentiates you from others. You never farm out the OSS/BSS systems,” says Philippe Lalande, program manager for the OSS through Java (OSS-J) Initiative.

The initiative’s focus will be to develop a process to define and implement Java-based APIs for OSS and BSS systems and is designed to accelerate the development of 3G OSS components.

Companies actively participating in OSS-J include Sun, Cisco, Nortel, Ericsson, Motorola, NEC, ADC, BEA, InfoVista, Objective Systems Integrators, Remedy, Cygent, Agilent, BEA Systems, Digital Fairway, Orchestream and Telcordia. These companies have defined vertical APIs that can be reused on top of OSS-J. So far the companies have built four multivendor demonstrations integrating more than 30 products.

The initiative will focus on three initial API specifications of OSS-Java technology for public review: trouble ticket, service activation and quality of service. These three APIs are being standardized under the latest Java Community Process (JCP) program, which has been the foundation for the Java 2 Platform, Enterprise Edition (J2EE), JDBC API and Java Messaging Service.

The JCP deliverables for each application area will consist of a specification, a reference implementation and a technology compatibility kit. All of these, including source code, will be freely available to the market.

The Java Specification Requests (JSRs) were approved by the JCP Executive Committee, and three expert groups are currently being created.

“We want to foster and create a market for third-party components in the OSS/BSS space that easily integrate in turning solutions over for anything for network management, provisioning, service activation, billing and customer care,” says Lalande. “Our vision is to achieve adoption of telco-specific APIs, creating a components market and leveraging the investment in middleware and products with other industries.”

In addition to running real data networks in the context of 3G wireless, the OSS-J initiative also is creating a new application area for IP billing.

The IP billing JSR (130) was approved in June, and the group is the midst of recruiting experts to participate. Companies can nominate experts through a standard submission form found at www.java.sun.com; so far, Amdocs is the first to do so.

The JSR 130 project is being led by NEC. “I can’t believe how little Java there is in the telco space,” says Ken Dilbeck, director of software development at NEC America. He notes that few billing companies are members of the JCP. Dilbeck plans on formalizing a telco expert group by mid-July.

“As 3G rolls out, the increase in IP services will make convergent billing an even greater issue,” he says. “Everyone knows we as an industry do not have an adequate billing infrastructure for all new IP services. We want Java to be pervasive in telco, as it is in other verticals, such as technology, e-commerce, finance, enterprise and the Internet world.”

Dilbeck points out that JSR 130 does not compete with existing specifications; rather, it is an API-focused implementation. “IPDR.org, for example, is putting together specs for what a billing record will look like; Parlay is working on call setup; and 3GPP is working on charging and accounting. We don’t want to compete with those specs. We will not specify what a billing record will look like. Rather, we’re trying to implement in such a way that those specs are realized in Java code,” Dilbeck explains. “We are defining APIs that would implement those specs—APIs from billing systems to mediation or network devices, that can then provide billing information for IP services.” Upon completion of public review, he adds, each final API specification, with its associated reference implementation and test suite, will be licensed for free.

Those API specs will enable service providers to mitigate the costs of new technologies, since they will facilitate sharing the investment with other industries, as well as leverage a population of skilled developers. “If you give an API specification to a technical expert, the OSS-J API definition is built on a standard for information modeling that has been around a long time. That means you are standardizing within the Java cloud rather than using proprietary solutions,” Dilbeck notes. He believes service providers also will benefit from having more application servers and more middleware on the shelf. “The new APIs leverage standard enterprise development technologies, commercial off-the-shelf products and widely available skilled Java programmers to enhance OSS,” he says.

Concurring is Lalande, noting that Java will enable telcos to share the risk of new technologies with other industries. “When you combine that with the advantage of developing faster, easily maintained code, you increase your value proposition because you decrease the time necessary to port from one environment to another,” he says.

He, too, points out that OSS-J should not be confused with other standards, such as TMN, a reference model, and common management information protocols for telco-specific areas. “Because those standards were designed specifically for the telco industry, the result has been that few developers really qualify as experts in that technology, which has led to a bottleneck in quick implementations,” Lalande says.

He cautions that people should not consider the initiative an attempt to create an end-to-end standard. “We are not trying to standardize the workflow or business processes or end-to-end scenarios that service providers and SIs may build,” says Lalande. Rather, the focus will be on individual APIs that will serve as building blocks.

“It’s the service providers that will have to come up with services to differentiate themselves; we are just trying to make life easier for network equipment vendors, ISPs, carriers and wireless carriers by reducing integration work,” says Lalande, noting it will be 3G providers that will have to implement the business scenarios driving the flow of information through integrated products. “SIs and service providers will build the business logic upon the J2EE platform and XML, standards from the TMF, 3GPP and 3GPP2, which will provide the reference models for the definition of the Java technology APIs.”