Sebastien,
This sounds great to me. You may have intended this but, I think that
the scenarios should be implemented as we go resulting in new unit
tests, samples or sample apps by the time we are ready to release M2.
Also, I propose a scenario that involves data access and the transfer of
a data graph between modules. A source module would get the graph using
the DAS and pass it to a worker module. The graph would be modified by
the worker and sent back to the source module with change history intact
to be synchronized with the database.
An inter-op scenario would be nice too.
Thanks,
--Kevin
Jean-Sebastien Delfino wrote:
I have used the last two weeks studying our current code streams (M1 and
sandbox) and the evolving SCA specification.
During this exercise, I have realized that we have a LOT to do in
order to
reach the level of function that supports the spec, as well as implement
additional interesting ideas that have been discussed on the mailing
list.
This can only be achieved if we have our community engaged actively.
I would like to propose the following approach to help us achieve that.
1. Use scenarios to drive the M2 work
Start a community discussion on the end to end scenarios that we want to
support in M2.
I'm thinking about concrete end to end scenarios that define the end user
experience and the overall story going from development, build,
package, deploy
to runtime and administration of an SCA application.
This exercise should help us realize the following:
- better understand what it means to build an application using the
new SCA
recursive composition model
- better understand the requirements, put them in perspective and
stage the
introduction of the relevant function in the runtime
- use these top level scenarios as a starting point to drill down into
more
detailed scenarios and the design of the runtime
- give the whole group common goals for M2, we build a runtime that
supports
the scenarios
- demonstrate the value of SCA to our users
Here are a few ideas of scenarios to initiate the discussion:
- a scenario building your average web app with SCA
- a scenario showing how to aggregate multiple services into new ones
- mediation and routing/exchange scenarios
- an application using publish/subscribe
- building a whole system of services on a network
- integration with an AJAX UI
- what else? any thoughts?
2. Stage the assembly of our M2 runtime.
I propose that we start a fresh stream for M2 and build the runtime
through
baby steps, in parallel with the scenario work. This will get our
community
members involved in building the runtime together and will lead to a
wider
knowledge base that makes it possible to quickly implement new
functionality
in the future. It will also build a community knowledge base that is
ready to
help new community members come on board quickly.
Here's a proposal for how to do this:
- design and develop M2 by bringing into this fresh stream the best
pieces
from the sandbox and M1, as well as new ideas emerging from community
discussions
- stage the introduction of functional chunks required to support our
scenarios
- at each step, focus on simplicity and approachability of the runtime
that we
produce (to allow more people to approach it and get involved).
Here are some themes that we could consider to initiate this effort
(not an
exhaustive list, and needs help):
- Modularity, building our runtime in a more modular way, with more
but simpler
modules, clean SPI modules with only interfaces, and decoupling the
core and
the Java component implementation type / container.
- A simpler metadata model (the recursive model is much simpler than
the 0.9
spec, this is a great opportunity for us to simplify our implementation)
- Better continuity and consistency between our metadata model and the
runtime
model
- Simpler SPIs, covering all aspects of the cycle (development, build,
deployment + install, runtime, admin etc.)
- Better continuity between the SCA component programming model and
the Tuscany
interceptor programming model
- The need for a special system component implementation type, or the
ability
to extend Tuscany with just regular components.
This is just an initial list, I'm sure we're going to come up with
many more
themes and areas of improvement :) I am looking forward to constructive
discussions, and hoping that this community effort will allow us to
come up
with a nice runtime platform to attack the work ahead of us.
Any thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
