helloworld via tuscany ... am I missing something?
Jim Marino wrote:
On Jul 2, 2006, at 2:51 PM, Clemens Utschig - Utschig (Oracle) wrote:Comments linline ... Jim Marino wrote:at the end it comes down to people seing the benefits (and these are not just core engineers) - so step by step tutorials, and I know this is a damn amount of work usually helps for attracting and more over making the concepts (that should be communicated) obviousOn Jul 2, 2006, at 2:02 PM, Simon Nash wrote: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 JSPtaglibs, working with a framework such as WebWork, or the integrationwith 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 crackedwhen we needed to make significant changes. Testing focused on seeingif a scenario worked and we ended up with poor coverage across the codebase.Instead I think we need to define additional, finer-grained scenariosthat 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.There seems to be a range there as well. For example, "users" vary from end-user application developers to systems extenders. I also think scenarios may not involve users directly at all in some cases, instead defining some kind of execution flow through the runtime.I've just added a scenarios page to the WIKI with some things that are important to me at:http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios?action=showHopefully you and others can add ones that are important to you and we can work on implementing them.+1Great, thanks for volunteering :-) Seriously, we would welcome you to add some scenarios to the Wiki and even help implement some.I'm pretty sure most people think "scenarios" are a valuable way to do development. I don't think they are sufficient though but that's another topic. More on topic, I also don't think this is a binary choice between test driven and "scenario" driven development. For example, many agilists start with scenarios (they may call them other things) and then proceed to TDD.the point on the story is the outcome - attracting developers is definetely important, nevertheless the outcome and success will be measured on people using it .. the easier common scenarios are - the better :-) (so taking base scenarios as dev line might be a good idea, and yes it's more work)From the scenarios we should derive technical specifications, designs that implement those specifications, andtests that validate that the implementations match the specifications.This seems a bit heavy-weight for an open source project. Are you suggesting we need to have a process where people provide functional and technical specifications? Not to be alarmist but if we required this, I think we will find it difficult to attract developers.test driven dev vs. scenario driven dev :-DOn TDD, I think it is a matter of personal choice; sometimes I find it useful to write a test case prior to coding the implementation while other times I find it constraining. Either way, it's up to individuals to decide what best suits them.Overall I take a similar approach to scenarios as I do TDD: sometimes it's great, other times it makes more sense just to write tests and code. If people want to start with scenarios, good, if people don't, that's fine with me too.This does not interfere with attracting developers at all, one this the outcome from usability point of view the other is "core feature dev"I think we're in agreement about the value of scenarios. My question to Simon was whether he felt we should *require* the functional/ technical specification cycle commonly associated with some commercial software development processes. My opinion is if someone wants to write those things, it may be helpful but we shouldn't require it.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").That sounds reasonable. I usually point to this article for an approach that works well in a distributed development environment: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.http://martinfowler.com/articles/continuousIntegration.htmlAlso, in core2 we have spent quite a bit of time introducing the use of JMock to provide very granular unit testing. While test coverage is still limited (around 50-60% overall, 300 or so tests) and we need to do much better, it may be worth perusing some of the unit tests to see if they fit your view of "low- level" tests (higher-level testing IMO should be done through an integration build as described in the Fowler article).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 auseful, 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 timeto get all the way to what we want Tuscany to be. So I think it makessense 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 andsome may not, and they should cover a progression from known use casesthat 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.--------------------------------------------------------------------- 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]
