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]
