| 4/26/05 - this is just a preliminary rough draft |
| of some of my initial personal observations of |
| where we are architecturally at M4. |
| Updated based on review meetings held 5/3. |
| |
| |
| Architectural Observations at M4 |
| |
| State of plugin structure: |
| Overall, We still have too many plugins. |
| Many divisions still determined by "function" rather than component. |
| Many divisions still dtermined by "team" or "site" rather than component. |
| |
| 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). |
| |
| Many "validation" ones are separate ... is there a reason for this? |
| [AR] wsi command line validation is required. |
| [DW] but does this require seperate plugins? |
| |
| Many "annotation" ones are seperate ... is there a reason for this? |
| |
| Some need to renamed to make obvious "core vs. ui" |
| |
| need more grangular feature definitions needed -- |
| General agreement should be primarily from "end user point of view". |
| Should be based on subsystems, as defined below. |
| Still need to investigate model vs. UI packaging. |
| |
| |
| Need to set proper expectation and definition of "internal .provisional". |
| 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). |
| |
| 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. |
| |
| |
| We have no "friend" APIs defined for WTP. Friend meaning ok for some "outside" |
| component, but inside project to use. We could not not meaningful do |
| this for release 1. This is something we should do for future releases. |
| |
| Its important we get a better grasp of if we have |
| API violations in our use of base Eclipse and pre-reqs. |
| Its currently a fairly large "unknown". |
| 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.) |
| |
| |
| Below is Quick Summary of components and API status |
| |
| for those marked "ready for review" I will |
| open bugzilla meta-bugs to encourage comments |
| from community clients specifically during M5 |
| cycle review. |
| |
| Note: following "subsystem" don't match Arch. Doc. exactly, but |
| concept is the same. Features, dependancies, etc., still flow from the |
| subsystem definitions. |
| |
| |
| |
| Common Subsystem |
| |
| - Common Component |
| o Extensible Navigator --> internalProvisional, moving to base 3.2 |
| o Tabbed Property View --> internalProvisional, moving to base 3.2 |
| o Snippets View --> internalProvisional. Belongs here in WTP. Needs more work to better integrate with Eclipse Templates (if possible) |
| o Extensible URI Resolver --> internalProvisional. |
| Appears not to handle several use-cases, question is if it ever could. |
| Some question on OASIS standards. |
| |
| o common frameworks - ready for Review |
| dataoperations - IDataModel - proposed API |
| datawizards - provisional |
| [need review from Chris B., to see if he could move to it post release 1.0] |
| |
| - Validation Framework Component --> internalProvisional. Good client design sessions, but may be trying to cover to much |
| likely not to provide a base for the desired "common validation framework" that crosses several projects. |
| |
| - Command Framework Component --> |
| I don't think should be a "component". |
| I don't think it should have provisional API? |
| Could it be integrated with "DataOperations"? |
| The question is if "running headless eclipse" suffices, or |
| if we really need to provide an API that does not pre-req Eclipse. |
| |
| |
| |
| - common.componentcore (needed for flexible projects) - Ready for Review, 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 base is looking at "non-local resources" in 3.2 ... all of which could impact design. |
| especially need review from base to determine if evoleable with their plans |
| |
| |
| Server Subsystem |
| |
| - Server Component -- Ready for Review |
| some review already indicated some issues to resolve |
| especially with server providers |
| - Internet Component |
| browser/launch URL API -- moved to Eclipse 3.1. |
| Internet Pref. --> 3.2 |
| TCPIP Monitor --> internal.provisional, pending post 1.0 review with TPTP |
| |
| Database Subsystem |
| |
| - RDB/SQL - internal, not API due to probable DTP project merge |
| |
| XML Subsystem |
| |
| - XML Component - some internal provisional .. need better design documents .. more refactoring |
| - Schema Component - some internal provisional .. need better design documents .. more refactoring |
| - DTD Component some minimal internal provisional .. need better design documents .. more refactoring |
| - SSE Component some internal provisional .. need better design documents ... .. more refactoring, especially need better |
| distinction between language consumer APIs and language provider APIs. |
| |
| Web Services Subsystem |
| |
| - WS Component ... some internal provisional |
| - WSDL Component ... Ready For Review. WSDL Spec Model API (see "EMF Models" notes). |
| - WSI Component ... ? some API (provisional?) from WSTV project ? |
| |
| Web Resources Subsystem |
| |
| - HTML Component .. some internal provisional .. need better design documents |
| - CSS Component ... some internal provisional .. need better design documents |
| - JavaScript Component some minimal internal provisional .. need better design documents |
| - Web Project Component - no api, HTML Web Project |
| |
| |
| JST Project |
| Server Subsystem |
| |
| - Server Component - Ready For Review. |
| |
| J2EE Web Subsystem (WAR) |
| |
| - J2EE Core Web Model Component [Issue: not currently packaged this way] |
| - Servlet Component/J2EEWebProject ... some API, create web compentent API |
| - JSP Component ... some internal provisional .. need better design documents |
| - WS Web Component (JAXRPC) |
| |
| J2EE Enterprise Subsystem (EARs, EJBJar, EJBClientJar, RARs) |
| |
| - J2EE Core Enterprise Model Component [Issue: not currently packaged this way] |
| - J2EE Component .. .Ready For Review: J2EE Spec Model API (see "EMF Models" notes). |
| - EJB Component |
| - WS Component |
| |
| |
| |
| |
| "EMF Models" notes |
| J2EE and WSDL have expressed the primary API part of their models is |
| intended to be the interfaces defined by respecitve specifications. |
| But general consensus in 5/3 review meeting that its "ok to assume EMF model" |
| is part of the API. |
| |
| |
| |
| |
| |
| |
| |