Jeremy mentioned: >In J2EE days the business samples were called "blueprints" so perhaps we >could call them that as well - would be a natural place for a petstore :-)
Here is another alternative: a) *Scenarios* – Demonstrate how Tuscany addresses real business problems. For example we can have scenarios that show how Tuscany solves the following business problems: · The ability to take advantage of existing business investments (services) to address new business needs by building composite solutions · The ability to dynamically handle changes in business environment through properties · The ability to address changes in business requirements through mediation · What else? Scenarios also are good end to end or horizontal test for Tuscany that should work when we release. BigBank is an example. What else we can add? b) *Samples* – These are *examples* that demonstrate how to use Tuscanyfeatures · JavaScript samples · Binding samples · What else? Samples could be part of functional testing of features and be part of automated unit test. Does this sound OK? On 4/13/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Jim Marino wrote: > > On the BigBank issue, I don't think we should replace that sample as > > the spec group will continue to evolve it and I believe it is useful > > to have the spec define a standard sample app. For people that have > > not participated in the spec work, it is recognized that the existing > > version does not really show all of the benefits of SCA. We actually > > had a more complicated version demonstrating conversations and async > > that was not published due to time constraints. I fully expect this to > > be evolved to the point where it demonstrates more fully SCA > > benefits. If it doesn't, I think we should influence the spec group > > so that it does. > > > > Jim > > > +1 from me, we should get the BigBank scenario working as described in > the "Building your first SCA application" document that was published > with the spec. We still have a few shortcuts in our implementation of > BigBank to work around some limitations of our runtime. I am going to > create JIRA issues for the differences that I see. Jim, do you by any > chance know how the complete - I'm going to avoid the term complicated > here :) - version of BigBank was going to use async? Working on async > now so I'm interested to see how/if BigBank could be improved to make > use of it... > > > > On Apr 13, 2006, at 9:56 AM, rick rineholt wrote: > > > >> > >> > >> ant elder wrote: > >> > >>> Here are some specific ideas to kick around: > >>> > >>> 1) how about calling business samples 'demos' and > >>> > >> technology samples just > >> > >>> 'samples' > >>> > >>> 2) restructure the current samples folder to be > >>> > >> something like: > >> > >>> samples > >>> - demos > >>> - bigbank > >>> - petstore > >>> - ... > >>> - das > >>> - ... > >>> - sdo > >>> - ... > >>> - sca > >>> - bindings > >>> - jsonrpc > >>> - ws > >>> - ... > >>> - componentTypes > >>> - java > >>> - javascript > >>> - ... > >>> > >>> 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 > >>> > >> Many of the samples require tomcat and despite the the > >> mock functional testing I > >> still believe we'll see these samples/demos break. So > >> by this proposal are we > >> going to remove the end user aspect that these tests > >> did? Testing as close to a > >> user environment as possible and still remain > >> automated? If the answer is to > >> remove then will we be doing this manually? > >> > >>> > >>> 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. > >>> > >> Just so I understand can you please elaborate on what > >> was changed that made the > >> Javascript examples so much easier to copy and reuses > >> over the helloworld.. Thanks. > >> > >> > >>> 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?). > >> Creating gifs and maintaining them seems more > >> difficult the ascii art and there > >> is no mandate that any particular samples have that. > >> I didn't see this as an issue. The ideas was to get > >> the use familiar with > >> samples layout. I thought this was good for some of > >> the first samples that > >> show where your sca files are located etc. There is > >> no requirement that every > >> "sample" do that. > >> > >>> 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. > >>> > >> I think java helloworld are grouped. > >> > >>> > >>> 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. > >>> > >> That's one of the reasons helloworld samples are there > >> for. > >> > >>> 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. > >> Not sure where to go here. I see both sides people > >> don't want to run that with > >> every build. Ideally it would all run in a nightly > >> build. I haven't had much > >> luck with getting that in place. The apache > >> infrastructure "GUMP' doesn't seem > >> to support maven 2.0 builds. > >> > >>> > >>> 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. > >>> > >> Once again I think I see that in helloword. And from > >> the the main readme > >> if you follow down you'll basically get that there is > >> a plain J2see. There are > >> some axis samples that were there to show integration > >> with a plain axis > >> client/service at one time that was considered > >> important. There is a sample > >> using helloworld as in a web application ... we once > >> deemed that as important to > >> show too. There is a helloworld showing using an > >> entrypoint and an externalservice. > >> > >>> 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. > >>> > >> Basically I agree. Bigbank does have a tutorial it's > >> under documentation > >> "SCA: "Building your first application" And yes the > >> main readme and a readme in > >> the the directory of bigbank should point or this > >> tutorial Or should it be > >> actually be relocated to the demo? > >> Also it may be slightly out of date since it was first > >> written some things in > >> the technology has changed. > >> > >>> > >>> 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)? > >> Yes it is long. But if you want the details ? > >> > >>> 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. > >>> > >> Petstore, PHP Flashy demos etc Will some people may > >> become confused with all > >> the samples and demos? > >> Assuming all the resources to do all this will people > >> need a 40 page document > >> for a roadmap of the demos and samples? > >> > >>> 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. > >>> > >> OK lets find out what that is and either incorporate > >> into bigbank or get rid of > >> bigbank for something that does this better. > >> > >>> > >>> 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 > >>> > >> Personally I'm not for cool and flashy here in OS. > >> Let give reason for why this > >> technology is needed and how to use it. Let's not > >> drape flash(cool) over it for > >> the sake of "FLASH" or that we can't really show the > >> latter. > >> > >>> > >>> 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 > >>>> > >>>> > >>>> > >>> > >>> > >> > >> __________________________________________________ > >> Do You Yahoo!? > >> Tired of spam? Yahoo! Mail has the best spam protection around > >> http://mail.yahoo.com > >> > > > > > > > -- > Jean-Sebastien > >
