One theme that came out of the recent project promotion thread was a
need to establish what our project structure should be. Part of that
also is the level of "support" between parts of that project structure.
I'd like to propose a strawman, not only of the structure but also of
the rules.
A project "core" that:
* is as small as possible with carefully controlled dependencies
* provides the fabric for the runtime (Contexts)
* provides APIs for providing plugin extensions
* provides SPIs for embedding in host environments
* can be built separately and used by extensions in binary form
(implying versioning and stability on the extension APIs)
* has a rule that incompatible changes to the API require the changer
to upgrade and test all extensions in the Tuscany project and with
a specific vote to accept them
Baseline services that are distributed with the core that:
* provide a deployment model for extensions (include loading,
context building, package handling (classpath))
* provide critical system services (monitoring, admin enablement)
* provide system services needed to support baseline extensions
(security provider, transaction manager, work manager, ...)
* has the same rule on API changes for those services as the core
Baseline extensions that are distributed with the core:
* programming models that are part of the specification
(currently Java, futures being C++, Spring, J2EE, BPEL, ...)
* transport bindings that are part of the specification
(currently WS, futures being JMS, ...)
* data bindings that are part of the specification
(currently SDO, futures being JAXB, ...)
* policy handlers that are part of the specification
(futures being Security, Transaction, ...)
Optional services that can be used to extend the runtime:
* programming models that are not part of the specification
(currently JavaScript, future being PHP, ???)
* transport bindings that are not part of the specification
(currently JSON-RPC, future being ???)
* data bindings that are not part of the specification
(currently JSON, future being ???)
* services for use by applications
(database access, DAS implementations, directory access, ...)
* these would be released separately and could be deployed
to a host environment by a user
Host integrations that provide installable distributions:
* provide implementations of the core's SPIs that allow
Tuscany to run in different environments.
(currently J2SE, J2EE WAR and Tomcat,
future being full J2EE, Geronimo, OSGi(Eclipse), ...)
* provide installable distributions that include all the
baseline compoments applicable to that environment
* provide "extended" distributions tailored to different
user communities that include selected optional services
Sample and demo applications that:
* show key concepts from the SCA programming model
(currently helloworld)
* show how to build a large scale application
(currently bigbank)
* show how to use Tuscany in different environments
Testing
* compliance test for the specification (when available)
* pre-release tests for Tuscany
* ALL modules above should test their own functionality
(at both the unit and integration levels) as part of their
own build. No manual setup should be required.
Given that, I would suggest the following changes to the project layout:
sca/
# "core" system
sca/system/common
sca/system/model
sca/system/core
# "baseline" services and extensions
sca/baseline/service/monitor
sca/baseline/service/security
sca/baseline/service/transaction
sca/baseline/service/work
sca/baseline/container/java
sca/baseline/transport/axis2
sca/baseline/data/sdo
sca/baseline/policy/security
# "optional" services and extensions
sca/extension/container/rhino
sca/extension/transport/jsonrpc
sca/extension/data/json
sca/extension/service/jndi
sca/extension/service/jdbc
# host environment integration
sca/host/tomcat/runtime # integration code
sca/host/tomcat/testing # integration testing
sca/host/tomcat/win32 # packaging for release
sca/host/j2se/runtime # etc...
# samples and testing modules that are not part of a developer build
sca/samples/helloworld/j2se
sca/samples/helloworld/war
sca/samples/bigbank
sca/testing/compliance
Thoughts?
--
Jeremy
