Some examples of possible Extensions as defined in the existing OSS/J Specifications

Below are some examples of possible Extensions as defined in the existing OSS/J Specifications. They are presented as Q&A.

1. Why are Quality of Service (JSR90) and Service Activation (JSR89) APIs extensible? Why not Trouble Ticket (JSR91)?

In fact all OSS/J API are extensible, anyone can create a new class that will extend an OSS/J interface. However it is expected that the main extensions will be with SA and QoS because TT information model is fairly fixed whereas SA and QoS are somehow agnostic (SA does not define the information model for a service and QoS does not define the information model for performance data). So it is expected that companies will create their own extensions for a specific technology (DSL, 3G,...) or for a specific vendor.

2. What are the possible extensions for Service Activation (JSR89)?

SA API is designed to allow Extensions that are needed in a real life system, as defined in chapter 5 "Implementing the API" of the Specification. The SA API Specifications define precisely how to extend: . the Service Information Model . the Order to a Business Process . the Event Model

3. What are the possible extensions for Quality of Service API (JSR90)?

Similarly to SA, the QoS API Specification defines in Part 2 chapter 4.4 "Extending Entity Model" what extensions are permnitted.

4. Are there some generic extensions for all OSS/J APIs?

The OSS/J Common Design Guidelines contains clear example and recommendation on how to extend the OSS/J APIs.

• On Java Value Type objects Developers and Users may provide an extension to a standard value interface and provide their own value interface. For example, vendor "XYZCorp" may provide an extension to the javax.oss.trouble.TroubleTicketValue called "com.xyzcorp.XYZTroubleTicketValue". The fully qualified name of the interface should be returned: "com.xyzcorp.XYZTroubleTicketValue"?
• On Events Developers and Users may provide an extension to a standard event interface and provide their own event interface. For example vendor "XYZCorp" may provide an extension to the "javax.oss.trouble.TroubleTicketCancellationEvent" called "com.xyzcorp.XYZ TroubleTicketCancellationEvent". The fully qualified name of the most derived interface should be returned i.e "com.xyzcorp.XYZ TroubleTicketCancellationEvent"

If a vendor provides an extension of an Event interface as defined in the API then the getEventTypes() must return both the fully qualified name of the interface as defined in the API and the fully qualified name of the extended type. For example both the javax."oss.trouble.TroubleTicketCancellationEvent" and the "com.xyzcorp.XYZTroubleTicketCancellationEvent" names must be returned.

• Other extensions The OSS/J Design Guidelines also contains rules/recommendations for using query mechanisms with API extensions and how to extend the XML schemas associated with the Java classes.