Java: Ready for the Big Time?

When Sun Microsystems first brewed up the Java programming language in 1995, the object-oriented technology hit the computing industry by storm. It is said to be easier to learn than C++ and can be used for applications that run in a distributed network environment among servers and clients. At that time, however, telecommunications providers were not about to incorporate something untried and untested into their back office systems. Today the industry seems to be opening its doors to Java mainly in operations support systems (OSS) as a pathway to billing. Providers are exploring JavaBeans and Enterprise JavaBeans (EJBs) to determine where the technology still must mature to meet the industry’s needs.

“Java is at the stage in its life cycle where people are increasingly trusting it as a technology,” explains Gary Barnett, director of research at Ovum. “The major missing pieces that really bedeviled Java a couple of years ago—really good development core support in terms of the maturity, the infrastructure, the underlying middleware that supports the Java platform—are beginning to fall away.”

Barnett says, “My advice to corporate customers is still that they would be mad to throw away all their COBOL or their C++ tomorrow and make a wholesale move, not because of any intrinsic weaknesses in the Java technology itself, but because they have an existing investment in all this older stuff—so why rock the boat too much?”

What’s in a Bean?

JavaBeans is an object-oriented programming interface, a component architecture that runs on any platform under Java’s “write once, run anywhere” philosophy. It runs on every operating system or in any application environment, such as a browser or word processor or another application. Through Java statements, beans can understand the characteristics of one another. The beans also have persistence and can recall information about other beans in a future version.

The idea behind a JavaBean is to look at pieces of executable code as component technology versus source code or code to be linked, explains Douglas Tait, network architect at Sun Microsystems. With JavaBeans, a developer builds components together to make a service. These components are linked at run time.

An Enterprise JavaBean is built on the JavaBean technology. It is a container architecture that sets up program components. EJBs allow a network operator to make changes in the server versus at every client when something is installed or taken away, enabling a company to do more distributed types of processing.

[END SIDEBAR] How Could ‘Billing Beans’ Work?

Today, Call Detail Records (CDRs) contain basic data such as initiation duration and termination information, explains Douglas Tait, network architect at Sun Microsystems. The CDRs are put into a database in the back office, where a company will process them and bill subscribers. “This is a very fixed and constant billing,” Tait says.

He believes that by using Java the billing component could be brought forward to collect data on more dynamic events such as the number of hits to a Web site or the number of times a subscriber presses star-7 on a cellular phone.

Tait says developers could employ a “billing bean” or a “service bean” with some billing instrumentation in it. He maintains that convergence will push microbilling, where microcomponents are inserted or instrumented into a service anywhere in the network to measure for billing. At any point, Tait explains, a manager could go in and turn off this billing aspect within a bean, or a bean can be activated to start tolling or collecting from a certain point on.

Slow Road to Change

“In many cases, carriers are very wary to try something new,” says Paul Hughes, research director for billing and payment applications at The Yankee Group. “They want tried-and-true versus next-generation. They want to see results. They are going to want to see testing that proves that it is going to be reliable. There is always a fear in implementing something new like this.”

Companies like Winstar Communications have been toying with Java since 1996, according to Robert McLaughlin, senior director of systems architecture at Winstar. Yet the company did not start deploying the technology until 1998, when it used Java in a system that tracks antennas on building rooftops. While the company is looking at Java for order management, it is not currently putting it to work for billing.

“Billing is so crucial to your company. It’s the one thing that if you screw up, you get to hear about it,” McLaughlin says. “So, actually going out and saying ‘I’m going to swap your billing system that you know works for one based on Java’ really is not going to get you a great reception right now.”

He says adoption at Winstar will be gradual. “I have to take a step and demonstrate that the technology works, that the technology is actually saving Winstar money. So, I make my business case, and they let me do something, then they let me do a bigger thing and a bigger thing.”

A Growing Acceptance

Despite the slow evolution, what is driving the recent push for Java in the telecommunications world? Philippe Lalande, senior product line manager, telecom management, Java management, at Sun Microsystems, believes the Internet is clearly one of the driving forces and cites the fact that Java has proven itself in the Web space.

One company that developed its technology in Java is eVergent, a company that specializes in electronic billing and customer care. The company uses WebObjects, an application server technology that offers object relational mapping tools on a scalable platform.

In the past, says Doug Galligan, chief technology officer at eVergent, a company typically had many different people doing the data modeling and the coding of business objects on large project. The coupling between the two was mostly custom written, and a company would have to explicitly identify different columns and rows in different tables and make various calls out to the database to get that information. WebObjects allows a company to find not only the volumes of the columns and the rows, but relationships between the different objects in a graphical tool. Then it does the mapping to the database. This capability allows a company to switch from database to database fairly easily.

“We’ve seen tremendous productivity gains using this product for mapping out our objects and storing them in a relational database. It’s extremely mature and we’re finding really good performance,” Galligan says. “It’s really enabled us to do the type of work that we did [in other companies prior to using Java], but with substantially fewer people and substantially less time needed to actually develop a large transaction system like a billing system.”

