Jim, To date I have been playing around with the system and just trying to come up to speed. When I saw this list from Jean-Sebastien I took it literally and I thought I might be able to ramp up in a more constructive way. Since I don't fully understand the architecture/design, I don't believe my thoughts on priorities have much credence. In any case, I will let you know if something really jumps out at me.
Lance On 2/8/06, Jim Marino <[EMAIL PROTECTED]> wrote: > > Hi Lance, > > No work yet done on the scoping (the work, not SCA "scopes" ;-) ). > What are your thoughts on priorities and items you would like to work > on? > > Jim > > > On Feb 8, 2006, at 9:11 AM, Lance Waterman wrote: > > > 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 > >>> > >>> > >> > >> > > > >
