Re: Sample framework

[Jim Marino]

I think there are a couple issues here which would benefit by  
stepping through what we expect users to actually be doing. From a  
user standpoint, I imagine most people will have the following goals:

1. Figure out how to write an SCA application
2. Figure out how to deploy the application
3. Run the application
Starting with 3 in a server environment does not really do anything.  
For example, I start something up and hit a web page, but can't  
really debug or step through without setting a project up in my IDE.   
What I think most users want is a quick way (i.e 5 minutes) to do the  
following:

1. Download a sample that has an automated way to create a dev project
2. Build the sample and deploy it to whatever host environment I  
typically do my development with. For example, for web app  
development, I prefer Jetty since it is light, fast, and easily  
embedded. Others may prefer Resin, Websphere, WebLogic, etc. As I  
mention below, however, I don't think most Tuscany development will  
be done inside a web app.
3. Run the sample and debug it (either remotely or in my IDE) so I  
can see what is happening
4. Make changes to the sample and goto step 2

The most time-consuming parts I have found in using new technologies  
is getting my dev environment setup properly. For example, with a  
binary distro, here is what I would have to go through:

1. Download the binary distro, including a pile of dependencies  
probably totaling over 200MB
2. Unzip the distro, follow the readme instructions to start the thing
3. Use a browser to hit a web page that prints something out

At this point, I still can't really see what is going on much less do  
things like changing bindings, adding policy, swapping implementation  
types, etc. If I want to use really understand how SCA and Tuscany  
work, I would have to:

4. Download the source sample, maybe it is included in 1 but maybe not
5. Setup my dev environment with a sample project
6. Build the sample and package it
7. Figure out whether I want to deal with Tomcat the version of  
Tomcat my Tuscany download just came with. Probably not, since I  
already have a Tomcat install or use something else.
8. Make any necessary changes to my dev environment so I can debug  
the sample as it is run
9. Deploy the sample to the host I do my development with

IMO what would be much simpler for end users would be to:

1. Download a sample distro
2. Build it with maven, which can generate the IDE project for me as  
well as deployment artifacts for whatever host type I choose, e.g. a  
WAR file
3. Set my IDE to use the source from the sample I just downloaded
4. Decide where I want to deploy it to. If it is a WAR, I just drop  
it in and either run it from within my IDE and debug or attach to a  
remote process

I think it would be useful to look at projects that have been highly  
successful (i.e. one of the most widely used Java projects) and see  
how they do things, Spring and Hibernate. Both do not ship a pre- 
configured host environment.

As a further thing to think about, I expect most SCA users will *not*  
be developing with or deploying to Tomcat and will probably instead  
use the standalone version. This is for a number of reasons:

1. The J2EE deployment model restricts some of the most important  
features implicit in SCA
2. Related to #1, most of the capabilities people really to want to  
see involve things like transactions and policy, dynamic re-wiring,  
etc. which are not directly supported in Tomcat. This will mean  
either having to configure Tomcat with a transaction manager or  
bundling one in the web application. Standalone can handle this  
dynamically. Consequently, I suspect the user experience will be more  
difficult on Tomcat. I also don't think most are going to be  
interested in "helloworld" variants as that can be done more easily  
with existing technologies.
3. With dependency injection,  there is no need to develop within a  
container - just use mocks. When I build apps, I typically don't get  
them running in a host environment until integration testing.

Jim



On Aug 18, 2006, at 7:26 AM, Rick wrote:

+1 for both .. does that make 2? :-)
I like the idea of having the bar a low as possible for someone to  
just start playing with samples to learn building SCA applications.
But I also see Jim's point.  There are other set of users (IT  
types) that may not even care about Tomcat and we definitely need  
to please them too.
I think the trick here is to for the site documentation about what  
download to to satisfy your particular interests  is very important  
and we make perfectly clear that Tuscany is not just a Tomcat/ 
webserver extension.
Luciano Resende wrote:
+1 for what Jervis, Ant and Simon are saying... I really liked the
pre-configured Tomcat  installations available for the samples in  
M1, made
my life much easier to get started in Tuscany. I have also  
recently created
that for DAS samples and it's available today at samples/das/ 
testing/tomcat

