Overview of the Eclipse Web Tools Platform
by Tim Wagner, Ted Bashor, Paul Meijer and Pieter Humphrey
09/28/2005
Abstract
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:
- Extend the Eclipse platform for J2EE/Web application development
- Define servers, runtimes, and modules
- Provide platform API and suitable models for tool developers
- Provide core tools for application developers:
- A set of high-quality tools in their own right, plus exemplars for
tool developers
- A collection of high-fidelity editing services for Web and
J2EE-related languages
For more information about WTP and to get started with WTP and
Eclipse, go to the Eclipse
WTP project Web site.
WTP Project Charter
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.
WTP Scope
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.
Web Applications
WTP supports JSP-based Web application development including the use
of static HTML pages, JavaScript, CSS, JSP EL, and servlets. The JSP
source editor extends the HTML editor's capabilities, providing content
coloring and code assist inside Java, JSP, Tag Library, EL, and
JavaScript code fragments. WTP also supports JSR 45-compliant
debugging, enabling breakpoints to be set in JSP source,
stepped through, and so on. JSPs are created in the WebContent folder,
located in the Project Explorer tree structure of any Web Project type.
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.
Deployment descriptor editing
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.
Structured Source Editor framework
The ability to edit a "mixed" JSP page containing, say, JSP, HTML,
and JavaScript code blocks, or to do deployment descriptor editing, is
based on the Structured Source Editor (SSE) framework. SSE
provides multilanguage editing support, extending the base Eclipse
editor into areas other than Java editing. High-fidelity support for
source editing across all the languages used for Web application
development and feature compatibility with the JDT is part of WTP's
goal. Many of these features are already available in WTP 0.7 when
editing artifacts like XML, JSP and JSP EL, HTML, XHTML, CSS, DTD, and
JavaScript.
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:
- Highlighting
- Refactoring
- Semantic Highlighting
- Search Participant
- Content Assist
- Quick Fix/Assist
- Parameter/Attribute Hints
- Property Sheet
- Document/Element Formatting
- Outline View
- Structured Selection
- Folding
- Hover Info
- Annotation Navigation (go to next annotation)
- Smart Edit
- External Files
- Open On (hyperlinks)
- Toggle Comment
- Mark Occurrences
- Quick Type Hierarchy View
- Linked Edit
- Quick Outline
- Find Element Occurrences
- Task Tags in Source Comments
- Validate As-You-Type
- Delimiter Highlighting (bracket matching)
Refer to the WTP
milestone release plans for the latest feature/language matrix, or
to a
great article on the WTP site for more detailed explanations of
these individual features.
XML Tools
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.
Setting up an XML project
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.
Design view
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
Error checking
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.
XML content assist
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.
Schema editing
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.
Schema storage
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.
Web Service Tools
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.
WSDL editor
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.
Creating a new Web service from a WSDL
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.
Creating a new Web service from a JavaBean
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.
Web Service Explorer
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
Enterprise JavaBeans
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).
Server Tools
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
Using WTP server functions: Server definition
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.
Using WTP server functions: Debug/Run on Server
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.
Other WTP Features
Several additional features add value to WTP.
Project types/flexible projects
The Project Explorer categorizes the types of projects you can
create. There are separate projects for the various J2EE runtime
components. Some examples include:
- Application Client project
- J2CA Connector Client project
- Enterprise Application project
- Dynamic Web project
- EJB projects
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.)
Builders
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.
What's Next?
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.
References
Pieter Humphrey has been at BEA for 7 years, working in technical sales and product marketing to help customers understand and apply our technology.
|
Bookmark
