Introduction This document describes a module for the NetBeans IDE, which will provide support for developers to develop SIP applications and deploy them onto an application server based on the SailFin project code-base. NetBeans is a project focused IDE for Java and other languages, built on the NetBeans Platform. Many of the IDE features are accessible from the Project "Explorer" A NetBeans module extends the functionality of an application built upon the NetBeans platform. A module may depend on other modules. A SIP Application is a collection of SIP Servlets and Listeners (which are APIs defined in JSR289) Java classes packaged as an archive that are deployed onto a SIP Servlet Container (also defined in JSR289). The SailFin project extends the application server based on the GlassFish project code-base with a JSR289 SIP Servlet Container. Features Project NetBeans users interact with a couple of objects while doing development of "deployed" applications. Their primary focus is their project. A project organizes the code and processes associated with a single archive around a simple set of concepts. A project organizes the "code" of the project and the processes associated with development into a single user visible object. Since a SIP Application is an archive, it make sense for the module to allow users to create a new project. A NetBeans project is a structured collection of files. The files persist the "code" that a user is developing along with the metadata that the IDE uses to create the archive associated with the project and that archives relationship with other archives (and the contain that will host its execution, in the case of a SIP Application). The IDE uses a wizard to lead the user through the process of associating some location on their disk with the project that they are creating. new project The IDE needs to collect the following data to create a new project: The name of the project. The location that will be used to store the project's metadata (from the users perspective). In the case of projects for archives that are associated with a container, an instance of the container is usually associated with the project when it is create. After the required data is entered, the IDE will write the files necessary to create a SIP Application project to disk. Since many projects are already in existence (based on an earlier specification JSR116) there needs to be some way to associate a project with existing java code, etc. One of the first operations that users will need to do after creating a project is to create new code that will become part of the project's archive. In NetBeans this is usually done with the New item that is associated with the project (in its contextual or right-click menu). The item allows the user to access a select number of likely artifacts that the user would want to create. This "likely artifact menu" (refered to as the PrivilegedTemplates) needs to have entries for a SipServlet and a SipListener. The Other menu items on the Project's right-click menu would include items similar to those found on a Web App Project. All of these items would behave as if the project was a regular web app project. One exception would be the Run item, which will NOT trigger the browser by default. The correct behavior for this item would be to open some Ui that would allow the user to generate SIP protocol messages and receive the responses. It will be possible to add this project to an Enterprise Application project as a submodule. Web Framework The SIP Application development module will continue register a web-app framework that supports the creation of projects that contain SIP functionality. This framework will be "pre-registered" in the projects created by the aforementioned New Project wizard. The framework will be removable from web-apps that have been extended with this framework. It can also be removed from projects created by the aforementioned wizard. Removing the framework from a project will not remove code that the user has written that depends on the presence of the framework. Most of the time removing the SIP framework from a SIP application is probably a user error. The presence of this framework allows the user to recover from such an error. New File Templates there are three files that a SIP application developer is likely to need to create.
- SipServlet
The Wizard should ask for the name that the user want the SipServlet to have. It should also ask for the package where the servlet belongs. The wizard should also allow the user to specify which methods to implement. After the user finishes the wizard, the java source is written into the project source tree at the appropriate location in the package structure. Ideally, the project should be deployable at this point... even though that won't make much sense, since the "business logic" hasn't been added to the servlet yet. This implies that the wizard must be able to prevent the user from creating a servlet that implements a SIP method that is already implemented by another servlet in the project. The code written by the wizard will use JSR289 annotation. If there are elements that must be added to the sip.xml to support the immediate deployability requirement, they should be added to the file. If the sip.xml file doesn't exist, it should be created also.
- Sip Listener Implementation
the wizard will ask for the name and package of the Listener. the wizard will present a list of interfaces that listener will implement. after the user finishes the wizard the java source will be written. The project should be deployable at this point. The wizard will need to prevent the user from creating "duplicate" listeners (if there is cases where such a restriction applies). the code written by the wizard will use JSR289 annotation. If elements must be added to the sip.xml to support "immediate deployability" they will be added as the wizard finishes. if the sip.xml file doesn't exist when these elements are required, it will also be created by the wizard.
- sip.xml
This wizard will create an empty sip.xml file with the proper namespace declaration and required elements to be immediately deployable. The sip.xml would be written to the web/WEB-INF directory.
A developer targeting Sailfin will probably need to be able to create a sun-sip.xml file. This would also be supported by a wizard. The wizard would create the file in the correct location. the project would be immediately deployable aftger running through the wizard. This implies that all required elements would be populated by the wizard. Java code editing The java editor will support code completion for JSR289 annotations. The development module will integrate editor hints and error detection for SIP Application semantics. the number of hints and errors detected will be based on the time available to implement them. XML editing The xml editor will support code completion for the sip.xml and sun-sip.xml file. This support will apply to sip-app_1_0.dtd based instances and sip-app_1_1.xsd based instances of the sip.xml file. Design Overview Creating a new project type, based on the Web App Project code base, is costly over the long term. Much of the code for such a project would be copy/pasted from the current web project. As the web project was fixed, a project created by copying the code would also need to be evaluated and fixed. Applying the SIP functionality as a web framework over a web app project is straight-forward, but lowers the visibility of the functionality considerably. Another implementation strategy would be to create a project wizard which creates a web app that has been preconfigured with the SIP framework. This raises the visibility of the SIP features. The wizard for this new project "type" would collect data that would be used to replace tokens in a pre-configured skeleton web-app project. The skeleton would be created by unzipping a static prototype. Once the Wizard finished, the standard open hooks for the web app make the project appear in the Project explorer. The actions associated with the node would all come from the web app project. The PrivilegedTemplates list for the resulting project would be extended by using the new Web API, WebPrivilegedTemplates.
Cannot resolve external resource into attachment. the build process also needs to get altered a bit, to try to open the test agent on project Run/Debug/Profile. This would be accomplished with an AntBuildExtender The templates for the new file types will be implemented using the "standard" method. The templates will part of the module. The annotation processing will be accomplished by java editor, pretty much automatically, based on the availability of the api definition. The XML file processing will be accomplished by the xml editor. The sip-app_1_0.dtd and the sip-app_1_1.xsd will be registered with NetBeans to enable these features. Quality and Availability The initial implementation of the module will be available at approximately the same time as the milestone 3 of the Sailfin project's server implementation. There may be a slight delay, since NetBeans 6.0 may not release until after Sailfin's MS3. The module will be "promoted" by the development team and then we will start to implement enhancements to the initial implementation as directed by interested users. The goal is to get a basic level of functionality out to users quickly and improve the plugin iteratively, based on user feedback. The 1.0 release of the plugin will occur about the same time as the Sailfin 1.0 release. There is one person on the team dedicated to testing the module against Sailfin and NetBeans 6.0. Performance There are very few places where performance issues are acceptable in an IDE. The module will provide feedback to indicate when long lived operations are happening. The amount of time taken to create a SIP Application project should not exceed 120% of the amount of time taken to create a "normal" web app project. The amount of time necessary to open a SIP Application project should not exceed 110% of the amount of time required to open a like sized web-app project. Management and Monitoring The module is a NetBeans module and is subject to some management through interfaces associated with that system. the module does not expose additional management interfaces. The module exposes no configurable options or preferences. The module will expose diagnostic information via the JDK's Logger capabilities. Error reporting for the module will also integrate into the IDE's error reporting mechanisms. Formal Interfaces Packaging, Files and Location The plugin will consist of a small number of nbm files. These nbm's will be built and packaged according to the rules of the NetBeans module system. These modules will be part of the enterprise4 cluster. Documentation Requirements The documentation requirements for an IDE module are pretty high. Each page of the wizards will need to have a help button, that will open content relevant to the current page. This content should also link to content that is relevant to the process of developing a SIP Application. this additional content would probably be viewed as a developer's guide or a tutorial of some sort. Any new nodes will need to be described. The javadoc for the new classes and interfaces associated with SIP Application development should be registered with the IDE, to allow editor features to work properly. Open Issues Are there required elements in the sip.xml when the user adds a sip servlet to a jsr289 app? are there required elements when a user adds a listner to their jsr289 app?
|
