| <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> |