<html><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><link type="text/css" href="../../../default_style.css" rel="stylesheet"><link type="text/css" href="../../../webtools/wtp.css" rel="stylesheet"><title>Preliminary Architectural Assessment</title></head><body><table border="0" cellpadding="2" cellspacing="5" width="100%"><tbody><tr><td align="left" width="60%"><font class="indextop">WTP Architectural Assessment at M4</font><br><font class="indexsub">Preliminary Architectural Assessment</font></td><td width="40%"><img src="../../../webtools/images/wtplogosmall.jpg" align="middle" height="129" hspace="50" width="207" alt="WTP Logo" usemap="logomap"><map id="logomap" name="logomap"><area coords="0,0,207,129" href="/webtools/" alt="WTP Home"></map></td></tr></tbody></table><table border="0" cellpadding="2" cellspacing="5" width="100%"><col width="16"><col width="*"><tbody><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><table border="1" cellpadding="10" height="50%" width="70%"> | |
<tbody> | |
<tr align="left" valign="middle"> | |
<td valign="middle" align="left"> | |
<blockquote style=""> | |
<p> | |
<cite> | |
The background and status of this | |
document: | |
</cite> | |
</p> | |
<p> | |
<cite> | |
4/26/05 - this is just a preliminary | |
rough draft of some of my initial | |
personal observations of where we | |
are architecturally at M4. | |
<br> | |
Updated based on review meetings | |
held 5/3. | |
<br> | |
<br> | |
Comments to wtp-dev list are | |
welcome. | |
</cite> | |
</p> | |
<p> | |
<cite>Version 0.3 May 11, 2005.</cite> | |
</p> | |
<p> | |
<cite>David Williams</cite> | |
</p> | |
</blockquote> | |
</td> | |
</tr> | |
</tbody> | |
</table></td></tr><tr><td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">General impressions of status</font></b></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
In "quick assessments" such as this one, its easy to seem critical, and | |
hard to write all the good and complimentary things I see in | |
WTP, so I hope this general statement suffices. There are a | |
lot of good things, tremendous progress has been made, and | |
all teams are working very hard to provide good function and | |
true platform quality code and APIs. Its hard to ask for | |
more than that, but below are some items that could use more | |
work before Release 1.0 (and this is just in my humble, | |
off hand impressions, so I may have missed things, or may have | |
misinterpreted some things). I intend these remarks only as | |
constructive suggestions or questions to make WTP even better than | |
it is. | |
</p></td></tr><tr><td align="right" valign="top"><img src="../../../images/Adarrow.gif" border="0" height="16" width="16"></td><td>State of plugin structure</td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p>Overall, We still have too many plugins.</p></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
Many divisions still determined by "function" rather | |
than component. | |
</li> | |
<li> | |
Many divisions still determined by "team" or "site" | |
rather than component. | |
</li> | |
<li> | |
many appear to be used by only one other plugin, so | |
why separate? (there's even one not pre-req'd by any | |
plugin .. pure extension). | |
</li> | |
<li> | |
Many "validation" ones are separate ... is there a | |
reason for this? [AR] wsi command line validation is | |
required. [DW] but does this require separate | |
plugins? | |
</li> | |
<li> | |
Many "annotation" ones are separate ... is there a | |
reason for this? | |
</li> | |
<li> | |
Some need to renamed to make obvious "core vs. ui" | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"><img src="../../../images/Adarrow.gif" border="0" height="16" width="16"></td><td> | |
Need more granular feature definitions (both for end | |
users, and products building on WTP that may not use all | |
of WTP). | |
</td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
General agreement should be primarily from "end user | |
point of view". | |
</li> | |
<li> | |
Should be based on subsystems, as defined below. | |
</li> | |
<li> | |
Still need to investigate model vs. UI packaging. | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"><img src="../../../images/Adarrow.gif" border="0" height="16" width="16"></td><td> | |
Need to define and set proper expectation and definition | |
of "internal.provisional". | |
</td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
they are, first and foremost, 'internal', subject to | |
change, even removal. there is no implied support. They | |
have been named "provisional" as a signal that we'd like | |
review comments and statements of need from community | |
for future releases. All cases of 'internal' are so | |
named so that clients who use them assume the risk of | |
re-working their code in future versions. We would like | |
it if when any internal package found to be needed, | |
feature requests were opened so appropriate solutions | |
could be designed to satisfy needs of community (and | |
still provide platform quality APIs). | |
</p></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
Note: in M4, much effort was made to assess what could | |
be API, and what could not. In some cases, the "could | |
not" cases did not get renamed in time for M4. Will do | |
early in M5 cycle. | |
</p></td></tr><tr><td align="right" valign="top"><img src="../../../images/Adarrow.gif" border="0" height="16" width="16"></td><td>We have no "friend" APIs defined for WTP.</td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
'Friend' meaning ok for some "outside" component to use, | |
while still inside project. We could not meaningful do | |
this for release 1. This is something we should do for | |
future releases. | |
</p></td></tr><tr><td align="right" valign="top"><img src="../../../images/Adarrow.gif" border="0" height="16" width="16"></td><td> | |
API violations in our use of base Eclipse and pre-reqs? | |
</td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
This is currently a fairly large "unknown" and we need | |
improved reports (and component definitions from base | |
Eclipse). I suspect we have a lot. I suspect some can be | |
"cleaned up" and some can not (and will need more work | |
with base to know if "future requirement" or if we are | |
doing something wrong.) | |
</p></td></tr><tr><td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Summary of components and API status</font></b></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
For those items below marked | |
<b>"ready for review"</b> | |
I have opened bugzilla meta-bugs to encourage explicit comments | |
from community and clients specifically during M5 cycle | |
review. These reviews are not so much for feature requests (those | |
could be seperate bugzillas) but for things like if JavaDoc is wrong or | |
in adequeate, if something appears not to be evolvable, or even if | |
the design or problem to solve seems unclear so that you could not | |
write to the APIs. Or ... you could include a few compliments :) | |
</p></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
Note: following "subsystem" don't match Arch. Doc. | |
exactly (it needs to be updated), but concept is the same. Features, | |
dependencies, etc., still flow from the subsystem | |
definitions. | |
</p></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>Common Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li>Common Component</li> | |
<ul> | |
<li> | |
Extensible Navigator --> internalProvisional, | |
moving to base 3.2 | |
</li> | |
<li> | |
Tabbed Property View --> internalProvisional, | |
moving to base 3.2 | |
</li> | |
<li> | |
Snippets View --> internalProvisional. Belongs | |
here in WTP. Needs more work to better integrate | |
with Eclipse Templates (if possible) | |
</li> | |
<li> | |
Extensible URI Resolver --> internalProvisional. | |
</li> | |
<p> | |
Appears not to handle several use-cases, | |
question is if it ever could. Some question on | |
OASIS standards. | |
</p> | |
<li>common frameworks</li> | |
<ul> | |
<li> | |
data operations - IDataModel - | |
<b>ready for review.</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94889">94889</a> | |
</li> | |
<p> | |
[need review from Chris B., to see if he | |
could move to it post release 1.0] | |
</p> | |
<li>data wizards - provisional</li> | |
</ul> | |
</ul> | |
<li> | |
Validation Framework Component --> | |
internalProvisional. | |
</li> | |
<p> | |
good client design and requirements sessions, but | |
may be trying to cover too much. | |
</p> | |
<li>Command Framework Component</li> | |
<p> | |
I don't think should be a "component". (since we | |
don't want to introduce yet another 'command' or | |
'operation' framework). I don't think it should have | |
provisional API. Could it be integrated with | |
"DataOperations"? There is fundamental question if | |
"running headless eclipse application" suffices, or | |
if we really need to provide an API that does not | |
pre-req Eclipse at all. | |
</p> | |
<li> | |
common.componentcore (needed for flexible projects) | |
- | |
<b>Ready for Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94890">94890</a> | |
</li> | |
<p> | |
But pure resource part rightfully belongs in base. | |
Need better distinction between flexible project | |
consumers, and Flexible project providers (those | |
that define what the flexible project is). (former | |
might be evolvable API, but not sure later could be | |
without being in proper project). My advice is to | |
publish as internal .provisional ... but don't mind | |
pushing forward with review, since part of it | |
belongs in base, since not sure if it works well | |
with base's "logical resources". since providing | |
team same as client team, since base is looking at | |
"non-local resources" in 3.2 ... all of which could | |
impact design. especially need review from base to | |
determine if evolvable with their plans. | |
</p> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>Server Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
Server Component -- | |
<b>Ready for Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94891">94891</a> | |
</li> | |
<p> | |
some review already indicated some issues to resolve | |
especially with server providers | |
</p> | |
<li>Internet Component</li> | |
<ul> | |
<li> | |
browser/launch URL API --> moved to Eclipse 3.1. | |
</li> | |
<li>Pref. --> 3.2</li> | |
<li> | |
Monitor --> internal.provisional, pending post | |
1.0 review with TPTP | |
</li> | |
</ul> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>Database Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
DB/SQL - internal, not API due to probable DTP | |
project merge | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>XML Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
XML Component - some internal provisional .. need | |
better design documents .. more refactoring | |
</li> | |
<li> | |
Schema Component - some internal provisional .. need | |
better design documents .. more refactoring | |
</li> | |
<li> | |
DTD Component some minimal internal provisional .. | |
need better design documents .. more refactoring | |
</li> | |
<li> | |
SSE Component some internal provisional .. need | |
better design documents ... .. more refactoring, | |
especially need better distinction between language | |
consumer APIs and language provider APIs. | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>Web Services Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li>WS Component ... some internal provisional</li> | |
<li> | |
WSDL Component. | |
<b>Ready For Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94892">94892</a> | |
. WSDL Spec Model API (see "EMF Models" notes). | |
</li> | |
<li> | |
WSI Component ... ? some API (provisional?) from | |
WSTV project ? | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>Web Resources Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
HTML Component .. some internal provisional .. need | |
better design documents | |
</li> | |
<li> | |
CSS Component ... some internal provisional .. need | |
better design documents | |
</li> | |
<li> | |
JavaScript Component some minimal internal | |
provisional .. need better design documents | |
</li> | |
<li> | |
Web Project Component - no api, HTML Web Project | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>JST Server Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
Server Component - | |
<b>Ready For Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94893">94893</a> | |
</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4>J2EE Web Subsystem/Feature (WAR)</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
J2EE Core Web Model Component [Issue: not currently | |
packaged this way] | |
<b>Ready For Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94887">94887</a> | |
(see "EMF Models" notes). | |
</li> | |
<li> | |
Servlet Component/J2EEWebProject ... some API, | |
create web component API | |
</li> | |
<li> | |
JSP Component ... some internal provisional .. need | |
better design documents | |
</li> | |
<li>WS Web Component (JAXRPC)</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><h4> | |
J2EE Enterprise Subsystem/Feature (EARs, EJBJar, | |
EJBClientJar, RARs) | |
</h4></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><ul> | |
<li> | |
J2EE Core Enterprise Model Component [Issue: not | |
currently packaged this way] | |
<b>Ready For Review</b> | |
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94887">94887</a> | |
(see "EMF Models" notes). | |
</li> | |
<li>EJB Component</li> | |
<li>WS Component</li> | |
</ul></td></tr><tr><td align="right" valign="top"> | |
| |
</td><td valign="top"><p> | |
Note: EMF Models for J2EE and WSDL have expressed the | |
primary API part of their models is intended to be the | |
interfaces defined by respective specifications. But | |
general consensus in 5/3 review meeting that its "ok to | |
assume EMF model" is part of the API. Still, components | |
encouraged to "spec" how generated, intended use, etc. | |
</p></td></tr></tbody></table></body></html> |