 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Press and Success OSS Through JavaTM APIs Enable Rapid Assembly of Business Components:
For years, these representatives discussed these issues while serving on various standards bodies. So what they told Lalande was not new, but increasingly urgent. The economy was slowing down at the same time that demand for communication services was skyrocketing. Yet nearly half of the $50 billion spent in the OSS market was for custom-made solutions that were painful, hardly reusable, and expensive to maintain year after year. By October 2000, fifteen companies that belonged to the Java Community ProcessSM (JCPSM) program formally agreed to participate in what is now called the OSS through JavaTM (OSS/J) Initiative. The original core OSS/J companies were Sun, Cisco, Ericsson, Motorola, NEC, Nokia, Nortel, and Telcordia. With Lalande as program manager, the OSS/J Initiative used the JCP program to bring technologies based on Java 2 Platform, Enterprise EditionTM (J2EETM) to the OSS market. Lalande explains, "We chose J2EE as the underlying platform to use mainstream enterprise technology, in order to share the investment with other industries. We focused on functional OSS APIs, and chose the JCP to produce developer friendly APIs, to foster a market of certifiable OSS components, and to seamlessly extend the capabilities of the Java platform." The OSS/J Initiative Begins The fledgling OSS/J Initiative recognized the need for an ongoing technical advisory committee to promote the vision and goals of the group. Led by Pierre Gauthier of MetaSolv, the Architecture Board comprises representatives of the core companies. Responsibilities included determining how to structure OSS Application Programming Interfaces (APIs), advising OSS expert groups, and deciding which OSS areas to address next. To encourage the implementation of JCP-approved OSS specifications, OSS/J member companies create relevant tools and hold informational seminars and demonstrations of OSS/J technology. Early on, the Architecture Board recognized the need to base OSS/J technologies on common architecture guidelines and JCP standards. "We complement the JCP program," Gauthier said. "The mission of the Architecture Board is to turn the OSS/J vision into concrete solutions that meet the OSS market requirements and the general software industry trends and patterns and to speed up the development of specifications and reference implementations." For multiple Java Specification Requests (JSRs) that relate to a common vertical market, it is extremely important to overall productivity and efficiency to maintain consistency from one specification to the next. A developer who learns the concepts in one API can more easily understand and implement related APIs. To ensure that such consistency was built into all OSS/J JSRs, the Architecture Board produced the OSS/J Design Guidelines, a set of industry-accepted design patterns and component definitions that OSS/J spec leads follow. Under these guidelines, specifications and reference implementations are easier to create and better in quality. Architects from OSS/J member companies -- plus Spec Leads for the first three OSS/J APIs -- formed an Expert Group to create JSR 144 OSS Common API, led by Daniel Lutoff of Sun. To provide consistency and reduce duplication of common interfaces and classes among the OSS/J specifications, the Expert Group extracted what was common among the three APIs to create the first technical umbrella JSR. The resulting specification includes the OSS/J Design Guidelines.
Every OSS/J JSR is an implementation of "The Common API." "Each time a new OSS/J JSR is started, it reuses the results of the common work done by the OSS/J Initiative, now standardized as JSR 144," says Lutoff. Using this template as a foundation, Expert Groups can worry more about technical issues and less about how to format the content. Lutoff believes these programmatic rules and standardized classes are useful for any JSR that sits on top of J2EE technology. Rick Porter, the JSR 90 Maintenance Lead, reports that JSR 144 is also used internally by companies. He says, "When we at Telcordia are designing an interface to one of our systems, we've looked at this as a good way to make our interfaces open." Standard Components Needed for Service Activation Although an entire spectrum of APIs is needed, the Architecture Board first addressed those defined as crucial by the telecommunications industry. For an industry straightjacketed by proprietary solutions, OSS/J APIs were developed to enable the assembly of commercial off-the-shelf-components, resulting in end-to-end OSS solutions for key functions like provisioning, billing, and so forth. Those end-to-end solutions have proved elusive until now and deliver huge value to service providers. When JSR 89 OSS Service Activation API was submitted, no standard components existed for the service activation area of OSS. Each available product addressed only a tiny aspect of all the processes that had to be handled. These components could be purchased from many sources, but they were are not interoperable. For a complete solution, customers had to write specific code to integrate the different components, a tedious, costly, and non-reusable venture. Spec Lead Stefan Vaillant of Nokia expected JSR 89 to reduce integration efforts by creating a set of standards that would enable the creation of a reusable software component market. Maintenance Lead Andreas Ebbert of Nokia says, "The products we expect to show up are components that don't differentiate in terms of the proprietary interfaces but in terms of the functionality and quality they offer." Then users can select components that match their needs best and plug them together with minimal effort or cost.
In the environment that OSS/J technology is making possible, companies can develop new products. Ebbert notes, "It's a pre-competitive environment because there has been no OSS component market until now. That's what the excitement is about -- to develop interfaces that enable a whole new market." IP VALUE, a startup in Germany, looked for a business opportunity and found OSS/J technology too compelling to ignore. At present, IP VALUE's sole product is an OSS/J-certified implementation of JSR 89 that enables flow-through, zero-touch service provisioning for overcoming bottlenecks caused by inefficient manual processes. This implementation is part of IP VALUE's Service Creation Factory product suite, which enables service providers to deliver enhanced, value-added services quickly, easily, and efficiently by automating and streamlining the service delivery processes. Chief architect Thomas Schmal of IP VALUE says, "Using standardized APIs for automating the service provisioning process reduces the integration costs for our customers significantly." This is why OSS/J technology is perceived by IP VALUE's customers -- regional service providers as well as major mobile operators -- as a telecommunication market focused, component-based enterprise application integration (EAI) approach. Pilot installations at T-Systems, a division of Deutsche Telekom Group, are used for demonstrating the flexibility and cost reduction capabilities of the Service Creation Factory. In another certified implementation of JSR 89, Intracom offers a Java-based transactional service activator, which allows an engine to roll back to an earlier step when a step fails during a multi-step activation, thereby preventing underlying network resources from crashing. The Mobile Workforce Management OSS/J Solution by IBM Business Consulting Services is a third product implementation of JSR 89. MetaSolv has two JSR 89-based pre-products in the works. One is an Automated Service Activation Program (ASAP) to communicate with multiple heterogeneous network technologies across diverse technology domains, and the other is an Order Management System (OMS) to offer precise control over service provisioning. Nokia and Digital Fairway are also developing pre-products based on this API. Quality of Service API Piques Interest Some OSS/J equipment vendors as well as Telcordia, one of the largest OSS providers, saw a critical need for a Quality of Service API. "Telcordia builds OSSs, which would be clients of the API. The Quality of Service API allows us to build an adapter that will talk to any Element Management System (EMS) that implements the API, so it makes integration a lot easier for service providers," says Telcordia's Rick Porter. Porter is Maintenance Lead for JSR 90 OSS Quality of Service API, which, under the original Spec Leadership of Stefan Aberg of Ericsson, addressed performance measurement, performance thresholding, and fault monitoring.
JSR 90 went public November 2002, but 3rd Generation Partnership Project (3GPP), focusing on standards for the GSM, GPRS, UMTS markets, and 3GPP2, focusing on standards for the CDMA, cdma2000: 1X-RTT, EV/D0 and EV/DV markets, have not yet completed final specifications of their Performance Management interface standards. The Quality of Service team understands the importance of aligning with 3GPP's and 3GPP2's effort and is working towards alignment between the two specifications. Motorola is leading the alignment effort between OSS/J, 3GPP and 3GPP2 along with many of the OSS/J companies. While some may be waiting to compare 3GPP's final specification with the performance part of JSR 90, there is considerable interest in the API, as indicated by over six hundred downloads since November. Several OSS/J companies are already using the specification internally, and Telcordia, Digital Fairway, and Nokia are now developing OSS/J-compliant software that could be productized. Several products have already hit the market. Mycom International offers a product, NIMS-PrOptima, based on its early adoption of the API. NIMS-PrOptima is a scalable and carrier-grade Next Generation Performance and Service Management platform, whose importation engine interfaces with a variety of data sources. IBM Business Consulting Services employs JSR 90 in its Mobile Workforce Management OSS/J Solution to support network fault monitoring and Quality of Service/Service Level Agreement management. ILOG JTGO employs JSR 90 to offer the first complete suite of Java graphic components for OSSs. Now considered a de facto standard, ILOG JTGO was named Best Java Component in the Java Developer's Journal Readers' Choice Awards for 2002. Winning this prestigious award "speaks volumes of the value ILOG JTGO \par brings to the software development professionals who are bringing the next-generation operations support systems to market," says Doug Doyle, ILOG's vice president of marketing. Trouble Ticket Considered Essential Technology Trouble ticketing is considered an essential component of any OSS, and for good reason. According to Spec Lead Pierre Gauthier of MetaSolv, the JSR 91 OSS Trouble Ticket API offers at least three substantial benefits to implementers.
First, a standard, open interface helps developers integrate many types of information systems together. The API's flexible structure makes it possible to do several things: call a trouble-ticket system using the integration of a work-flow engine, have a customer-care application send a trouble ticket to a service provider, have an event management system automatically generate a trouble ticket, or have a service provider generate a trouble ticket. For companies that are beginning to use Enterprise JavaBeansTM (EJBTM) and J2EE technologies, the Trouble Ticket API offers a second benefit: a mechanism in which to wrap their trouble ticketing system. As Gauthier puts it, "They can plug their own entity bean into this infrastructure, and they get all the rest for free -- the XML messaging and the session bean facade. This plug-in infrastructure has been extremely useful for a number of companies." Third, trouble tickets are a part of business-to-business relationships. A number of companies have expressed appreciation for the API's Extensible Markup Language (XML) interface, viewing the XML part of the API as "one of the finest XML specifications they've seen so far for that topic," says Gauthier. The Trouble Ticket API had a number of early adopters, including NEC, Siemens, and Telegea, some of whom either implemented the technology into their existing products or modified it to fit their infrastructure. To encourage the adoption of JSR 91 by other companies, ILOG developed a module that can generate OSS/J-compliant trouble tickets. Digital Fairway has a pre-product, eOSS Product Suite, that is not yet generally available. Herschel Technologies' pre-product, Herschel Integration Suite, can integrate any CORBA-based Network Management system with trouble ticketing systems based on the API. IBM Business Consulting Services has used the specification to provide for trouble ticket resolution in its Mobile Workforce Management OSS/J Solution, a commercial product. Generic Transport Mechanism for IP Billing New data services are constantly being defined, but until recently no standard API existed for integrating the collection of usage data for these services into a service provider's billing environment, says James Jouett of NEC, Spec Lead for JSR 130 OSS IP Billing API. Now that JSR 130 provides a generic transport mechanism that all the different devices can use to communicate with the billing system, various parties stand to benefit.
For example, if a provider decides to offer a new service, they nearly always need to manually code in the transport capability for sending usage data from the new server to the billing system. But by implementing the API, it's an off-the-shelf job, not a custom one. This specification allows a billing system to easily integrate any number of usage data sources, supporting the convergence of IP and traditional services. Since the API allows the transfer of data in any format, regardless of the content, it can be applied to any technology or service that provides usage data for billing purposes. Even though the spec has only recently gone to Final Release, as of January the API had been downloaded over one thousand times, indicating strong interest in the community. NEC is currently working to implement the API for some of their network management and mediation products, which should be available this year. Development and Implementation Continues The implementation process has only begun. "In an economic environment where CSPs are under increasing pressure to decrease operating costs and leverage existing software investments, standards initiatives such as OSS through Java are a means to help CSPs achieve these end goals", says Sharon Ballard, Analyst, The Yankee Group. Nokia, a leading OSS vendor, has announced plans for adopting the OSS/J APIs into a forthcoming release of the Nokia NetAct OSS, a future-proof, scalable framework for operating an entire managed network. JSR 142 OSS Inventory API led by Vassil Rachkov of MetaSolv is in Public Review, and Digital Fairway's eOSS Product Suite is implementing an early adoption version of the specification. Overall, the OSS/J specifications have proven to work well, as borne out by numerous case studies conducted by BEA Systems, BTexact, ILOG, Lumos, Mahindra British Telecom, MetaSolv, Motorola, Oracle, Sonic Software, Sun, and other companies. In some ways, OSS/J API development and implementation work is just starting. The Architecture Board is discussing which JSRs will be developed next to address whether and how to use EJB technology, XML technology and Web Services. According to IDC analyst, Elisabeth Rainge, "As a result of the OSS through Java efforts, OSS and billing architectures are evolving, competitive dynamics in OSS and billing are shifting, and usage of Java technologies in the industry community is showing that this initiative can have a deep and far-reaching effect on the industry".
See Also:
|
