ant elder wrote:
Here are some specific ideas to kick around:
1) how about calling business samples 'demos' and technology samples just
'samples'
Yes, +1
2) restructure the current samples folder to be something like:
samples
- demos
- bigbank
- petstore
- ...
- das
- ...
- sdo
- ...
- sca
- bindings
- jsonrpc
- ws
- ...
- componentTypes
- java
- javascript
+1 we should just rename componentTypes to containers to be consistent
with the rest of the runtime.
- ...
3) There should be a consistent set of samples within bindings,
componentTypes etc so its easy to copy things to create new samples and add
new function
4) samples are like functional tests so we should add a sample for every bit
of existing and new function
5) Fix the testing/tomcat stuff so all the samples doing functional testing
get run as part of a regular build
+1 to all of this. I would like to add a new sample showing the SCA
async PM, created JIRA issue 188 for this. I think we also need a simple
technology sample that shows wiring of two moduleComponents in a
subsystem. This is an important part of the SCA assembly programming
model and we have no sample showing this except bigbank.
The cpp subproject has different samples (Calculator instead of
HelloWorld), I think it would be good to show common samples across
languages, i.e. at least port HelloWorld to the cpp project, or port
Calculator to the java project. Longer term, most samples should exist
in both cpp and java forms.
In more detail:
Right now we have a samples folder which has things like the bigbank,
helloworld, javascript and various other stuff in it. The bigbank sample
shows a complete SCA application that does something useful and real world
like, the helloworld samples on the other hand are very simplistic and
really just help a developer getting started with SCA. I think Bigbank fits
into what you describe as business samples and the helloworld samples are
technology samples, but to make this clearer how about calling business
samples 'demos' and technology samples just 'samples'?
Samples to me could be a lot like functional tests, for every bit of new
function we add we should add a sample showing how to use it. Samples would
show just one bit of function so its obvious whats required without getting
confused by unrelated code and xml. I've started trying to use this approach
for the JavaScript samples:
http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/JavaScript/
If we go that way it has to be really easy to create a new sample, the
helloworld samples aren't so easy to copy but after a few different attempts
with the JavaScript ones its now relatively easy to just copy an existing
JavaScript sample to a new project and do a global edit to change the sample
number. The most difficult part is updating the readme.htm file with all the
ascii art directory structure pictures etc, I think its probably better to
use plain txt readme files with simple content for samples and only have
fancy html readme's for the demos (and gif's instead of ascii art?). Another
minor problem with the JavaScript ones is the name is javascript-sampleX but
it may be better to have sample-javascriptX so then all samples would get
grouped together in your IDE.
Another aspect is it should be easy and obvious what samples are required
when creating something new like a new componentType. Most componentTypes
are going to require similar samples like a helloworld component, injecting
properties and references, initialization and scoping etc. If we get a good
set of these for the Java componentType then when creating a new
componentType you can just copy all the Java ones and update as required and
its obvious what needs to get done. This probably all also applies for
bindings and maybe theres a set of samples required for Tuscany core
function as well (showing module fragments, subsystmes etc?). This way we'd
also end up with a consistent set of samples, so if you've learnt how to use
one componentType then picking up a new one the samples would be familiar.
This would also all work across the different language impls so Java, C++,
and PHP SCA impls could all have a similar set of samples.
Right now some of the binding functional testing is done with existing
samples but these don't actually get run as part of the main build so they
do get broken. If the functional testing is going to be done in samples then
we need to sort out the testing/tomcat stuff so its easy to do and so the
samples get properly run as part of the regular build process.
I think samples should expand on each other, for example they'd be a basic
helloworld componentType sample, then a WS entryPoint sample exposes
helloworld as a WS, then a WS-Security sample secures the WS entryPoint
sample. I think Demo's on the other hand should be complete and self
contained applications. There could be tutorials that show how each demo was
developed.
For the demos, we already have bigbank so we might as well keep it but it
needs to be made more obvious what it does and how to use it. Right now I
can't find any readme's or doc describing it, there used to be a pdf about
it, where's that gone (and from what I remember that was like a 40 page doc
which is way more than most people will have time to read)? Someone
mentioned petstore and I think that could be a worthwhile demo as well - its
so well known so people can grok whats going on without needing to read a 40
page document. I think I heard that the PHP SCA impl have their own demo app
which isn't bigbank, it may be worth looking at what they have and also
adding it as a demo for the Java impl. I think the demo documentation needs
to make clearer why SCA is a good thing, its not real obvious right now from
the existing doc why this is better than using something like J2EE or just
wiring up a bunch of POJOs with Spring.
It would be good to have some more cool technology demo's, but right now the
only function Tuscany supports is fairly mainstream. I think the E4X support
in JavaScript could make some interesting WS mediation samples, but the
function isn't quite there yet. The json-rpc/ajax stuff could be really cool
but its also not ready yet. Maybe as this first milestone release is
targeting getting new contributors rather than business users then just
sorting out the functional samples and cleaning up the bigbank demo would be
enough.
...ant
+1 unless somebody finds time to come up with, implement and document a
nice new business scenario demo (or enough time to implement PetStore...
but I'm not sure if PetStore is a good SOA sample and would illustrate
the capabilities of SCA/SDO better than Bigbank), for the May release we
should at least get bigbank working and well documented. Maybe the only
thing we can add to Bigbank is an Ajax front-end? What do people think?
Another question,
On 4/12/06, haleh mahbod < [EMAIL PROTECTED]> wrote:
Hi,
What are the categories of samples that we need to consider for Tuscany?
I see two potential categories.
1) Business samples - Focused on showing how Tuscany solves certain
business
problems.
2) Technology samples - Focused on showing developers how to use
Tuscanyfeatures such as Transaction.
Does this look right?
If yes, what are some good samples that we can consider for each category?
What should our approach to Samples be? Start with one sample and expand
it
to show additional functionality; or
create distinct samples?
Haleh
--
Jean-Sebastien