Flexibility of Java Beans

A major benefit of using Java is its inherent flexibility, Tait says: “I can build services from scratch, or I can enhance services that are already deployed.” In telecommunications, pulling out a component or adding one that enhances the service without taking the service down is important. “I can do inline straight code like you do in a traditional sense, or I can grab a graphical user interface and see these beans as actual building blocks that I can move onto my palette and connect and interconnect. Or, I can see them in a call flow diagram and interconnect them that way. If I have that flexibility in building them and configuring them, I have equal amount of flexibility in taking the components out and putting new components in.”

Reusing the Beans

A measure of the Java flexibility is being able to unplug and reuse the code. “I see these beans and these components being used and reused everywhere,” Tait says.

Another company employing Java technology for billing is iPlanet e-Commerce Solutions, a Sun/Netscape alliance. Formed in March 1999, iPlanet has developed BillerXpert 4.0, a 100 percent Java product that uses “servlets,” Java Server Pages and EJBs to perform billing functions. Stanford Au, vice president of customer relations management systems at iPlanet, says the ability to use EJBs at a business logic level to reuse that logic is why iPlanet uses this technology.

In addition, JavaBeans addresses convergence across multiple network domains, allowing a company to run a service on any network. “I could have a call control element or service that I could then plug into my telephony network for doing traditional call setup and tear-down; or I take that same application and plug it into my IP network or the Internet to do call setup or call tear-down,” Tait says. “That same service does not have to be reinvented for either of those two networks.”

Increased Competition

Providers also stand to benefit from increased competition among vendors. The Java technology could lead to more choices.

“If the JavaBeans stuff actually holds the promise, I will be able to go out to a number of vendors and pick the pieces I want to build my enterprise,” McLaughlin says. “That way, I can make my enterprise slightly different from some other enterprise, and I can go into business quicker than they can.”

Many of the standardizations thus far have tried to stay technology-neutral, because that was the only way a solution would be vendor-neutral. With Java, a company can stay vendor-neutral, regardless of the underlying technology. In addition, being able to change, create, activate or deploy new services quickly is critical especially with time-to-market concerns.

Cost Drivers

McLaughlin explains that Winstar’s move to Java was driven by saving on operating costs. The company had built its own order entry system, and despite being well-received, he notes, the system was client-server in the worst sense. A lot of software was running on a server, and a lot on the client. “Every time we actually do a full number release, like go from 6 to 7, we end up replacing more or less all the desktops [about 1,000] that use this order entry platform; and when we do point releases, it takes us about three weeks to straighten out the mess that the software management system does,” he says.

“Our hope with Java is that when a new release pops in, we’re actually not running most of it on the client, we’re running it on a server behind the client, so we don’t really have to do massive machinery upgrades and spend a lot of time and energy doing software management systems,” McLaughlin says. “When the person clicks in, they get the latest release of the software.”

Integration

Lalande explains that most of the spending on a system happens when integrating different applications. Because this is done on a one-to-one proprietary fashion every time, providers enact a lot of one-shot integration. “This is painful for everybody,” Lalande says.

Many argue that the JavaBeans component-based architecture makes integration with other systems much easier, reducing the time involved and the cost of integrating. Using Java is a quick way to integrate two systems and translate the transactions between the two systems, McLaughlin says.

Tim Daniels, vice president and chief architect of product development at Aptis Inc., explains that if an entire system were written in EJB architecture, a company could have a dedicated server just for a billing and calculation engine, a rating engine or customer care. The EJBs would keep it all tied together, coordinating those processes and updating the database accurately across that distributed environment. Daniels says this can be done without CORBA when using EJBs.

However, if a company had a rating engine written in C++, a bill calculation engine also written in C++ and a customer care engine written in Java, coordinating those would require CORBA. A CORBA layer would sit over all of those distributed processes to keep them all synchronized and tied together. “That’s why EJBs and JavaBeans are all CORBA-compliant,” Daniels says, “because you don’t ever know what other systems you’ll have to integrate with over a distributed environment.”

Integration Challenges

While McLaughlin says there are advantages to JavaBeans technology, it does not work completely because not everyone agrees on what definitions of the objects are.

“It’s a lot harder than it sounds,” he says. “There are a lot of fields involved. Two groups think they have the same name, but they have different meanings. …You get three different people in a room and they all have different definitions of ‘customer.’ ” McLaughlin believes it will take a couple of years to actually work out the kinks between the various vendors.

Integrating Java technologies with other systems, particularly legacy systems, is no more difficult than with any other technology according to Ovum’s Barnett. “Integration would be easier if there were one single operating system, but it’s not going to be that way,” he says.

Performance Issues

In addition to integration challenges, developers are confronting performance limits. With Java, a lot of bits are flying over a company’s local area network, McLaughlin explains. When a company is running Java, Java applets and JavaBeans, the supporting infrastructure must be very tight and pretty much the same everywhere. But that is not really the way the infrastructure has been built out, McLaughlin says. It’s been based on the client-server model: clients are terminals with software on them that are closely associated with data. Yet, Java and EJBs offer the ultimate distributed model. Actual programs or messages between them are moving around, so networks have to be hardened— than if only data were flowing, McLaughlin says, and they have to be a lot faster. “This stuff is requiring a lot more bandwidth inside your network,” he says.

