Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 61: Phonelets API Specification

Stage Access Start Finish
Withdrawn   09 Apr, 2004  
CAFE   11 Mar, 2000 17 Apr, 2000
JSR Approval   04 Mar, 2000 10 Mar, 2000
Status: Withdrawn
Reason: Withdrawn at the request of the Spec Lead after 4 years with no Expert Group.
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0


Description:
Phonelets provide developers with a simple API to package, deploy and run Computer Telephony Integration (CTI) applications in a resource and security controlled environment.

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

Specification Leads
  Marc Petit-Huguenin 8x8
Expert Group
  8x8    

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Spec Lead after 4 years with no Expert Group.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: 8x8 - Network Software Division

Name of Contact Person: Marc Petit-Huguenin

E-Mail Address: petithug@8x8.com

Telephone Number: +33 492 946 830

Fax Number: +33 492 946 831



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is to develop the Phonelets Specification. It will describe an API for writing CTI (Computer Telephony Integration) applications called Phonelets and describe the architecture (Phonelets containers) necessary to deploy, manage and run the Phonelet.

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

The Phonelets specification is targeted for the Java[tm] 2 Platform Standard Edition. The specification of Phonelets for small devices (Webphone, PDA...) will be for further study.

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

The Java Telephony developers community needs an architecture which addresses the following requirements:

  • Providing a life-cycle for CTI applications for loading, initializing, running and destroying CTI applications. Optionally, this architecture will permit to save and restore the state of a Phonelet (for persistence, load balancing, load on demand and on-the-fly upgrading of CTI applications).

  • Providing a standard packaging format to bundle Phonelet code, resources, configuration and management templates into a single file named Phonelet Archive (.par). This file can be run on multiple Phonelet containers from multiple vendors.

  • Providing a security framework based on Java[tm] 2 Platform security architecture to grant CTI applications access to sensible resources.

  • Providing a unified and controlled way for CTI applications to access external services, such as JavaSpeech API, or JNDI.

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

The JTAPI specification does not solve the issues of scalability, deployment and distribution of CTI applications.

Phonelets containers are somewhat like EJB containers, but EJB architecture is more centered around notions of remote invocations and data persistence.

The Phonelets design is largely inspired by the servlets design. However the two technologies are very specialized, the former for telephony applications, the later for HTML and content handling.

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

The Phonelets architecture will use JTAPI 1.3 and the upcoming JTAPI 2.0 as the standard way to access to telephony services.

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

javax.phonelet

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

None.

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

None identified at this time.

2.9 Are there any internationalization or localization issues?

Some resources packaged into Phonelets ARchives files will need to be localized.

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

None.



Section 3: Contributions

There are no additional contributions.