I'd like to help out with Jean-Sebastien's list however, Jim seems to indicate that a scoping effort should take place first. Is the scoping effort currently under way? Jean-Sebastien also mentions a Tuscany/Java milestone, is there something posted on http://incubator.apache.org/tuscany/index.html that speaks to milestones?
Lance On 2/3/06, Jim Marino <[EMAIL PROTECTED]> wrote: > > 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 > > > >
