<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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><p>Overall, We still have too many plugins.</p></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>Common Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </td><td valign="top"><ul>
				<li>Common Component</li>
				<ul>
					<li>
						Extensible Navigator --&gt; internalProvisional,
						moving to base 3.2
					</li>
					<li>
						Tabbed Property View --&gt; internalProvisional,
						moving to base 3.2
					</li>
					<li>
						Snippets View --&gt; internalProvisional. Belongs
						here in WTP. Needs more work to better integrate
						with Eclipse Templates (if possible)
					</li>
					<li>
						Extensible URI Resolver --&gt; 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 --&gt;
					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">
                &nbsp;
            </td><td valign="top"><h4>Server Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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 --&gt; moved to Eclipse 3.1.
					</li>
					<li>Pref. --&gt; 3.2</li>
					<li>
						Monitor --&gt; internal.provisional, pending post
						1.0 review with TPTP
					</li>
				</ul>
			</ul></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </td><td valign="top"><h4>Database Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>XML Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>Web Services Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>Web Resources Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>JST Server Subsystem/Feature</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>J2EE Web Subsystem/Feature (WAR)</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </td><td valign="top"><h4>
				J2EE Enterprise Subsystem/Feature (EARs, EJBJar,
				EJBClientJar, RARs)
			</h4></td></tr><tr><td align="right" valign="top">
                &nbsp;
            </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">
                &nbsp;
            </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>