There are a lot of future features that we would like to implement in GT4IDE and globus-build-service. Some of them we will do ourselves, while others will probably linger in our wishlist forever. If you want to help out, or want to propose another feature for the wishlist, please contact Borja Sotomayor at borja AT cs DOT uchicago DOT edu

Besides this list of features for our existing tools, we have also brainstormed some (completely new) cool tools that could be developed for the GSBT project. If you want to start the ball rolling on any of these tools, please contact Borja.

GT4IDE Wishlist

Small Wishes

• Add more design patterns
• Add more implementation skeletons
• Use a known templating engine to generate code: The current ad-hoc templating system meets our requirements, but as more design patterns and implementation skeletons are added to the plugin, a more powerful templating engine might be necessary. Apache Velocity (http://jakarta.apache.org/velocity/) might be a good option.
• Allow users to specify more properties when creating a service: The first release allows users to define only very simple services from the Eclipse IDE. More complex scenarios require the user to get his hands dirty and edit the WSDL code directly. The plugin should provide greater flexibility by allowing these complex scenarios to be handled completely from the IDE's GUI. For example, by allowing the user to specify what standard WSRF PortTypes the service will implement.
• Provide “client” functionality: Although the user can manually add classes to the project and implement client applications, the plugin could easily generate boilerplate code for a service's client.
• Run the Globus container within Eclipse: If the previous item is implemented, it would make sense to integrate the Globus container into the plugin, so it can be run in an Eclipse console, without having the user switch between Eclipse and a shell window.
• Integration with GT4 Javadocs: Eclipse provides context hints in its editor. These context hints use Javadocs (when available) to show the user a description of a class, method, etc. Integration with the GT4 Javadocs is desirable.

Big Wishes

• Remote debugging of services: Debugging GT4 services is a cumbersome task, generally involving deciphering huge stack traces and following the execution of a service by making the service print log messages at certain points. Debugging from an IDE, allowing interactive inspection of variable values and step-by-step execution, would make debugging GT4 services much easier. Adding this functionality should be relatively simple (although not trivial) since Eclipse already allows Web Services programmers to debug remote Web Services deployed on a Tomcat server (an additional plugin is required for this).
• Specifying service data (Resource Properties) using a GUI: Generating WSDL code for service operations  is straightforward since we can establish a mapping between the WSDL-defined operations and their implementation in the Java code. Resource Properties, however, currently require that the programmer manually edit the WSDL file. The plugin should provide in the future a GUI to specify Resource Properties. The Eclipse Modeling Framework (http://download.eclipse.org/tools/emf/scripts/home.php) might come in handy to do this.
• Collaborative development: Eclipse already includes excellent support for collaborative development, including easy integration with CVS. However, support could be added for requirements that are only found in Grid projects (e.g. automatic service deployment in multiple remote servers, compatibility with collaborative tools besides CVS, etc.)
• Eclipse Web Tools: The GT4IDE plugin stands to benefit greatly from the Eclipse Web Tools project which, among other things, provides XML editors and graphical XML Schema and WSDL editors. More details about this project can be found here: http://www.eclipse.org/webtools/

globus-service-build

Other interesting tools

• Tool that reads an annotated Java 5 class (the implementation of a service) and generates the WSDL code (including resource property definitions, derived from annotations), the WSDD and JNDI code (derived from annotations), and the namespace mappings file.
• Easy to use, general purpose service debugging GUI. In other words, a GUI that can dynamically generate a user-friendly graphical interface for any WSRF service, and allows the user to tinker with the service. Easily showing debugging information (both client-side and server-side) would be a big plus. This would be a sort of globus-browse-service on steroids.
• GAR validator: a tool that performs some basic sanity checks on a GAR file, to capture errors that would normally arise in run-time. For example, a basic check would be to see if the GAR meets the expected GAR directory structure. A more advanced check would be to see that the Java classes referenced from the WSDD and JNDI deploy files are included in the GAR file.