On Jul 2, 2006, at 2:51 PM, Clemens Utschig - Utschig (Oracle) wrote:
Comments linline ...
Jim Marino wrote:
On 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:
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
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) obvious
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.
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=show
Hopefully you and others can add ones that are important to you
and we can work on implementing them.
+1
Great, thanks for volunteering :-) Seriously, we would welcome you to
add some scenarios to the Wiki and even help implement some.
From the scenarios we should derive technical
specifications, designs that implement those specifications, and
tests 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.
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)
test driven dev vs. scenario driven dev :-D
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.
On 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").
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.
That sounds reasonable. I usually point to this article for an
approach that works well in a distributed development environment:
http://martinfowler.com/articles/continuousIntegration.html
Also, 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 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
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.
---------------------------------------------------------------------
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]
