 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 254: OSS Discovery API
The following information has been updated from the original request: 2005.12.16: Specification Lead: Andrew Paterson E-Mail Address: apaterson Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Nakina Systems Name of Contact Person: Sergio Pellizzari E-Mail Address: sergiop@nakinasystems.com Telephone Number: +1 613-254-7351 Fax Number: +1 613-254-7352 Specification Lead: Sergio Pellizzari E-Mail Address: sergiop Telephone Number: +1 613-254-7351 Fax Number: +1 613-254-7352 NOTE that this information has been updated from this original request.Initial Expert Group Membership: Nakina Systems Supporting this JSR: 4DH Consulting Section 2: Request
2.1 Please describe the proposed Specification:The OSS Discovery specification is a part of the OSS through Java Initiative (OSS/J) set of specifications. OSS Discovery shares the core goals of OSS/J: The Discovery APIs are suitable for use by applications that perform discovery of physical network devices and their data. The APIs provide an access point for configuration and management of discovery applications providing the means for the production of discovery files and discovery events related to the discovery job lifecycle. Some examples of areas of concern for the Discovery APIs are discovery seed data, discovery agents, concurrency control, discovered data events, device connection management and policy, and device security credentials. The artefacts produced by these areas of concern are expected to manifest themselves in the form of an OSS Discovery object model that will extend the OSS/J CBE wherever possible (see JSR 144). The object model will also include OSS Discovery events. The existing CBE packages already provide many of the required methods for manipulating objects that extend the CBE. The discovery APIs are useful for creating a single integrated discovery solution across multiple independent systems that are OSS Discovery compliant. They are also useful for building a customized end user application (such as a GUI) on top of one or more OSS Discovery compliant systems. Discovered entities are represented using the OSS/J CBE (Core Business Entities), and so the API is suitable for network resource and service level discovery. Using the CBE classes simplifies data exchange between an OSS Discovery application and other OSS applications. For example, discovered data that is captured using the CBE is readily injected into a compliant OSS Inventory application; the CBE serves as a common ?currency? across the two applications. The primary source for discovered data is physical network equipment. However, the data available on the physical network may not always represent the complete picture for resources and services. For example, complete topology data is not always obtainable without additional data from external data sources. External data sources can be just about anything from databases, to other EMS/NMS systems, to administrator "fat finger" input. OSS Discovery makes no assumption that discovered data shall be persisted directly to a data store. The API provides notifications mechanisms related to discovery job lifecycle events. The API provides mechanisms for the production of discovery files compliant with the import and export schema specification of the Inventory API. As an example, listeners can be business logic components that can access external data sources, and provide any necessary intelligence for merging data from the network and data from external sources. An implementation of the Inventory API is a natural candidate for the application of the discovery results. The specific nature of any business logic components is outside the scope of the Discovery APIs. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Server 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target platform is Java 2 Platform, Enterprise Edition. The OSS Discovery API is developed consistently with JSR 144 and the other APIs developed by the OSS through Java? Initiative (JSR 89,90,91, 130, 142, 210) and works smoothly with them. 2.4 Should this JSR be voted on by both Executive Committees?Since the JSR targets the J2EE platform, the J2EE/SE EC vote alone is appropriate. 2.5 What need of the Java community will be addressed by the proposed specification?A number of software development firms in OSS targeted industries, such as telecommunications, are already using EJB components for their next-generation OSS software. Without some standardization conventions for these components, the industry runs the risk of proliferating similar components with slightly different APIs. Hence, standardizing these component APIs through a Java community process is an attractive proposition. 2.6 Why isn't this need met by existing specifications?Currently, no existing Java platform specification provides a standard API for OSS components. Existing APIs are generally vendor-proprietary. 2.7 Please give a short description of the underlying technology or technologies:The OSS Discovery API will be defined on top of J2EE and other OSS APIs. The most important J2EE APIs for this JCP will be the following:
2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The API will have one or several packages and the prefix for all packages will be "javax.oss". The remaining part of the package name will be defined according to a logical name for different parts of the API. Package names of all OSS JSRs will be coordinated to avoid ambiguous use. 2.9 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.10 Are there any security issues that cannot be addressed by the current security model?None anticipated. 2.11 Are there any internationalization or localization issues?None anticipated. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?This specification might impact the OSS Common API (JSR 144) section Core Business Entities specification and the OSS Inventory API (JSR 142). The synchronization and necessary evolutions will be managed by the OSS through Java Initiative members through the JCP process. 2.13 Please describe the anticipated schedule for the development of this specification.An approximate schedule that depends on the scope of the work and availability of expert members is as follows: 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.Details of the day-to-day working model are TBD soon after formation of an Expert Group. Since OSS/J participation tends to be geographically diverse, ongoing conference calls and a dedicated mailing list are the most likely communication tools for tracking progress. Various EG members will be responsible for delivering the components of the JSR, RI, and TCK. The OSS Discovery project plan is accountable to OSS/J project plan, which is currently primed by the OSS/J Product Team. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Progress updates will be provided on the OSS/J main web site (http://ossj.org/). The OSS/J leads have initiated efforts to provide more information to the public through projects on java.net. OSS Discovery will follow the plans for OSS/J as a whole. OSS Discovery progress will also be updated on the JSR community page on a regular basis. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI and TCK will be delivered as stand alone packages, under the same licensing model and certification model as all other OSS/J APIs. If, by the time of release, a decision is made to include OSS APIs as part of the J2SE/J2EE platform, the RI and TCK might be delivered as part of the J2SE/J2EE platform edition. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Discovery API will be made available to the public under exactly the same terms and conditions as all other OSS/J APIs, which is called the OSS/J Harmonized Licensing and Certification Model. The agreements for the Specifications, the Reference Implementations and the TCKs can be viewed by downloading any OSS/J API. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.? OSS/J API Roadmap - http://ossj.org 3.2 Explanation of how these items might be used as a starting point for the work.The OSS/J API roadmap provides broad directional guideline that describes the intended direction for OSS service and resource discovery. The OSS/J Core Business Entities (CBE)describe the foundation for a data model that ties together all OSS/J work, based on the NGOSS SID The OSS Discovery API is closely related to the OSS Inventory API because discovered entities typically serve as input data to the Inventory system. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.N/A |