- Luciano

On 8/18/06, Simon Laws <[EMAIL PROTECTED]> wrote:

On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote:
>
> There are quite a few old threads where we've discussed  
samples, here's
> just
> one of them:
>
>
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/ 
200604.mbox/% 
[EMAIL PROTECTED]
>
> If we're moving towards multiple Tuscany distributions targeted at
> different
> areas then i think its fine (and even desirable) for one of those
> distributions to contain an entire host environment. One of the  
good
> things
> about the M1 release was that it really did make it easy for  
new users
to
> get started, just "unzip and click on startup".
>
>    ...ant
>
> On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Aug 17, 2006, at 11:21 PM, ant elder wrote:
> >
> > > I agree with Jervis, things just running out-of-box is much  
nicer
> > > for first
> > > time users than having to fiddle about editing config files.
> > >
> > > Would an alternative be to change the structure of the  
samples and
> > > move
> > > these technology specific samples into the extension that  
they use.
> > > For
> > > example, something like having a javascript folder that  
contained
> > > separate
> > > projects for the JavaScript container and each JavaScript  
sample.
> > > There
> > > would still be lots of helloworld samples, but not all in  
the one
> > > top level
> > > samples folder so wouldn't be quite so in your face.
> > I like the idea of moving the samples into the extensions  
(except
> > maybe the samples that use multiple extensions) and actually  
think it
> > could correspond to Jeremy's proposal. This would allow us to
> > compartmentalize things more which I think is going to be  
fundamental
> > to scaling the project. I have several caveats for this though:
> >
> > - there is a clear distinction in the tree between the  
samples and
> > runtime extension code. In other words, each sample project  
should
> > not be a sibling to the project containing extension code but  
should
> > go under a samples folder in separate projects
> > - the extensions are individually built from the core  
projects and
> > fairly autonomous per my previous email
> > - samples are not built with the check-in build for  
extensions and
> > are separately distributable
> >
> > In terms of end-user experience, I think things are going to  
vary
> > greatly depending on the host environment. For example, in our
> > standalone environment, things can be automated fairly easily:
> >
> > 1. User downloads core distribution
> > 2. User downloads and drops in sample distribution and starts  
the
> > standalone core
> > 3. Core reads the dependencies from the sample SCDL and pulls  
down
> > the required extensions via the ArtifactFactory from a Maven
> > repository. This would resolve the transitive closure of all
> > extension dependencies. This would allow us to track  
dependencies for
> > extension libraries such as Spring for "free" since most  
projects
> > publish POMs to a Maven repo.
> > 4. If user chooses, they could avoid step 4 and just download  
the
> > extension and plug it in
> >
> > Something similar to the above could be done for OSGi except  
the end
> > user would just deploy a core bundle into an existing OSGi  
host such
> > as Equinox they had installed.
> >
> > If we are deploying to a servlet container, things will  
likely be
> > more complex but not too much:
> >
> > 1. User downloads sample application and builds it using  
Maven, which
> > retrieves the core as a dependency and bundles everything  
into a war.
> > 2 User deploys the sample war
> >
> > If we "prepackaged" every sample distribution so it could  
just be
> > dropped in, I think we will wind up with a ton of packaging  
problems
> > as core will need to be included in every one.
> >
> > I'm pretty firmly against distributions containing an entire  
host
> > environment, such as Tomcat. I'd prefer we follow projects like
> > Spring, Struts, WebWork, Hibernate (take your pick) and provide
> > distributions which are simple to deploy into containers  
using some
> > minimal configuration steps. My reason for this is partly  
practical.
> > First, we should support deploying on a variety of host  
environments
> > and having to rev versions would be a nightmare. Second, in  
most data
> > centers I have come across, there is a standard image  
technologies
> > must accommodate and they will not accept an "bundle of stuff".
> >
> >
> > Jim
> >
> > >
> > >   ...ant
> > >
> > > On 8/17/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> > >>
> > >> One thing concerns me would be the out-of-box user  
experience. For
> > >> a first
> > >> time Tuscany user, don't you think it is more user  
friendly if
> > >> users only
> > >> need to follow the readme, go to a directory, run a  
common, then
> > >> everything
> > >> works out-of-box? Speaking in my experience, it does  
encourage me
> > >> to explore
> > >> a new product further if I can set up and run a typical  
helloworld
> > >> sample
> > >> successfully in 5 minutes without any coding. Well, maybe  
just me
> > >> being too
> > >> lazy... ;-)
> > >>
> > >> Cheers,
> > >> Jervis
> > >>
> > >> > -----Original Message-----
> > >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> > >> > Sent: Thursday, August 17, 2006 6:54 AM
> > >> > To: tuscany-dev@ws.apache.org
> > >> > Subject: Sample framework
> > >> >
> > >> >
> > >> > We have had a rapid increase in the number of samples  
recently
many
> > >> > of which do essentially the same thing. Some feedback  
from M1
also
> > >> > said that we seemed to have invented the greatest number of
> > >> > varieties
> > >> > of HelloWorld but that it was hard to tell if SCA could do
anything
> > >> > else. I'd like to propose a change in how we structure the
> > >> > samples so
> > >> > that we make it clearer to illustrate the technology to  
users.
> > >> >
> > >> > Rather than having separate projects for each technology
> > >> > variant, I'd
> > >> > like to suggest we have just a couple of projects that  
provide a
> > >> > framework and then have instructions in the  
documentation for
each
> > >> > technology that clearly show how to apply it.
> > >> >
> > >> > For example, I can see two framework environments:
> > >> > a) a client environment with a simple command line  
client wires
> > >> > together a couple of local components
> > >> > b) a webapp environment with a simple JSP client that  
also wires
> > >> > together a couple of local components
> > >> >
> > >> > Then, for example, the JavaScript extension could say:
> > >> >    To illustrate the use of JavaScript as a component,  
take the
> > >> > client a) and
> > >> >    1) replace <implementation.java class="Foo"/> with
> > >> > <implementation.javascript script=" foo.js"/>
> > >> >    2) Install javascript extension
> > >> >    2) rebuild/run sample
> > >> >
> > >> > Or, to illustrate the WebService binding:
> > >> > Server
> > >> >    1) Take webapp and add <service>< binding.ws ...>
> > >> >    2) Install Axis binding extension
> > >> >    3) Deploy server app to Tomcat
> > >> > Client
> > >> >    1) Take client application and replace <component
> > >> name="foo" ...>
> > >> > with <reference><binding.ws ...>
> > >> >    2) Install Axis binding extension
> > >> >    3) Run client
> > >> >
> > >> > The basic idea being, have a common framework and the
> > >> > instructions on
> > >> > how to use the particular extension.
> > >> > --
> > >> > Jeremy
> > >> >
> > >> >
> > >>
-------------------------------------------------------------------- 
-
> > >> > To unsubscribe, e-mail: tuscany-dev- 
[EMAIL PROTECTED]
> > >> > For additional commands, e-mail: tuscany-dev- 
[EMAIL PROTECTED]
> > >> >
> > >> >
> > >>
> > >>
-------------------------------------------------------------------- 
-
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: tuscany-dev- 
[EMAIL PROTECTED]
> > >>
> > >>
> >
> >
> >  
-------------------------------------------------------------------- 
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >



I agree with Ant. As primarily a user (in the sense that I wanted to
understand it and try the samples) of the Java M1 release the  
presence of
the pre-configured Tomcat installation was really handy for quickly
running
through the samples and getting a feel for what it was all about.  
As you
are
constructing a build and distribution system/approach that allows  
you to
cut
different distros to suit different requirements for hosting or  
embedding
can you make a standalone samples distro for the interested  
newbie. No
suggestion that this distro would get deployed into production or  
used
other
than to get familiar with the technology or bootstrap a development
environment? This doesn't suit the hardcore techy who just wants the
latest
release of the components they are going to refresh into their hand
crafted
development/test/deployment environment but then they would go  
and get one
of the other distros.

Regards

Simon






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