JSR 91: OSS Trouble Ticket API

Name of Contact Person: Pierre Gauthier

E-Mail Address: yaic@nortelnetworks.com

Telephone Number: +1 613 763 2281

Fax Number: +1 613 765 7387

Specification Lead: Pierre Gauthier

E-Mail Address: yaic@nortelnetworks.com

Telephone Number: +1 613 763 2281

Fax Number: +1 613 765 7387

Co-submitters:
(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: dmagadi@nortelnetworks.com

Telephone Number: +1 408 965 7336

Fax Number: +1 408 965 4632

Co-submitting Company: Ericsson

Expert Group Member: Lar Tenfalt

E-Mail Address: Lars.Tenfalt@emw.ericsson.se

Telephone Number: +46 31 747 1974

Fax Number: +46 31 747 2942

Co-submitting Company: Motorola

Expert Group Member: Frank Korinek

E-Mail Address: frank.korinek@motorola.com

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: h-kawata@bq.jp.nec.com

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: Stefan.Vaillant@nokia.com

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: mab@remedy.com

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: philippe.goujard@uk.sun.com

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: bdasarat@telcordia.com

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
Clarify
Ericsson
Motorola
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 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?

No.

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

No.

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