More comments inline... On Jul 2, 2006, at 2:02 PM, Simon Nash wrote:
I think it is o.k. for people to outline the scenarios that are important to them, and implement them if they want, regardless of whether they are "advanced" or "simple". I like the idea of people choosing to work on areas they are interested in and when the community is comfortable, we cut a release. I think this allows for a rapid release cycle and, more importantly, accommodates community diversity.My comments are inline below. Simon Jeremy Boynes wrote:Jean-Sebastien Delfino wrote: > 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.snip> 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?On 6/30/06, Kevin Williams <[EMAIL PROTECTED]> wrote:One the the things that came out at the BOF at ApacheConEU was that weSebastien,This sounds great to me. You may have intended this but, I think thatthe scenarios should be implemented as we go resulting in new unittests, 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 intactto be synchronized with the database. An inter-op scenario would be nice too.are not doing a good job of communicating what SCA is all about. I think having a bunch of scenarios like this will help us do that. Another thing that came out was that it would help if we broke the distribution down into smaller pieces - for example, making SCA, SDOand DAS available as individual releases rather than bundling them alltogether which gave users the false impression that they were all tightly coupled. I think we need a lot more information on each scenario though - at least to the level of detail Kevin provided. For example,> - a scenario building your average web app with SCAI'm not sure what "your average web app" is - are we talking JSP taglibs, working with a framework such as WebWork, or the integration with something like Spring? Are we talking about just accessing services, or both producing and consuming? Are we talking aboutaccessing a remote service or wiring local application components withSCA? Are we talking portable web app with Tuscany bundled, or how it works in an SCA-enabled container?I'd like to suggest we capture these on the wiki in enough detail thata user new to the project would be able to understand what we are talking about. The scenarios can then become illustrative samples of what SCA is about and how it can be realized with Tuscany.I don't want the scenarios to become the be-all and end-all though. Wetried that with M1 and IMO it failed miserably. We scrambled to implement features and ended up with a brittle codebase that cracked when we needed to make significant changes. Testing focused on seeing if a scenario worked and we ended up with poor coverage across the codebase. Instead I think we need to define additional, finer-grained scenarios that cover the components of the system. For example, different ones for SCA, SDO and DAS, and, digging deeper, different ones for web-services, Spring, static SDOs, non-relational DAS and so on. Basically, there are a lot of different scenarios for SDO on its own, we don't need to matrix them all into SCA, just pick a few key ones that help illustrate SCA concepts. At the most detailed level, the scenarios become the unit test cases for packages and individual classes.I think the purpose of scenarios is not to serve as tests, but to define required functionality in terms that are meaningful from a user perspective. From the scenarios we should derive technical specifications, designs that implement those specifications, and tests that validate that the implementations match the specifications.Some of the tests should validate high-level user-visible functionality("functional verification") and some should validate correct functioning of lower-level components according to their specified contracts ("unit tests"). So I see tests as different from scenarios. Some higher-level tests will look quite similar to elements of a scenario. Lower-level tests won't look like scenarios, but will exercise building blocks of functionality that are needed to make the scenarios work.Finally, I don't think we should define scenarios in the context of M2- we should define them in the context of what we want Tuscany to be. As we implement, at some point we can say that we think we have a useful, consistent set of features and then turn that into a release. When you combine this with the refactoring into smaller pieces that can be released separately, it will help build momentum for the project by showing continual progress.As Sebastien said, there is LOTS to do. This means it will take time to get all the way to what we want Tuscany to be. So I think it makes sense to stage the scenarios and not try to define right now every possible part of advanced functionality that we might like to see in Tuscany some day.
Some of the initial scenarios may end up in M2 and
I'm a bit worried that this will discourage people from working on something important to them because it is not slated for a predetermined milestone. For example, if someone wanted to work on a feature that was not part of some milestone, would they be allowed to check the feature into head? Again, I think we need to be flexible about "milestones" and releases.
Also, this process of deciding what "ends up" in a milestone may result in a "tyranny of the majority" (it's close to July 4th so I have to allude to de Tocqueville :-) ) where a really innovative feature is stifled because it does not fit into a set of release criteria determined by the many.
some may not, and they should cover a progression from known use cases that are needed to cover the basics, up to more advanced scenarios that show how SCA and Tuscany can handle more sophisticated requirements better than alternative technologies.
Maybe it would help move things forward if people just went ahead and added the scenarios that were important to them to the wiki page I started and we separate out the discussion of how we release to another thread since most people seem to agree that scenarios are useful?
-- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
