Hi Sebastien,

Nice write-up - thanks a lot for doing this.

I'm generally o.k. with these with a few caveats:

1. We'll need to scope because I think there is a lot more here than we can accomplish 2. As a pre-req to do this, I think we need to have the following in place. My view is that while we will be continually playing with the core architecture moving forward, we need to make some changes now to avoid some immediate problems. Things I would like to do in conjunction with this work:

- Transition to new context architecture and get rid of TuscanyModuleComponentContextImpl. Right now, we can't unit test a module context, separate out SDO or effectively implement management hooks and overrides for entry points/ external services. We also can't modularize very well any capabilities we may want to add to a runtime such as binding extensions, component extensions, etc. TuscanyModuleComponentContextImpl also contains a dependency on projects it should not (e.g. it depends on the Java builder but "cheats" by referring to the impl class with a String and performing newInstance()).

- Fix how proxying works. Right now the target and source proxies are not distinguished enough. This will effect what we can do with policies and overrides, particularly at the subsystem level.

Another way of phrasing the above is to say in addition to the "end- user oriented" goals you outlined, we need to have these architectural goals. I believe once we do this, the runtime will be dramatically simplified, we will be able to get rid of a lot of dead code, and it will be easier to attract people to work on the runtime and add extensions (e.g. new component types, transport bindings, policies, data binding, etc.).

I've already written a replacement for TuscanyModuleComponentContextImpl and checked it in with unit tests. I'm also working on the proxying. I'll check those in when I make progress that does not break the build. Unless there are any objections, I'm volunteering to do the work to meet that goal.

Jim




On Feb 1, 2006, at 12:51 PM, Jean-Sebastien Delfino wrote:

Hi,
I started to put together a list of items that I think we should support in our first SCA/Java Milestone. The idea is to establish reasonable goals in terms of function and timeframe. I also think that this will help people find areas where they can contribute, since this is pretty broad.
Core Module assembly model
- align implementation with a subset of SCA 0.9 (the implementation diverges from SCA 0.9 in some areas today)
- support for module and fragment SCDL
- support for componentType
- no multiplicity
- simple properties only, no complex properties
- support for both Java and WSDL interfaces
Subsystem assembly model
- support for subsystem SCDL
- ModuleComponents only no externalService and entryPoint at the subsystem level
- Support for wiring/specifying endpoints on externalServices
- Support for overriding properties of moduleComponents
- On Tomcat, subsystem maps to a Tomcat instance, moduleComponent maps to a Web app
- In J2SE, you can run a single moduleComponent
Client and implementation model
- align implementation with a subset of SCA 0.9
- support for SDO2 as well as regular Java objects - basic scope management (request, session, module)
- no metadata API
- no request context
- no session id
- no service references
- no conversational, no callbacks
Development Tools
- WSDL2Java and Java2WSDL generators
- XSD2SDO and Java2SDO generators
- both in the form of API and maven plugins
Bindings
- Web Service binding using AXIS 2 (SOAP/HTTP, doc literal only, support for streaming)
- Pluggable data-binding (start with regular Java objects and SDO)
- I think that we can live with just a WS binding for now and look at the default SCA binding later (maybe it'll just be a variation of the WS binding with some defaults anyway).
Extensibility
- Support contribution of a new binding (I'm thinking about a sample HTTP binding to illustrate that) - Support contribution of a new component type (Ant's sample Javascript component type)
Admin
- just doc or basic tools (maven plugin?) to install/uninstall a subsystem and module component - just doc or basic tools to start/stop a subsystem and module component - wiring, configuration of module component properties require editing SCDL file and bouncing the subsystem
- Simple monitoring/logging
Target environments
- JDK 5.0
- Tomcat
- J2SE
Samples
I think we need samples for most of the items in this list to illustrate how various user roles will use Tuscany (app. developer, assembler, deployer-admin, system-developer who wants to extend or integrate with Tuscany) and help drive all this work from concrete scenarios.

Any thoughts and ideas are welcome.

--
Jean-Sebastien


Reply via email to