In addition, the Java goal to write once and run anywhere means that it is an interpretive language, or interpretive interface. In order for it to run on a platform, the virtual machine interprets byte codes right down to the native interface, so it looks at the byte code and then interprets the action on the computer, Sun’s Tait says. That interpretation has usually been very costly in terms of performance. He notes that the interpretation went from a 40-to-1 degradation in the switch from C++ to Java. This has since been reduced to about 10-to-1 with Java’s second release. Developers, he says, are coming up with additional ways to fix this. “I see it as an engineering problem. All you have to do is throw a whole bunch of engineers on it, and eventually we’ll fix it,” Tait says.

Tools and utilities are being developed that perform a real-time dynamic compilation down to native code with a 1-to-1 correspondence, or relationship in performance with C++. “We’re solving this problem,” he says, “but when we get down to the hard core, fault-tolerant highly available fail-overs have to be within subsecond range well into the heart of the network.” This means that a company must avoid dropping calls that are set up. Tait says this requires a recovery speed of less than a second for every call. For a single call, this is not an issue; yet, for thousands of calls that could be dropped, this translates into lost revenue or potential customer churn. Tait says it will take time to get a grip on this problem.

Where Will This Play Out?

According to experts, Java is poised to take off first in the wireless market and second in OSS. Sun recently announced its Next Generation OSS Through Java intention. It has joined with Ericsson, NEC, Nokia, Nortel Networks and Telcordia Technologies Inc. in an effort to define Java-based APIs for OSS and business support systems.

The current process in which businesses develop their own APIs, then either allow access to them or not, is often criticized for being highly fragmented and requiring heavy integration. Aside from the high cost of integration, it slows the roll-out of new services for which time to market is critical.

The open industry effort will first define a very limited scope to address applications for 3G wireless systems. As Sun’s Lalande explains, “We believe that because the 3G wireless network will be computing-nascent, it is an opportunity for service providers and carriers to deploy brand new infrastructure for their OSS and BSS systems.”

The industry group will focus on trouble ticketing first because, Lalande says, it is the easiest to tackle. Then it will look at performance and quality of service. Finally, it will address what Lalande deems the most complex task: implementing Java for service activation and provisioning. “This is a more revenue-generating type of application, and there are some new challenges that are brought by IP on wireless phones and Internet access through wireless handsets, and that will probably structure a lot of the rest of the OSS and BSSs,” he says.

Right now, McLaughlin is working on the order entry and order processing product for Winstar. Yet, regardless of what area Java infiltrates first—OSS or billing—the systems must still be able to communicate. Galligan at eVergent says TCP/IP connections can be used to access legacy systems. Likewise, XML is a way to send and receive self-describing data between two systems, he notes.

If Lalande’s group can build, demonstrate and test the use of Java in the OSS space, then billing would be the next step. “Billing,” he says, “is a very hot topic—especially IP billing.”

Sidebar: Jumping on the JavaBeans Bandwagon

Aptis Inc. is a company that has incorporated the JavaBean technology into its latest billing architecture. Aptis uses object-oriented JavaBean servlet technology to allow middle-tier platform independence. It offers a browser-based user interface to link to back-office functions.

Tim Daniels, vice president and chief architect of product development at Aptis, gives an example of how a user would sign onto a system using JavaBeans: The user would set up an account using a browser. The HTML page taking the request would interact with a servlet, which would be invoked to take care of the process flow. It would present a screen—another Web page—for entering customer information. The user would enter the customer information, which would interface with a servlet that knows which JavaBean to invoke to process the customer information and format it in a way that the billing platform can accept.

Aptis uses JavaBeans to invoke the business logic program sitting on the billing server or platform. The servlet waits for the business logic program to finish its process. Then the servlet will generate another Web page to display that the customer was successfully established, or that the customer was rejected and why. Part of the servlet’s job is to maintain that persistent connection and flow of information from the end user to the back-end server. “JavaBeans are just a simple, fundamental component. Each one does a simple little task, but in order to organize all those tasks into a logical business process mode, we use the servlet technology,” Daniels says. Aptis must use an application server to execute the servlets.

The multitiered architecture allows a company to make many types of changes without affecting the servlets, the JavaBeans or the back-end business rules. The presentation layer, the middleware, the business rules and the database are all independent.

In the Aptis system, JavaBeans act as a gateway either for a graphical user interface, like a Web-based user interface, or to integrate to other applications such as OSS that need a gateway to the billing platform to establish information about a customer. Daniels says this technology provides an easy gateway for integration to its billing platform.

Daniels believes other companies will soon be jumping on this new technology. But he also believes most communications providers are currently struggling with forming a strategy for how to migrate to the new architecture, while at the same time protecting the investment in their legacy systems.