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
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.
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.
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.
--
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]
