Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 91: OSS Trouble Ticket API

Stage Access Start Finish
Maintenance Release 2 Download page 21 Aug, 2007  
Maintenance Draft Review 3 Download page 08 Jun, 2007 09 Jul, 2007
Maintenance Release Download page 20 Feb, 2007  
Maintenance Draft Review 2 Download page 10 Nov, 2006 18 Dec, 2006
Maintenance Draft Review Download page 07 Dec, 2005 09 Jan, 2006
Final Release Download page 19 Feb, 2002  
Final Approval Ballot View results 29 Jan, 2002 11 Feb, 2002
Proposed Final Draft Download page 21 Nov, 2001  
Public Review Download page 03 May, 2001 01 Jul, 2001
Community Draft Ballot View results 10 Apr, 2001 16 Apr, 2001
Community Review Login page 09 Mar, 2001 16 Apr, 2001
Expert Group Formation   24 Oct, 2000 14 Dec, 2000
JSR Review Ballot View results 10 Oct, 2000 23 Oct, 2000
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

The OSS Trouble Ticket API will provide interfaces for creating, querying, updating, and deleting trouble tickets (trouble reports).

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Roman Schlegel Frox Communication
Expert Group
  Digital Fairway Corporation Ericsson Inc. Frox Communication
  Johnson, Cedrick W. Motorola NEC Corporation
  Nokia Corporation Nortel Siemens AG
  Sun Microsystems, Inc. Telcordia Technologies, Inc.

Note that this JSR was completed under JCP 2.1.

Updates to the Original JSR

The following information has been updated from the original request.


The Maintenance Lead role changed to Frox Communication and the JCP version changed to 2.6.

Maintenance Lead: Michael Nidel

E-Mail Address:

Telephone Number: +41 55 254 1239

Fax Number: +41 55 254 1264


Maintenance Lead: Axel Terfloth

E-Mail Address:

Telephone Number: +49 231 47642 201

Fax Number: +49 231 47642 554

2005.02.25: The Maintenance Lead role changed from MetaSolv to IPValue.

Maintenance Lead: Thomas Schmal

E-Mail Address:

Telephone Number: +49 231 47642 0

Fax Number: +49 231 47642 554

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Nortel Networks

Name of Contact Person: Pierre Gauthier

E-Mail Address:

Telephone Number: +1 613 763 2281

Fax Number: +1 613 765 7387

Specification Lead: Pierre Gauthier

E-Mail Address:

Telephone Number: +1 613 763 2281

Fax Number: +1 613 765 7387

NOTE that this information has been updated from this original request.

(Please provide company or organization names. Note that co-submitters must have signed the JSPA.)

Co-submitting Company: Clarify

Expert Group Member: Diwakar Magadi

E-Mail Address:

Telephone Number: +1 408 965 7336

Fax Number: +1 408 965 4632

Co-submitting Company: Ericsson

Expert Group Member: Lar Tenfalt

E-Mail Address:

Telephone Number: +46 31 747 1974

Fax Number: +46 31 747 2942

Co-submitting Company: Motorola

Expert Group Member: Frank Korinek

E-Mail Address:

Telephone Number: +1 847 576 1643

Fax Number: +1 847 538 5564

Co-submitting Company: NEC Corporation

Expert Group Member:Hiroya Kawata

E-Mail Address:

Telephone Number: +81 45 939 2450

Fax Number: +81 45 939 2487

Co-submitting Company: Nokia Networks

Expert Group Member:Stefan Vaillant

E-Mail Address:

Telephone Number: +49 211 9412-3973

Fax Number: +49 211 9412-3988

Co-submitting Company: Remedy Corporation

Expert Group Member: Mark Buckallew

E-Mail Address:

Telephone Number: +1 650 254 4943

Fax Number: +1 650 903 9001

Co-submitting Company: Sun Microsystems

Expert Group Member: Philippe Goujard

E-Mail Address:

Telephone Number: +44 1276 689 414

Fax Number: +44 1276 677 121

Co-submitting Company: Telcordia Technologies

Expert Group Member: Balakrishnan Dasarathy

E-Mail Address:

Telephone Number: +1 973 829 5038

Fax Number: +1 973 829 2645

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

Nortel Networks
Cisco Systems
NEC Corporation
Nokia Networks
Remedy Corporation
Sun Microsystems
Telcordia Technologies

Section 2: Request

2.1 Please describe the proposed Specification:

Fault tracking and resolution is a time-consuming activity and one of the most useful tools available to network and service managers is that of a trouble ticket system. Trouble tickets are essentially fault reports that are administered as documents. These documents are active from the time a fault is reported, during its diagnosis, and until its eventual correction. They are then generally archived to provide statistical information.

A trouble ticket contains not only information about the related fault but also represents the on-going activity related to the correction of the fault. Hence a trouble ticket contains not only information about the fault (such as a description of the problem, probable cause, and time of reporting) but also status of any corrective action initiated and the current owner of the problem. Trouble tickets may be generated by telecommunications management components or through customer relationship management systems.

A number of trouble ticket systems is available in the marketplace but each is accessed by a different set of APIs necessitating custom integration into an OSS. The goal of this JSR is to define a standardized API, based on J2EE, that will permit rapid deployment of commercial trouble ticket systems.

The Trouble Ticket API will meet the following functional requirements:

  • allowing clients to create, remove, or cancel trouble tickets;
  • allowing clients to change the values of trouble ticket parameters; and
  • allowing clients to be informed of changes to trouble tickets via a notification mechanism.
The Trouble Ticket API specification will address the following aspects:
  • the specification of the Enterprise Java Beans exporting interfaces to the trouble ticket system;
  • the specification of the mechanism to locate the interfaces;
  • the specification of the XML-based messages that may be sent to, and received from, a trouble ticket system;
  • the specification of the strongly-typed object-based events and XML-based events emitted by a trouble ticket system; and
  • the specification of an event subscription mechanism.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Platform, Enterprise Edition

2.3 What need of the Java community will be addressed by the proposed specification?

There is a growing trend within telecommunications industry towards the use of J2EE for development of various aspects Operations Support Systems (OSSs). Without some form of standardization, there is a a risk of divergent specifications proliferating throughout the industry.

2.4 Why isn't this need met by existing specifications?

There are no existing open Java API specifications for trouble ticket systems; existing API are vendor-specific.

2.5 Please give a short description of the underlying technology or technologies:

he APIs will be defined on top of J2EE. The most important J2EE APIs for this JCP will be the following:

  • EJB (Enterprise JavaBeans):
    To facilitate the integration of OSS components, the expert group will define standard EJB interfaces.
  • JMS (Java Message Service):
    Besides the ability to execute synchronous (EJB) methods calls, there is also a need to send asynchronous messages. For this, JMS will be used.
  • JNDI (Java Naming and Directory Interface):
    The specification will include standards for JNDI names.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The prefix "javax.oss" will be used in all OSS JSRs, including those recently submitted, namely: "OSS Quality of Service API" and "OSS Service Activation API". Package names of all OSS JSRs will be co-ordinated to avoid ambiguous use.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

The specification has no dependency on operating systems, CPUs, or I/O devices.

2.8 Are there any security issues that cannot be addressed by the current security model?

None is anticipated

2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

  • Publication of Community Draft: February 2001
  • Publication of Public Draft: March 2001
  • Publication of Final Specificaion: June 2001