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:
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.
One the the things that came out at the BOF at ApacheConEU was that we 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, SDO and DAS available as individual releases rather than bundling them all together 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 SCA
I'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 about accessing a remote service or wiring local application components with SCA? 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 that a 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. We tried 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. 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. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
