|eclipse web tools
This project proposal is in the Proposal Phase and is posted here to solicit additional project participation and ways the project can be leveraged from the Eclipse membership-at-large. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.webtools newsgroup or the wtp-proposal mailing list.
IntroductionThe eclipse Web Tools Platform Project aims to extend the eclipse tool integration platform with plug-ins that support the J2EE programming model. The Web Tools Platform Project is targetted at both application developers who want to create J2EE applications and to tool developers who want to create J2EE development tools. IBM strongly supports this project and plans to contribute for consideration many plug-ins that have been developed for the WebSphere Studio product family, and to adopt plug-ins from this project as the basis for future IBM development tools. This document gives a high level overview of the initial set of plug-ins that IBM plans to contribute, and highlights opportunities for their further development and extension by other contributors and adoptors.
Server ToolsJ2EE applications run on Application Servers which provide a considerably more complex execution environment than a Java Virtual Machine. IBM will contribute its Server Tools which make servers first class objects in the development enviroment. The Server Tools provide a framework for application developers to create instances of servers, to associate them with projects, to publish content to them, to start, restart, and stop them, and to debug and profile them. Servers can be set up with respect to the development environment in several modes. In Unit Test mode, the server directly accesses the content in the workspace, allowing changes to resources to be immediately reflected in the running application. In Local mode, the workspace content must be published to a server that resides on the same machine as the development environment. In Remote mode, the workspace content must be transmitted over the network to a server that resides on another machine.
The Server Tools include a wizard for creating new server instances, and a view for the management of the servers. In addition to the framework, adapters for the Apache Tomcat servlet engine and a TCP/IP monitoring server will be contributed. A Web browser plug-in will be contributed to facilitate running Web applications.
IBM will contribute an Internet Preferences plug-in which allows the user to configure HTTP proxy servers so that the eclipse JVM process can open HTTP connections through proxy servers.
Figure 1. Server Tools
Figure 1. shows the Server tools. The editor contains the imbedded Web browser with a JSP document, index.jsp, being displayed. The user has just selected index.jsp and executed the "Run on Server" command. The bottom view is the Servers view. Here two servers, a Tomcat v4.1 servlet engine and a WebSphere v5.1 application server are configured. The Tomcat server has been associated as the default server for the test2 Web project.
ExtensionsThe Server Tools are a focal point for extension by server vendors. To integrate into the Server Tools framework, a vendor must provide an adaptor that implements extension points for creating, configuring, and managing their server. We expect that Open Source application server vendors will contribute adaptors for their servers. Possible contributors include ObjectWeb, Apache Geronimo, and JBoss. Commercial vendors, such as IBM and BEA will probably make adaptors freely available, although possibly not as Open Source due to potential exposure of internal interfaces. In the future, APIs for managing J2EE servers will become increasingly standardized, via the Java Management Extension (JMX). Using JMX, e.g. for adding and removing J2EE modules, is an opportunity for further development of the Server Tools.
J2EE Projects, Wizards, Models, Editors, and ValidatorsThe J2EE programmming model includes several types of module (Web, EJB, Client, Resource Adaptor, etc.) and the notion of an Enterprise Application which combines a set of related modules. These modules have specified structures (e.g directory layouts and archive formats: .war, .ejb-jar, .rar, .ear, etc.) and deployment descriptors (web.xml, application.xml, etc.). IBM will contribute Natures for the standard J2EE projects, wizards for creating them, and builders for building them.
IBM will contribute simple wizards for creating standard servlets and JSPs. IBM will provide wizards for creating Stateless and Stateful Session EJBs and Bean Managed Persistence (BMP) and Container Managed Persistence (CMP) Entity EJBs. However, the CMP support will be very basic since CMP is in general very vendor specific.
IBM will contribute a J2EE perspective and a J2EE hierachy view that displays the structure of J2EE modules.
IBM will contribute Eclipse Modelling Framework (EMF) based models for all the standard J2EE deployment descriptors (web.xml, application.xml, etc.). These models will simplify the creation of advanced tools and editors.
The J2EE deployment descriptors are XML documents that are described by either DTD (J2EE 1.3 and previous versions) or XSD (J2EE 1.4). IBM will contribute an XML source editor for modifying these documents. The XML source editor provides programmer assistance based on the DTD or XSD grammar of the document.
The content of a J2EE deployment descriptor can be XML validated with respect to its associated DTD or XSD grammar. However, there are many other semantic constraints that must be satisfied within a deployment descriptor and there are additional semantic constraints that must be satisfied among a set of deployment descriptors and the resources of projects. For example, a Web deployment descriptor (web.xml) may define servlets and refer to Java classes that implement the servlet. Clearly these referenced servlet classes must exist on the classpath of the Web module and must implement the appropriate Servlet interface. If any of these constraints are violated then the application may fail to start or may throw an exception at runtime. Resolving these problems often requires skill and may be very time consuming. IBM will therefore contribute a set of validators for the J2EE projects and resources. Validation failures will be flagged with source code markers and be displayed in the Tasks view as usual.
IBM will contribute a validator framework that allows validators to be registered and managed. Users will be able to control which validators are applied to each project.
There is an important relation between the J2EE projects and the servers. The J2EE modules defined by the projects may be added to the configuration of the servers. A project may have a default server associated with it. Then when a project resource is selected, a "Run on server" command lets the user execute the selected resource (e.g. an HTML page, a JSP or a servlet). For example, a developer could create an instance of a Tomcat servlet engine and assocate it with a Web project. The developer could then create a JSP resource in the Web project, select it, and run it on the server. This action would start the server, if necessary, and launch a Web browser with a URL that was correctly contructed from the JSP resource name and the server configuration (e.g. using the correct port). IBM will contribute actions for running Web resources on servers.
Figure 2. Web Deployment Descriptor XML Source Editor
Figure 2. Shows the Web Deployment Descriptor XML Source Editor. The source editor provides syntax colouring and code assistance based on the DTD for web.xml.
ExtensionsThere is much scope for advanced wizards that create one or more related projects and resources that implement specific application models, e.g. commerce sites, auctions, human resources, etc. Application server developers may create extensions to the deployment descriptors for storing proprietary information. The standard EMF models of the deployment descriptors can be extended to model the additional proprietary information.
There is much scope for the development of advanced deployment descriptor editors. The XML source editors can be used as panes of multipane editors.
There is much scope for improving the completeness of the validators and for providing programmer assistance such as help and tips for correcting problems.
There is scope for exploiting XDoclet to simplify the deployment of EJBs and Web services. XDoclet support should include extensions to the Java source editor to provide code assist for XDoclet tags.
There is scope for the contribution of advanced CMP Entity EJB tools.
Vendors who wish to integrate JSP compilers should support JSR 45 for debugging JSP at the source level. In general JSR 45 should be used for debugging non-Java source, for example SQLJ, that is compiled directly or indirectly into Java bytecodes.
IBM will contribute a Content Type Identifier framework to the base eclipse platform so that editors can be selected based on content instead of file extension, e.g. a file may contain JSP without having the file extension .jsp.
IBM will contribute a Snippets view that allows a library of code snippets to be created and then dragged and dropped into the source file being edited.
IBM will contribute simple creation wizards for the supported source formats.
IBM will contribute validators for the supported formats.
Figure 3. HTML/JSP Source Editor
Figure 3 shows the HTML/JSP source editor open on index.jsp. The editor is supported by outline, palette, attribute, and snippet views.
ExtensionsThe SSE can be extended to other source formats that admit a DOM like representation. The Content Type Identifier framework can be extended to recognize other formats.
The SSE can be incorporated into other advanced editors, e.g. a WYSIWYG HTML/JSP editor.
Extended snippet libraries can be created for each supported format.
Advanced wizards can be developed to create resources with application specific content, e.g HTML forms, Logon pages, etc.
XML Wizards, Editors, and ValidatorsXML is a key format for Web development. J2EE deployment descriptors are XML documents. Web pages can be created using XHTML. XSD grammars define the content of XML documents. XSLT is used for transforming XML and generating HTML.XML plays a central role in Web services standards, e.g. SOAP, WSDL. IBM will contribute an EMF model for DTD and a basic DTD source editor that supports an outline view. .
IBM will contribute an advanced editor for XSD. The XSD editor has a graphical pane that shows the relationships between the components of the XSD document.
IBM will contribute simple creation wizards for XML, DTD, and XSD.
IBM will contribute validatiors for XML, DTD and XSD.
IBM will contribute a XML instance document content model that is based on either a DTD or an XSD grammar.
IBM will contribute code generators that generate an XML instance document from a DTD or XSD grammar, an XSD grammar from an XML instance document, and an XSD grammar from a DTD grammar.
Figure 4. XSD Graphical Editor
Figure 4 shows the XSD graphical editor. The graphical pane allows users to create XSD documents without having to understand XSD syntax.
ExtensionsThere is scope for creating an advanced WYSIWYG XSLT editor, and other XSLT tools such as a debugger. There is scope for adding support for popular Open Source XML technologies such as FOP and Cocoon.
Web Services ToolsWeb services are the latest major addition to J2EE (e.g. JSR 101, JSR 109). IBM will contribute a set of Web services tools that cover the full development life cycle including Discovery, Access, Creation, Deployment, Testing, and Publication. The main Web services standards supported include Simple Object Access Protocol (SOAP) 1.1, Web Services Description Language (WSDL) 1.1, Universal Description, Discovery, and Integraion (UDDI) 1.0 and 2.0, Web Services Inspection Language (WSIL) 1.0, and Web Services Interoperability Organization (WS-I) Basic Profile (WS-I BP) 1.0. IBM will contribute a task oriented Web service wizard that ties together all the life cycle steps. The Wizard is extensible and allows the integration of different tools and runtimes at each step. Wizard steps are also invocable via pop-up actions. The life cycle steps include discovery of Web services from UDDI or WSIL, creation of Web services from Java or via WSDL based server skeleton generation, deployment of Web services to an application server, accessing Web services via WSDL based client proxy generation, testing of Web services via dynamic interprettation of WSDL or via test client generation, and publication of Web services to UDDI or WSIL.
IBM will contribute the adaptors for the Apache Axis Web Service runtime to integrate it with the Web service wizard. These adaptors allow the Axis runtime to be configured into a Web project, and for the code generators which convert Java to WSDL and WSDL to Java to be invoked. The WSDL to Java generator creates both server skeletons and client proxies.
IBM will contribute a Web service Explorer and a WSDL Explorer. These are Web applications that run on the servlet engine integrated into eclipse. The Web service Explorer supports Discovery and Publication of Web services to UDDI 1.0 and 2.0 registries and from WSIL documents. The Web service Explorer allows WSDL documents to be imported and exported from the eclipse workspace to UDDI registries. The WSDL Explorer allows Web services to be tested dynamically, based on their WSDL documents, and for the SOAP messages to be viewed.
IBM will contribute a WSDL documentation generator which creates HTML from WSDL in a manner similar to the way Javadoc generates HTML from Java source code.
IBM will contribute a WSDL editor which includes a source pane and a graphical pane. The graphical pane is integrated with the XSD editor. IBM will contribute an EMF model, a creation wizard and a validator for WSDL documents.
IBM will contribute a test client generator. This plug-in generates a sample JSP test client that can be used to unit test a Web service.
IBM has already contributed WS-I testing tools in the eclipse Web Services Validation Tools project. The WS-I testing tools include static validation of WSDL based on the WS-I BP 1.0, and an extension to the TCP/IP monitor that writes SOAP message traffic to a standard log file format and a validator for the SOAP messages captured in the log file based on BP 1.0.
Figure 5. WSDL Graphical Editor
Figure 5. shows the WSDL editor open and a simple WSDL file, Hello.wsdl. In this example, the WSDL was generated from a Java class and the WSDL editor is being used to visualize it. However, the graphical view also supports creation and modification of WSDL without requiring a knowledge of WSDL syntax.
ExtensionsWSDL is a central format for Web services tools and is itself extensible. All of the WSDL tools, including the editor, documentation generator, and validator either have extension points for WSDL extensions, or should be modified to include such extension points. Extensions can then be developed for additional WSDL binding extensions such as SOAP over JMS. The WS-I tools are extensible with respect to new profiles which should be supported as they as defined by WS-I.org. Future WS-I profiles include support for SOAP Attachements and Security.
The SOAP message montior and validator contains many possibilities for extension, including the ability to replay a log file, with or without modification, the ability to set breakpoints on messages or conditions, and the ability to display SOAP messages in more readable forms, especially those that contain WS-Security headers which include base-64 encoded digital certificates or encrypted content.
The subject area of Web services is currently under rapid evolution and there are many new specifications being proposed. The basis specifications are being upgraded (e.g. SOAP 1.2, WSDL 2.0, and UDDI 3.0). The large number of new specifications provides a fertile ground for new tools.
The Web services wizard is extensible with respect to runtimes and this is an opportunity for Web service runtime vendors to provide adaptors for their runtimes to extend the wizard.
There is an opportunity to integrate local UDDI registries into the Web services tools to give developers an easy way to unit test UDDI Discovery and Publication operations.
Database Access ToolsMost Web applications will involve accessing a database. For example, Java components such as servlets and EJBs may make JDBC calls. There are JSP tag libraries that simplify database access. There is also an extension to Java syntax, SQLJ, that allows embedded SQL statements. IBM will contribute a wizard for generating an SQL statement and an editor and validator for modifying SQL statements. The SQL statements will be stored in a simple source format known as .sqx which contains the native SQL source wrapped in XML. The XML wrapper contains additional information about the database. The editor contains a source pane and a visual editing pane. A view is provided to display the tables available in the database and the editor supports drag and drop of these tables into the statement being edited. A developer can create an SQL statement and then copy and paste it into any other source format that allows SQL strings, e.g. Java JDBC calls, JSP tags, SQLJ source. The SQL wizard and editor work on a live connection to a database via a JDBC driver and support the test execution of SQL SELECT, INSERT, DELETE, and UPDATE statements.
IBM will contribute an SQL EMF model that can be used by other tools.
Figure 6. SQL Statement Editor
Figure 6 shows the visual SQL editor which allows users to create SQL statements without having to understand SQL syntax. The user can drag and drop tables into the statement. The editor can also execute the statement to give the user immediate feedback.The SQL statements can be copied and pasted from the source pane into other source files.
ExtensionsThe SQL model allows for extension with respect to vendor specific SQL datatypes. The SQL editor can be reused in source editors that support inline SQL strings. There is scope for improving the quality of source code assistance provided by the SQL source editor.
There is scope for expanding the database tools to include database design functions.
Milestone PlanIBM plans to contribute the plug-ins described above as a sequence of milestones. Each milestone provides a set of functions that can be used by developers for application development. The high level description of these milestones follows. The milestone schedule is beyond the scope of this document. The content of the milestones described below is our best estimate at the current time and may vary slightly as we execute this plan. Milestone 1 provides the ability to create, deploy and debug servlet based Web applications in Tomcat. This milestone includes the Server tools and supports the ability to add new application servers, create Web projects, create servlets, and run servlets in normal or debug mode. The output of the servlet can be displayed in an imbedded Web browser and the HTTP traffic and be viewed using the TCP/IP montior. Milestone 2 adds JSP support. This milestone includes the HTML/JSP source editor, snippets view, and JSP creation wizard. Developers can debug JSP source and step into the Java source of classes invoked by the JSP. The Structured Source Editor will be included in this milestone to support editing of HTML, CSS, XSD, JSP, etc. Elements of the Web services tools such as the Web Service and WSDL Explorers will be included. Milestone 3 adds most of the remaining Web services tools. Servlet container based Web services in Axis are supported. The XSD and WSDL editors and associated WSDL and UDDI tools are included. The WS-I test tools are integrated with the WSDL validator and TCP/IP monitor. Milestone 4 adds the EJB and database access tools. EJB and Enterprise Application modules are supported. Users can create, deploy, and debug Session and Entity EJBs. Session EJB based Web services are now supported.
SummaryIBM will contribute for consideration a complete set of basic J2EE and Web tools to the eclipse Web Tools Platform project. The contributed tools are the results of extensive development effort over several years within the context of the IBM WebSphere Studio product family. These tools are immediately useful in themselves and also provide a framework that runtime vendors and tools developers can extend. However, the contributed code is only intended to be a starting point for the definition of APIs and tools that will form the basis of future development.
The IBM contributions described here will make a significant addition to the completeness and appeal of the eclipse platform and will help build a thriving J2EE developer community around eclipse.