Google Git
Sign in
eclipse / www.eclipse.org / webtools / 13c61b8971cb027b489d5897463f9e6941d3a0fb / . / development / arch_and_design / ArchitectureOverviewInitial.html
blob: b0ef1f160ae6beebcf557973b48aaebec719e103 [file] [log] [blame]
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta name="GENERATOR" content="Pseudo WTP" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link href="theme/default_style.css" rel="stylesheet" type="text/css" />
<!--
<link href="theme/Master.css" rel="stylesheet" type="text/css" />
-->
<title>Eclipse WTP Architecture Overview</title>
<style type="text/css">
<!--
dt {
font-weight: bold
}
-->
</style>
</head>
<body>
<div align="center">
<h1>Eclipse Webtools Architecture Overview</h1>
</div>
<div align="center">
<table border="1" cellpadding="10" height="50%" width="70%">
<tbody>
<tr align="left" valign="middle">
<td valign="middle" align="left">
<blockquote>
<p><cite>The background and status of this document.</cite></p>
<p><cite> Version 0.1 August 16, 2004. </cite></p>
<p><cite>While this document is a work product of the <a
href="#architecturegroup">WTP Architecture Group</a> I will have to take
full responsibility for all the many errors and omissions it contains,
but will give credit both to the Architecture Group and the many other
teams for their many valuable contributions to it and the time they spend
educating me.</cite></p>
<p><cite>This first version of this document is being distributed now,
even though still rough and incomplete (I'd guess about 50% incomplete), to get some community
readership to determine if it represents a useful direction and if it
should be continued. Feedback, questions, and comments can be made to
the wtp-dev mailing list.</cite></p>
<p>Thank you for your contributions, David Williams (david_williams@us.ibm.com)</p>
</blockquote></td>
</tr>
</tbody>
</table>
</div>
<h2>Purpose and Objectives</h2>
<p>Given a heterogeneous group of people, companies, and contributions, it
would be difficult for WTP to be easily &quot;open&quot; to a community without some
overview of its architecture. The
purpose of this document is to give a high-level view of the
architecture that is implicit in most of the initial contributions. Over time, this document will capture the architecture of the Eclipse Web Tooling Platform. This document is not the Architectural Plan, as required by the <a
href="http://www.eclipse.org/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
Development Process</a> listed on the Eclipse <a
href="http://www.eclipse.org/org/documents/main.html" target="_top">Governance</a> page. That Plan will be written later, but, hopefully, as an outgrowth of this docuent. </p>
<p>This
Overview documents the current and desired architecture of WTP
as a whole -- that is, contributed components will (still) be expected to
document their own architecture, designs, APIs, and how they fit in to
overall architecture -- and, since it is a comunity based project, the level and timing of that documentation will vary greatly. </p>
<p>
The benefit of having an overall document is that it can capture things
that are not captured by individual pieces: both across component relationships and
also things which might seem unique when individual pieces are examined,
but which are really common when the system is viewed as a whole.</p>
<p>The
primary reason for doing this work is to make it easier for others to
contribute to WTP and to integrate with it. That is, it is to serve as
something of a road map, guiding contributors and integrators on the
most scenic areas of interest. It is definitely not intended to be a &quot;how to&quot; manual -- it won't give all the answers to specific questions (and actully in most cases not any of the answers to specific questions) -- but hopefully will make it easier to find where to look for the answers. Also, it is definitely not intended to be a
return to centralized development practices, but simply to help guide
decentralized development. To stretch a commonly used open source
metaphor, the architecture document is to be more of architecture of a
bazaar, rather than the architecture of a cathedral (and, to be
explicit, the best bazaars do have some organization -- they are not
just random anarchy!).</p>
<p>A second reason for doing this work is to help keep track of holes or errors in
current architecture -- or, stated another way, find things that are not
architected, but merely implemented. </p>
<p>
This architecture document may summarize the
extensible and pluggable areas where components can be easily changed or
extended. But that's primarily documented component by component. </p>
<p>It
is hoped this document will also be useful as planning and requirements
input, for example, if there are missing or redundant pieces, it would
be easier to plan what to do about that, given some overall
documentation, rather than trying to decide each individual case in
isolation. Eventually, in the long run, hopefully it'll evolve to work in the opposite direction too, input from requirements and plannning can be used to modify this document and the architecture itself.</p>
<p>This architecture document is expected to be a &quot;living&quot; document,
updated at least every milestone both to remain &quot;current&quot; and to be
improved with feedback from the community. It is also anticipated that
people contributing to this document will be code-contributing members.... that
is, its no ivory tower where work goes on in isolation!</p>
<h2>Web Standard Tools vs. J2EE Standard Tools</h2>
<p>Overall the project is &quot;split&quot; into Web Standard Tools (WST) and J2EE Standard Tools (JST), as is well described by the links from the description of the project <a
href="http://www.eclipse.org/webtools/index.html" target="_top">Eclipse Web Tools
Platform Project </a>.</p>
<p>Architecturally, the J2EE components depend on the Web Standard components, but not vice versa. (That is, I should say this will be case, there's still some case of refactoring needed to have &quot;perfect&quot; separation).</p>
<h2>Architecturally significant use cases</h2>
<p>High level uses case are document here to give a high level idea of the what this overview is meant to cover.
</p>
<p>[4 to 6 more high level use cases to be added later.]</p>
<ul>
<li>Create a web application, including deployment descriptors, HTML, JSP, and
Java files, and run them from the WTP-IDE on a local or remote test
server.</li>
</ul>
<h2>Architectural Viewpoints</h2>
<p>The architecture is described from several points of view. Each
point of view highlights particular aspects of the system, and different
readers may be interested in one view over others. Overall, though, this document focuses on documenting the &quot;model-driven&quot; architecture, meaning that the system is described in terms of the model objects, their properties, and how they interact with each other. For example, its not intended to document an editor for a web resource, but that fact that it can be modified by changing specific models is the architecturally important part. </p>
<blockquote>
<h3>Static Development system Viewpoint</h3>
</blockquote>
<blockquote>
<p>This is the system as its &quot;actively idle&quot; ... that is, a
developer in using it to create a web application, using editors,
wizards, properties, etc. to create artifacts, but does not include
actually running, debugging, deploying, or publishing anything.</p>
</blockquote>
<blockquote>
<h3>Run/Debug Development viewpoint</h3>
</blockquote>
<blockquote>
<p>This view point highlights those areas of the system that come into
play while running or debugging on a test server, to test that the
application works correctly.</p>
</blockquote>
<blockquote>
<h3>Components view point</h3>
</blockquote>
<blockquote>
<p>This view point shows the systems as "logical collections",
typically "owned" by one team, typically in same geographical area.</p>
</blockquote>
<blockquote>
<p>In addition to the logical grouping, the Components view point will
mention significant supporting classes or pre-reqs which might not be
obvious from the other view points.</p>
</blockquote>
<hr />
<h2>Static Development system</h2>
<h3>Server/Runtime target</h3>
<blockquote>
<p>The server/runtime target defines the properties and runtime class
library of a particular server. These properties and runtime class
library is used by the web project to know what's appropriate for that
web project, given certain servers. </p>
</blockquote>
<blockquote>
<p>This figure of a simplified view of the server target shows how its definition comes from an Eclipse Extension, but that a particular defined instance of a server would have extra info associated (and saved) with it, such as where the runtime jars are located on the local file system. The runtime jars are needed for &quot;static development&quot;, but of course the &quot;real&quot; runtime jars are used when the server is ran. </p>
<p><img title="Target Server Instance" src="images/server.png" width="566" height="246" name="ServerTargetInstance" alt="ServerTargetInstance"/></p>
</blockquote>
<h3>WebProject and Webnature</h3>
<blockquote>
<p>The WebProject and WebNature describes how and where various deployment artifacts (resources such as web.xml files, etc.) are stored, and other information that's important at &quot;development time&quot; such as the intended target server. </p>
</blockquote>
<blockquote>
<p>Its important to note that the actual deployment descriptor for a web
app, namely web.xml, is, in our system, conceptually just a serialized
form of the web app model. This is a frequent pattern though out the framework. And, of course, the web.xml file is still standard, can still be deployed as usual, etc. Of course, there is occasions when there is extra information we'd like to keep track of due to being in an IDE enviroinment that is not really part of the standard deployment descriptor, so that is written to some meta data file associated with the project. These relationships are shown in the following figure. <br />
<br />
<img src="images/webAppAndServerTarget.png" width="645" height="246" />
</p>
</blockquote>
<h3>Web resources (html, jsp, xml files, etc).</h3>
<blockquote>
<p>The main model object used to manipulate web resources are a
StructuredModel and a StructuedDocument. XML, JSP, and HTML all have a
special DOM Model associated with them. DTD and CSS have similar
DOM-like models associated with them, but technically don't meet the DOM
spec. (DTD is very close, CSS is more like a list of nodes, rather can a
hierachey of nodes). The StructuredDocument is very similar to the
IDocument interface, and just adds some specialized events to make
incremental updates possible. The following figure shows these relationships as they might be while editing a web.xml resource.<br />
<img src="images/ModelEditing.png" width="668" height="236" />
<br />
</p>
</blockquote>
<blockquote><p></p>
<p>I hope the careful reader is wondering what happens if the web app model and the DOM Model both want to update the web.xml text. There's certainly the usual &quot;resource changed&quot; listeners that are common in Eclipse to help things keep in synch, but sometimes changes are desired from one source or the other without actually saving the resource. This leads to another typcial pattern used in our systems, that of model-to-model adapters, as shown in the following figure. <img src="images/modelToModel.png" width="766" height="383" />
</p>
</blockquote>
<h3>Database Model</h3>
<blockquote>
<p>[more to be provided later]</p>
</blockquote>
<blockquote>
<p>Models for databases, connections, tables, etc.</p>
</blockquote>
<h3>Database Queries</h3>
<blockquote>
<p>[more to be provided later]</p>
</blockquote>
<blockquote>
<p>SQL Model based on SQL-99 Standard. Uses/depends on EMF.</p>
</blockquote>
<h3>WebServices</h3>
<blockquote>
<p>[more to be provided later]</p>
</blockquote><hr />
<h2>Run/Debug Development viewpoint</h2>
<blockquote>
<p><b>[Obviously ... this section is very incomplete .... more to come ... if deemed important, and if there's time, which I only say since it could be one of the more complicated to document usefully]</b></p>
</blockquote>
<h4>Server (proxy)</h4>
<blockquote>
<p>This server object differs some from the server/runtime target, in
that it actually controls the &quot;running&quot; on the server. In the
standard (contributed) case, this server depends on a
&quot;standard&quot; Eclipse project layout. (A future work item is to
allow more flexible project structures.)</p>
</blockquote>
<h4>TCPIP Monitor</h4>
<blockquote>
<p>Its probably worth noting that the TCPIP monitor actually setups a
&quot;proxy&quot; server, to monitor traffic to and from the test server
(it can not monitor traffic from any arbitrary server)..</p>
</blockquote>
<hr />
<h2>Components view point</h2>
<p>[Editors note: it is in this seciton I'd like to (in the long run) have links to the specfic components design and API documentation.]</p>
<p>Defintion of terms [open to debate]: I've tried to use <i>Subsystem</i> which seems the term the <a
href="http://www.eclipse.org/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
Development Process</a> uses to denote a large, logically related set of components, which are fairly ndependent of other subsystems, at least conceptually. I've used the term <i>Component</i> to mean that part of as subsystem that conceptually has meaning by itself, and which would be recognized or seen by an end-user as &quot;part of the system&quot; and identifiable with some standard or specification. Sub-component is similar, but maybe highly related to other components (due to re-use) but which is typically transparent to the end-user. </p>
<h2>Subsystem: Server-tools</h2>
<blockquote>
<h4>WST Component: Server Framework</h4>
</blockquote><blockquote>
<p>This framework handles definition of any (or, at least many) servers
and server types, but the actual server support is provided in
subcomponents.</p>
</blockquote>
<blockquote>
<h4>WST Component – HTTP standard server tools</h4>
</blockquote>
<blockquote>
<h4>WST Component - Internet (Built in Browser, tcpip montior,
Proxy preferenes)</h4>
</blockquote>
<blockquote>
<h4>JST Component – tomcat standard server tools</h4>
</blockquote>
<h2>Subsystem: Web Resources </h2>
<blockquote>
<p>This framework is used for deployment descriptors (XML source) [Note:
no special deployment editors are in current contribution, so they are
just treated as xml files. And, of course, true web resources (XML,
HTML, XHTML, CSS, JavaScript). </p>
</blockquote>
<blockquote>
<h4>WST Component – Structured Source Editors framework</h4>
</blockquote>
<blockquote>
<p>The primary purpose of extended the base text editing support is to
provide specialized models and events which can lead to better
performance, and easier interaction between other models. In particular,
its thought the most used model in this framework will be the DOM model,
which implements DOM Level 2 APIs but is a &quot;custom&quot;
implementation, which can 1. handle ill formed markup (as it always is
during editing) 2. can be done incrementally (as opposed to
&quot;batch&quot; processing, as most DOM parsers do), and 3. provides a
few &quot;extra&quot; APIs that make the DOM more suitable for use in
tools. Note: the JavaScript editor does not make use of &quot;Structured
Source Editor&quot; models and there is no &quot;JavaScript&quot; model
to interact with ... that interaction is all done at a document level.</p>
</blockquote>
<blockquote>
<h4>JST Component – JSPs (editing, menus, wizards, indexing, refactoroing, etc.)</h4>
</blockquote>
<blockquote>
<p>In our framework, JSP's are treated as a &quot;marked up&quot;
document. Technically this is not required by the JSP Specification, but
in practice seems to be the common (maybe only!) case. This allows
interaction with the DOM model of the JSP to modify it, search it, etc.
</p>
</blockquote>
<blockquote>
<h4>WTP Component – HTML (editing, menus, wizards, indexing,
refactoroing, etc.)</h4>
</blockquote>
<blockquote>
<h4>WTP Component – CSS (editing, menus, wizards, indexing,
refactoroing, etc.)</h4>
</blockquote>
<blockquote>
<h4>WTP Component – JavaScript (editing, menus)</h4>
</blockquote>
<blockquote>
<h4>WST Subcomponent – XML base tools (URI Resolvers, ContentModels, XML and Schema Validation)</h4>
</blockquote>
<blockquote>
<p>Many functions relay on some &quot;low level&quot;
models, which are important enough to call out for special attention.
URI Resolvers are critical in correctly &quot;finding&quot; related
resources in a web project, and &quot;content models&quot; are used to
define the &quot;legal content&quot; of XML, Schema, TLDs, HTML, and JSPs.
These content models also have behavior and extension points to allow &quot;extra data&quot; to be
associated, such as the information used in &quot;hover help&quot;.
Includes URI Resolvers, ContentModel Interface (and implementation for
for DTDs and Schemas). This project subcomonent also provides project-based validation of XML files. -- One item for the future is that this component may relay on Xerces, so make use of its XMI interace, to provided better information in validation errors and warnings. The Xerces dependancy is currently intentionally an &quot;internal&quot; dependancy, not shared amount the project. This subcompent has dependancy on EMF.</p>
</blockquote>
<h2>SubSystem: Web Applications and Projects</h2>
<blockquote>
<h4>WST Subcomponent – Common Archive Framework</h4>
</blockquote>
<blockquote>
<blockquote>
<p>Handles loading/storing archives using pluggable strategies</p>
</blockquote>
</blockquote>
<blockquote>
<h4>WST Subcomponent – Project Support</h4>
</blockquote>
<blockquote>
<blockquote>
<p>Import/Export/Creation Support</p>
</blockquote>
</blockquote>
<blockquote>
<h4>WST Subcomponent – Common Navigator</h4>
</blockquote>
<blockquote>
<blockquote>
<p>Extensible framework that provides content to resources in workbench</p>
</blockquote>
</blockquote>
<h2>SubSystem: J2EE Applications and Projects</h2>
<blockquote>
<h4>JST Subcomponent – J2EE Resources</h4>
</blockquote>
<blockquote>
<blockquote>
<p>EMF based models</p>
</blockquote>
<blockquote>
<p>Also depends on JEM package.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Provides specialized J2EE EMF Resource handling</p>
</blockquote>
</blockquote>
<h2>SubSystem: Database</h2>
<blockquote>
<h4>Component: Data Tools</h4>
</blockquote>
<blockquote>
<h4>Component: SQL'99 Tools and models</h4>
</blockquote>
<h2>SubSystem: Webservices</h2>
<blockquote>
<h4>WTP Component WSI</h4>
</blockquote>
<blockquote>
<h4>WTP Component WSDL</h4>
</blockquote>
<blockquote>
<h4>WTP Component WS Models (soap, uddi, wsil)</h4>
</blockquote>
<h2>SubSystem: XML and Schemas</h2>
<blockquote>
<h4>WTP Component: XML Validation</h4>
<h4>WTP Component: XML/Schema Generation</h4>
<p>Provides &quot;extras&quot; to standard source edinting, the ability to generate and xml instance file from a DTD or Schema is one of the coolist. </p>
</blockquote>
<h2>SubSystem: Web Tooling Common Base</h2>
<blockquote>
<p>These are tools and frameworks required by multiple higher level
components, which must be at low level in the “stack” of components to
be shared, or, with careful review, common utilities.</p>
</blockquote>
<blockquote>
<h4>WTP Component - Validation Framework</h4>
</blockquote>
<blockquote>
<blockquote>
<p>Special Eclipse builder, that allows validation of resources.
Typically, higher level components provide extensions to this framework
to handle validating their particular models and resources, such as XML,
EJBs, etc.</p>
</blockquote>
</blockquote>
<h1>Pointers to prerequiste projects</h1>
<p>In addition to the base Eclipse, the following projects/packages are prerequistes of the Webtooling Platform. </p>
<h2>EMF</h2>
<p>EMF, <a href="http://www.eclipse.org/emf/" target="_top">Eclipse Modeling Framework</a>, 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, espcially when the model may change from one release to another (the way that deployment descriptors and J2EE specs change from verison to version. </p>
<h2>GEF</h2>
<p>GEF, <a href="http://www.eclipse.org/gef/" target="_top">Graphical Editing
Framework</a>, is a framework &quot;on top&quot; of SWT that makes it easier to develop sophistocated, highly customizable user interfaces that go beyond typical widgets (I believe we only use this in our snippets view, subuilder, and schema editor -- though there's been some discussions of using it with XML editor in the future). .</p>
<h2>JEM Package</h2>
<p>The JEM package, Java EMF Model, is actually part of the <a
href="http://www.eclipse.org/vep/" target="_top">VE Project</a>. The VE team has recently made it available as seperate download from their <a
href="http://download.eclipse.org/tools/ve/downloads/drops/S-1.0M2-200407301410/index.html" target="_top">VE
build pages</a>. 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<br />/home/tools<br />under<br />/org.eclipse.jem/rose<br />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). </p>
<h2>XSD</h2>
<p>The <a href="http://www.eclipse.org/xsd/" target="_top">XSD, XML Schema Infoset
Model, Project</a> provides a model and API for querying detailed information about schemas and manipulating them. </p>
<h2>Others</h2>
<p>[Eventually, we may document here certain packages we use and ship internally, such as Xerces, just to help avoid duplicating such internal packages.]</p>
<h1>Known Architectural/Design Issues</h1>
<p>This section is just to be explicit about architectural issues
that are known and which the architecture committee will be discussing various solutions to. </p>
<p>Note always a clear seperation between &quot;model&quot; and &quot;view&quot; objects ... yes, we confess, occasionally, given some bit of a codes history or deadline driven design, our model/view seperation is less than perfect (but don't get me wrong, its pretty good!). </p>
<p>Multiple java models (JDT and JEM).
Maybe not a real issue per se,
but not sure we’ve documented differences between them, when to use one
vs. the other, etc.)</p>
<p>Multiple operation/command frameworks are in
initial contribution – need to resolve to one and/or coordinate with
base Eclipse plans.</p>
<p>Currently "meta data" or &quot;extra information&quot; is stored inconsistently
(and hard to find/understand). Sometimes in (several) files with no names,
sometimes as OSGI preferences, but there’s no “framework” for common,
easy access.</p>
<p>There are currently two (or more!) frameworks for providing URI resolution. Some work is needed to determine if the Extensible URI Resolution framework can be used to replace all of them. </p>
<hr />
<dl>
<dt><a name="architecturegroup">WTP Architecture Group</a></dt>
<dd>David Williams, IBM</dd>
<dd>Chuck Bridgham, IBM</dd>
<dd>Erich Gamma, IBM</dd>
<dd>Henrik Lindberg, Frameworx</dd>
<dd>Naci Dai, Eteration</dd>
</dl>
<p></p>
</body>
</html>