| <html> |
| <head> |
| <META http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type"> |
| <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"></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> |
