The background and status of this document:

This version is a second draft of WTP Architecture Overview and has incorporated comments received. Comments to wtp-dev list are welcome.

Version 0.3 December 2, 2004.

Eclipse Webtools Architecture Overview

The Web Tooling Platform (WTP) Project is made up of two subprojects, Web Standard Tools (WST) and J2EE Standard Tools (JST).

The list of components for WST and the list of components for JST give descriptions of the components and [eventually will contain] links to that component's specific design documents.

This document describes the subsystems that these components form. These divisions into subsystems are important because they form the basis of what is available to other projects, and end-user update manager features, and features for maintenance streams. Also, it allows a high level description of internal and external dependancies.

For end-users, there is currently only one news group, eclipse.webtools. For developers, there are currently three mailing lists wtp-dev, wtp-wst-dev, and wtp-jst-dev. As the project continues, if traffic seems "heavy" for a particular component, then new mailing lists and/or news groups will be created as needed.

This document decribes the Subsystem View, Dependancies on the Eclipse Project, Dependancies on Tools Projects, Relation to other Projects and Products, Summary in Graphical form, and Deployment View.

Subsystem View

WST Project

Build and Test Subsystem

For completeness, I'll mention our build and test component, highly modeled after the base Eclipse build and test components.

Common Subsystem

Components in this subsystem have no dependancies on other webtooling components and are not specific to web tooling functionality, but are needed by other web tooling components.

Server Subsystem

Database Subsystem

Will be an update manager feature.

XML Subsystem

Will be an update manager feature.

Web Services Subsystem

Web Resources Subsystem

Generic Web Module Subsystem

JST Project

Server Subsystem

JSP Resources Subsystem

Will be an update manager feature.

Basic J2EE Subsystem

Advanced J2EE Subsystem

Dependancies on the Eclipse Project

Platform

All components pervasively required by both WST and JST. Note, there might be a few not required in short term, such as debug component, but long term it is easily imagined to be needed.

JDT

Not required by WST, but required by JST. Note: we don't rule out that we might require it someday in WST ... but no known cases currently.

PDE

Not required, though obviously want to verify co-existence.

WebDav

While not an official platform project or component, we do want to verify co-existence.

Dependancies on Tools Projects

In addition to the base Eclipse, the following projects/packages are prerequisites of the Webtooling Platform. GEF, EMF, and XSD are pre-req'd by enough of WST to say its always required. The JEM package is only pre-req'd by JST.

EMF

EMF, Eclipse Modeling Framework, is a way to define meta models, and then instantiate specific instances of those models. Its particularly famous for being useful to maintain models across multiple products, especially when the model may change from one release to another (the way that deployment descriptors and J2EE specs change from version to version.

XSD

The XSD, XML Schema Infoset Model, Project provides a model and API for querying detailed information about schemas and manipulating them. [Note: technically XSD Infoset is part of Technology Project, but is distributed with EMF]

GEF

GEF, Graphical Editing Framework, is a framework "on top" of SWT that makes it easier to develop sophisticated, highly customizable user interfaces that go beyond typical widgets .

JEM Package

The JEM package, Java EMF Model, is actually part of the VE Project. The VE team has recently made it available as separate download from their VE build pages. In addition to allowing easier interaction with other EMF models, it also incorporates BeanInfo into its models (not just reflection). We use it in connection to our J2EE EMF-based models. From what I hear, there's no ISV documentation for this package, but the rose models that are used to create the meta model can be found in CVS on dev.eclipse.org
/home/tools
under
/org.eclipse.jem/rose
To load into rose (from workspace) you'd also have to have org.eclipse.emf.ecore in workspace, and define, in Rose, an EditPathMap of WorkspaceRoot as what ever your workspace root is on your filesystem (then it can find included files/models automatically).

Others

Xerces. We currently ship Xerces binaries within plugin's runtimes that require them. [There's been some discussion that with OSGI classloading of PPS (Platform (bootloader), Pre-reqs, Self), that it should be easier to provide a common Xerces plugin, as long as there's no version requirements conflicts, and no custom class loaders involved, and appropriate factories used to "get" the specific parts of Xerces needed that are not part of the platforms runtime].

Relation to other Projects and Products

J2EE Servers

Database Servers

Summary in Graphical form

The following diagrams summarize the subsystem and relationships described above.


The darker shaded subsystems are accessible by end-users and other components via update manager.


The darker shaded subsystem (orange) is accessible by end-users and other components via update manager.
The white subsytems indicate the "links" into the WST subsystem. The JDT and JEM components indicate two
components from other projects required in JST, but not required in WST.


Deployment View

This section makes explicit what is currently planned to be made available as deployable features via update manager. This is paritally driven by views expressed by community users, and partially dirven by the expressed needs of other projects. It may not be the perfect "slice and dice" of the whole package that would suit everyone, but the expecation is that other projects can always download more than they need, and pick and choose the exact components they want to re-distribute.

All deployment features below will have a "binary" runtime version, and an SDK version, with all source and developer documentation.

At the hightest level, is JST and WST seperately. (With JST requireing WST).

Within JST, user's can choose all of JST, or JSP Subsystem.

Within WST, users's can choose all of WST, or the XML Subsystem (includes Schema and DTD components), or the Data Subsystem

Of Course, at any point of a decision, the choosen "subcomponent" will still "pull allong" all that its dependent on.