by Tim Wagner, Ted Bashor, Paul Meijer and Pieter Humphrey
The Web Tools Platform (WTP) project extends Eclipse into the domain of Web and enterprise (J2EE) application development. This open source project is dedicated to providing a generic, extensible, standards-based tools platform for producing Web-centric technologies. WTP provides a rich set of tools and features for application developers, as well as a vendor-neutral framework for value-add extensions, including a customizable project model and application server support. This article provides an overview of WTP's sub-projects—Web Standard Tools (WST) and J2EE Platform Standard Tools (JST)—and explores the major themes of the 0.7 release:
For more information about WTP and to get started with WTP and Eclipse, go to the Eclipse WTP project Web site.
To get a better understanding of the WTP project, let's take a minute to look at some of the project's principles (you can find the entire list of WTP principles on the WTP project Web site):
Extension of the Eclipse value proposition: The Eclipse Project has set a high standard for technical excellence, functional innovation, and overall extensibility within the Java IDE domain. We intend to apply these same standards to the Web/J2EE application-tooling domain.
Vendor ecosystem: A major goal of this project is to support a vital application development tools market. WTP's exemplary functionality is useful on its own but is designed from the start to be extensible, so commercial vendors can use what this project delivers as a foundation for their own product innovation and development efficiency.
Vendor neutrality: Vendor neutrality is at the core of this project. We aim to encourage Eclipse participation and drive Eclipse market acceptance by strengthening the long-term product value propositions of the widest possible range of application development vendors.
Standards-based innovation: This project delivers an extensible, standards-based tooling foundation on which the widest possible range of vendors can create value-added development products for their customers and end users. Where standards exist, we will adhere to them. Although WTP's focus is on runtime technologies with accepted standards and existing deployments, it also tracks emerging standards where leading-edge tools are desirable. Where multiple technologies are widely used for a given functional need, we will attempt to support each, subject only to technical feasibility and our goal of providing the most capable and extensible foundation for the long term.
These principles together endorse the view that WTP aims to extend the core tools and functionality of Eclipse to J2EE and Web applications, enabling J2EE vendors to build on top of WTP's base functionality by ensuring that WTP implements approved standards in the J2EE and Web application sphere.
Figure 1 illustrates the major components of WTP. With respect to runtime components, WTP 0.7 supports JSP-based Web applications, Java Web services, and Enterprise JavaBeans.
Figure 1. Major components of the WTP
In addition, WTP provides a core set of server tools for easy server customization and configuration. The runtime components and server tools are discussed in more detail in the following sections.
A useful addition to dealing with JSP programming in WTP is the form bean wizard: It can help you turn a simple Java class into a bean by generating getter/setter methods for any private variables defined in the class. In addition, various other wizards drastically reduce development time. One example is the servlet wizard, which is the fastest route for creating servlets in WTP. The wizard will auto-generate a servlet stub and place the generated source file in the JavaSource folder, and it will add the appropriate deployment descriptors to
web.xml to register the servlet and to define the matching URL pattern.
WTP assists tool developers by providing models for common J2EE artifacts, such as deployment descriptors. For Web applications, editing
web.xml to declare a servlet is a simple matter of opening the file in the J2EE perspective, and using the outline and design views to edit in "graphical mode." In addition, WTP provides high-fidelity editing support for all XML files, including code assist, syntax highlighting, validation, quick fixes, refactoring, and search.
Figure 2. Source Editor
SSE-based editors have been designed to interoperate with each other and with the base JDT components, so HTML and Java editing preferences would apply when editing a JSP page, for example. SSE essentially extends the basic Eclipse editor by partitioning documents into language regions, and then it associates editing services to each language.
When editing one of the aforementioned artifacts, SSE provides a subset of the following features:
When editing XML, the source pane provides the conventional text-based editing experience, with elements highlighted in green, attributes in purple, and strings in blue if you're using the default settings. We'll return to the source editing experience shortly, but first let's see the other presentations available. If you're using the default perspective settings, then you'll also see the outline view to the right, showing a structural representation of the XML file. The outline view also provides an easy way to make structural modifications to your document, such as reordering sections or swapping items in a sequence. You can also create new elements by right-clicking an existing element and choosing the type of the new child to insert. The property view shows the attribute settings for the selected element in conventional "property/value" form. Values can be changed directly from this view. For more information, visit the eclipse.org Web site, which has an excellent XML tutorial.
XML and schema files can be added to any project, but there's a simple example project type we can use to easier demonstrate the feature set. To use this, first ensure that you're in the J2EE perspective. Then, right-click in the project navigator, select New Project, then select Examples, and finally select Editing and validating XML files. This project creation wizard help you set up a project in which you can explore XML files, schemas, DTDs, and their interaction.
Once the example project is created, you'll find it listed under the Other category in your Project Explorer. If you accepted the default project name, it will be called XMLExamples. Open it, then open the PublicationCatalogue directory. You'll see an example XML file and its accompanying schema.
In addition to the source view, there's also a design view for XML. The design view is somewhat like a combination of the outline view and the property view in that it offers a structural image of the XML file, complete with attribute settings. However, unlike the property and outline views, in the design view all the content is visible and editable.
Figure 3. Design view
The XML source view performs both well-formedness and validation checking as you type. Add an element not defined in the schema, and the editor responds with a red squiggle under the unexpected element along with a detailed hover message explaining the problem. The error report disappears when the problem is corrected.
Validation of the XML can also be done on demand, similar to generating build errors in a language such as Java. To initiate validation, right-click in the Project Navigator window and select Validate XML File. The validation process will inform you of the result, and any problems will be recorded in the "problems" view along with markers on the offending lines of the source itself. Like all problems, these markers will persist until the next validation or the area of the text is deleted, whichever comes first.
Files with problems are also denoted in the Project Explorer, as are the projects that contain them.
Reporting errors is great, but avoiding them in the first place is even better.
To achieve this, content assist is available, and helps the user by offering, during text editing, completions based on schema or DTD information when it is available, and on an inferred schema (based on existing XML content) when it is not.
Like XML files, XSDs can be viewed in source mode and share syntax highlighting settings with XML. The property view for schemas utilizes an enhanced UI widget in WTP known as the "tabbed property view": Each of the tabs on the left-hand side contains different information about the schema's properties. The General tab shows the target namespace and prefix, while the Other tab shows the various schema-level settings. Finally, the Documentation tab shows the schema documentation element content, if present. In addition to viewing the text of a schema, its content may be viewed in graphical form by selecting the Graph (graphical schema view) tab at the bottom of the editing pane. Double-clicking an element in this view expands the element's definition; the ellipsis nodes indicate sequences, and occurrence settings are shown beneath elements.
Figure 4. XSD
The property view tracks the currently selected item in the graphical view, and provides editing capability for your current schema selection in the graph view. You can use the graphical view and property editor together to edit the schema. Right-clicking a sequence node, for example, brings up a context menu that enables (among other options) the addition of a new element. Selecting a node enables its type to be changed in the property editor. As with XML files, the outline view provides insight into the schema's structure, and is a handy way to reorganize or incrementally specify a new schema—support for creating new types, elements, and attributes make it easy to create new schemas or extend existing ones without having to recall the fine points of XSD syntax.
Schemas needed frequently or for offline use can be stored in the XML Catalog, which is also available in the preference pages. The XML Catalog enables both programmatic (plug-in-based) and user-defined storage of selected schemas, and permits their use to be keyed by public IDs, URIs, and namespace names in any project.
WTP provides support for AXIS 1.2 Web service functionality at many levels throughout the Eclipse environment. Working with Web services in WTP is done from within a dynamic Web project type, and the Project Explorer will display the set of Web service clients, local and remote Web services, and defined or generated WSDLs being developed. Extensible wizards can be used to generate both client and server bindings, while the built-in Web Services Explorer makes it easy to perform Web service discovery, testing, and UDDI publishing.
The WSDL editor provides a graphical editing view in addition to a source view, and can be used to define and modify imported schemas, types, messages, port types, bindings, and services. To create a WSDL file, select New from the Project Explorer, then select Web Services, and finally select WSDL. Supply the parent folder, if necessary, and the file. The remaining options are helpful in creating a WSDL you intend to hand-edit.
Figure 5. WSDL editor
The Project Explorer offers options to test WSDL files with the Web Service Explorer, validate the WSDL file against its schema, publish the WSDL, generate a client, generate a skeleton JavaBean, generate a client, or generate WSIL.
Developers can start with a WSDL file and easily create a skeleton JavaBean, which is a starter implementation for the operations defined in the WSDL. After adding your own code, the Web service can be deployed to the server and tested. WTP also provides a way for a client stub to be automatically generated, as previously mentioned.
Developers can start with a JavaBean class and easily do the reverse of the above to create a WSDL that describes the operations in the JavaBean. Simply supply the wizard with the class name for your JavaBean, pick the target server, associate target server and service projects, configure which methods in the JavaBean to expose as Web service operations, and the wizard will generate the Web service and offer UDDI publication options.
The Web Services Explorer is a JSP Web application hosted on the Apache Tomcat servlet engine contained within Eclipse. The Web Services Explorer provides three key services to the user:
Comprehensive support for discovering Web services in WS-Inspection 1.0 documents and in UDDI v2 or v3 registries using the UDDI v2 protocol.
Comprehensive support for publishing Web services to UDDI v2 or v3 registries using the UDDI v2 protocol. WTP offers options for IBM, MSFT, SAP, XMethods, and NTT Communications.
Comprehensive support for browsing and invoking Web services natively via their WSDL and XSD.
Figure 6. Web Service Explorer
WTP supports EJB development via an annotation-based model in which a single annotated source file is used to generate bean, interfaces, and EJB deployment descriptor files. In this release, XDoclet-based development of session and message-driven beans is supported, with entity beans support planned for the WTP 1.5 release. WTP and XDoclet support EJB deployment to a number of different servers, including WebLogic Server, JBoss, JOnAS, and WebSphere. EJBs can be created for standalone deployment to the server, or the EJB project can be one of many projects of a J2EE application and deployed as part of the application Enterprise Application (EAR).
Modeling servers, server connections, and the deployment of project artifacts to servers is a major focus of WTP functionality. WTP models server types (known as runtimes), specific server configurations, and deployable "modules"—artifacts that can be built in the project and deployed to one or more active servers.
There are two ways of defining server types in WTP: generic server definitions, an XML-based configuration file approach, and custom server definitions, a programmatic approach.
The generic server support is designed to simplify the process of defining a new server type by providing easy Ant-based publishing and using properties to define specific server settings. While not all WTP functionality is available, the process of configuring a new server type is quick and easy, and a UI exists to assist developers with property settings. For more information on this approach, see Gorkem Ercan's article, Generic Server - Server Definition File Explained. WTP 0.7 ships with generic server definitions for BEA WebLogic Server 8.1 and 9.0, WebSphere 6.0.x, JOnAS 4.x, and JBoss 3.2.3.
Custom server definitions expose the full power of the underlying WTP server infrastructure to customize such tasks as configuring third-party server runtimes, publishing projects to servers, adding and removing of projects to servers, server control (stop, start), and debugging. WTP adopters, such as BEA, often write custom server adapters for their commercial offerings, since this approach enables them to leverage the full power of the runtime to offer enhanced services, performance, or both. WTP also ships with custom server adapters for Tomcat 3.2, 4.0, 4.1, 5.0, and 5.5, and Geronimo 1.0 Server.
Figure 7. Server plug-in
Users define new servers in a two-step process when done for the first time. First, declare a new runtime in the preferences dialog. This configures the entire Eclipse development environment with the location of a server installation ("runtime") on disk and must only be done once for a given installation of a third-party server runtime. Second, the server view can be used to define an instance of a server that can be used during development for publishing modules, start/stop of server, adding and removing modules, debugging, and so on.
The "Run on Server" support allows developers to quickly run a module. Modules are defined as any content that can be deployed to a server, for example, a J2EE standard deployment unit like a Web project containing a servlet. Running in debug mode, if supported for that type of module, enables the user to step through the selected module's code for troubleshooting.
Several additional features add value to WTP.
The Project Explorer categorizes the types of projects you can create. There are separate projects for the various J2EE runtime components. Some examples include:
A J2EE application is assembled in an EAR project. Developers can use the New EAR Application Wizard to create a new EAR project and add EJB and Web service projects to it; modules from the Web and EJB projects are then automatically added to the EAR. The EAR project's Properties dialog can also be used to add more modules.
The JDT project model is not hierarchical, and the "exploded archive" structure for J2EE projects—one module per project—is not very flexible. Flexible Layout eliminates project migration and enables WTP to coexist with existing directory structures. You can create EJB projects, Web service projects, and additional Web projects, and add these to the same enterprise application and/or other enterprise applications. Enterprise application projects "assemble" the associated EJBs, Web services, and Web projects into an EAR and deploy it as a single unit. Remember that your server must have an EJB container for this functionality (Tomcat, for example, cannot be used for such deployments.)
Special project and XML file validators run during the build process. In WTP 0.7, Builders "assemble" J2EE modules in a project's .deployables directory. In WTP 1.0, the server publishing process handles assembly.
The focus of the WTP 1.0 release will be on the further development of platform APIs to enable the first wave of products based on WTP. Following that, WTP 1.5 will be released with the Eclipse 3.2 platform release in June 2006. Candidate items for WTP 1.5 include support for revisions of major specifications such as J2EE 5.0, SOAP 1.2, and WSDL 2.0, as well as new JSRs and Web service specifications.
We also expect the shape of WTP to change as new projects emerge and mature at Eclipse. New vendors are joining Eclipse, and projects are being created at a rapid clip. For example, the data tools in WTP will move into the newly created Data Tools project. Technology projects, such as those proposed for EJB 3.0, will likely influence WTP as they mature.
Pieter Humphrey has been at BEA for 7 years, working in technical sales and product marketing to help customers understand and apply our technology.