You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2006/08/19 20:12:34 UTC
DAS vs. O/R tools, was: Sample framework
On Aug 18, 2006, at 10:07 PM, Robbie Minshall wrote:
> Jim I agree with you on all of your points.
>
> Perhaps saying exec types is a stretch but I do believe that there
> are clear
> benefits to the ease of an embedded execution env such as tomcat.
> I am not
> sure if this benefit is justified but people have seemed to like it
> and is
> nice if it avoids the need to set up a DB and configure jdbc
> resources on
> tomcat.
I should say I only speak for Java SCA but in terms of a DB, can't
this be done with an embedded DB inside the web app? I've used http://
www.hsqldb.org/ and found it great as they have an in-memory mode.
This would eliminate the need to touch Tomcat config and would work
in any Servlet container.
>
> As someone whom uses, and likes HIbernate very much I do not see much
> benefit in it but the RDB DAS is an alternative/competitor to
> Hibernate. It
> is important to understand and provide guidance to users on their
> roles and
> when and how to use which persistence mechanism ( currently I
> believe that
> this is not as clear and the confusion will be a bad thing ).
I agree it's not clear. I think it would be unfortunate to position
RDB DAS as a competitor to Hibernate and similar technologies rather
than try to extend them. From a practical perspective, I believe it
will hurt Tuscany gaining traction as those tools are some of the
most popular in the Java space. I also think they serve a very
important role in service-oriented development that shouldn't go away.
FWIW, I'm a pretty strong proponent of O/R technologies (for the
right use-cases) and sit outside of DAS development, being only
involved in SCA. Coming at it from that perspective, my observation
(and I suspect other Java developers) would be:
1. For management of strongly typed relational data in a service
implementation, Hibernate, JPA, and JDO are good technologies. If
someone wants to use a different approach such as iBatis or JDBC
those are fine too. I'm not sure of the value of introducing
additional change tracking, etc. to what those tools already provide
for disconnected "local data". Also, they offer important programming
model additions such as the preservation of object identity, lazy
fetching, etc.
2. For data that needs to be made "remote", SDO/DAS could add a ton
of value to these existing technologies by providing the ability to
flow the data to clients (e.g. Java, Javascript/Web2.0, .NET, etc.).
3. A DAS implementation that could access heterogeneous data would be
valuable. I could see this as extending O/R tools.
>
> Anyhow, your points are valid though our views may be different and
> I agree
> that adopting the successful techniques used by open source is a good
> thing. Essentially the thing I care most about is that samples are
> accompanied by dev, deployment, execution tutorial style doc and am
> happy to
> help in this regard.
>
That would be great. I think it would be particularly helpful to have
someone who has not worked on the SCA runtime contribute to this
since some of us are too close to the technology. If you are tied up
with DAS stuff, then hopefully we could get you to eyeball what we
wind up with?
Jim
> Robbie
>
>
>
>
>
>
> On 8/19/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> On Aug 18, 2006, at 6:10 PM, Robbie Minshall wrote:
>>
>> > Regarding whether or not to embed tomcat with the muscle car
>> > application
>> > . . . it is definately just going to come down to a preference
>> > issue for
>> > ease of deployment vrs an idealistic build env ( are we teaching
>> > people to
>> > deploy, or are we providing an easy avenue for one to showcase SOA
>> > using SCA
>> > & SDO - that is the nuts and bolts of the difference here ).
>>
>> I have the feeling I my previous post didn't explain well...I don't
>> think we are trying to teach someone how to deploy a war or some type
>> of archive. I think the goal of the samples should be to teach a
>> fairly skilled developer how to write applications for the SCA Java
>> runtime.
>>
>> In order to teach a developer how to use Java Tuscany, they need to
>> have the sample source and an easy to use build environment. Just
>> deploying a binary to a server and watching it run isn't really
>> helpful. If we take some of the more popular frameworks as guides,
>> the samples they come with are distributed as source with a build
>> environment and a minimal bootstrap (in the case of Hibernate), if
>> anything at all. To take a few:
>>
>> http://caveatemptor.hibernate.org/2.html
>> http://www.springframework.org
>> http://ibatis.apache.org
>>
>> We can structure the sample build to resolve dependencies through
>> maven and not have to manage those as part of a distribution.
>> Moreover, the build can include multiple goals for different target
>> hosts. Deploying to something like Tomcat or a Servlet engine would
>> be a simple process of doing something like:
>>
>> 1. Download the sample tar, unzip it
>> 2. Run mvn war
>> 3. cp <war file> <tomcat deploy dir> (or just run the standalone
>> Tuscany version)
>>
>> To set up a build environment with all dependencies:
>>
>> 4. mvn idea:idea (or mvn eclipse:eclipse)
>> 5. Add the project created in step 4
>>
>> To create a full debug environment:
>>
>> 6. Download the tuscany core and extension source tars
>> 7. Attach source to the project dependencies in the IDE
>>
>>
>> > My view is
>> > that the working tutorials should be educational and the killer app
>> > should
>> > be distributed in a manner that is easy for exec/manager types as
>> > well as
>> > developers to get going right off the bat
>> Hmm, I would say our primary audiences (in order of importance are):
>> systems developers who want to contribute to Tuscany; and
>> applications developers who want to use it. I think it is a bit of a
>> stretch to say execs/managers would bother to download Tuscany.
>>
>> I agree though it is important to get developers up an running as
>> quickly as possible with something useful. Given this, do you think
>> the steps I outlined above are too difficult for a developer to do,
>> particularly the "average" developer who uses open source (who is
>> really above average and used to tinkering with things)?
>>
>>
>> > - though I definately see the
>> > other side of this argument.
>> >
>> >
>> > Regarding the 'sending the message that people should use SDO/DAS
>> > instead of O/R technologies such as Hibernate, EJB3, or JDO. How
>> > about showing how they are complimentary'
>> > . . . the issue here is that the role and benefits of SDO/RDB
>> DAS is
>> > somewhat grey at the present moment. It is clear that providing a
>> > good
>> > document show casing the expansion of existing applications using
>> > Hibernate
>> > and a POJO model into a service orientated SCA land using the SDO
>> > functionality across services is key - this is the complimentary
>> > part and I
>> > could not possibly agree more ( why Kapel and I are playing with a
>> > Hibernate
>> > DAS ).
>> This would be really cool, for example allowing Hibernate graphs to
>> be sent to a client. The OpenJPA people also expressed interest in
>> this and I'd be happy to introduce you to some of them if you are
>> interested.
>>
>> > . . . it is also very important for us to have a competitive
>> > picture and
>> > story regarding using the RDB DAS for persistence rather than
>> > solutions such
>> > as Hibernate/EJB3 etc - this is not so simple and would involve
>> best
>> > practices regarding the various performance aspects and the
>> > disconnected
>> > graph vrs connected model.
>> >
>> This is my own opinion (I mostly like Hibernate even though it has a
>> few quirks) but I really don't think we want to position SDO/DAS as
>> competitive to JPA or Hibernate. We would gain more traction if we
>> worked with popular O/R tools such as Hibernate as instead of
>> attempting to replace them.
>>
>> > The samples should address two perspectives: How do I best
>> migrate my
>> > application using existing technologies into a SOA application ; If
>> > I am
>> > starting from scratch what is the most common, and therefore the
>> most
>> > supported technique for model, persistence and exposure.
>> >
>> I'm not sure about SDO but one of the key themes of the SCA
>> collaboration is that SCA can use *existing* technologies and it does
>> not force people to re-write their applications. Of course it's not
>> magic and people need to architect things in a service-oriented way
>> to do this, but the key point is the amount of re-writing is kept to
>> a minimum. My own preference is to be really cautious about this
>> since if people perceive SCA as yet another technology that is going
>> to force them to redo everything we are going to have difficulty
>> gaining traction.
>>
>> Jim
>>
>> > Robbie
>> >
>> >
>> >
>> >
>> > On 8/18/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >>
>> >> On Aug 18, 2006, at 12:24 PM, Robbie Minshall wrote:
>> >>
>> >> > I think that there are two ( ok more than that but still . . . )
>> >> > types of
>> >> > samples. One type attempts to demonstrate the muscles of the
>> >> > technology and
>> >> > inspire a 'boy this is great, this is better than what I am
>> >> > currently doing'
>> >> > thought process. The other is more educational and attempts to
>> >> > walk the
>> >> > developer through the development/deployment process while
>> giving
>> >> > them a
>> >> > sense of what they are accomplishing. Both are usefull.
>> However,
>> >> > I often
>> >> > feel that samples get the goals confused and wind up
>> complicating
>> >> > the code
>> >> > of educational sample without providing the appropiate tutorial
>> >> > updates.
>> >> >
>> >> I agree. Petstore is probably an example of this happening.
>> >>
>> >> > The key for educational samples is that they should be readable,
>> >> > should
>> >> > involve deployment and most importantly a concise accurate
>> >> > tutorial. They
>> >> > should not attempt to be the killer app but in the SCA land
>> should
>> >> > definately involve plugging in different service implementations
>> >> > etc as a
>> >> > part of the tutorial. It is also a little harder than one would
>> >> > think to
>> >> > provide documentation etc that clearly indicate to the user
>> which
>> >> > application they should use for what goal.
>> >> >
>> >> I'm not sure the education samples all need to plug in different
>> >> impls. Maybe as an "extra". For example, I may only be ever
>> >> interested in writing Java. Agreed on documentation.
>> >> > I would recommend two approaches. Providing a simple sample
>> >> > application
>> >> > combined with a tutorial for dev, deployment, execution, service
>> >> > replacement
>> >> > etc that does not provide an runtime environement such tomcat.
>> >> Also
>> >> > providing a fatter muscle flexing sca application combined
>> with a
>> >> > up and
>> >> > runing environement.
>> >> Agreed on the division but I don't think we need to distribute
>> a host
>> >> environment such as Tomcat. For the muscle flexing one (I know
>> have
>> >> an image of some 70s muscle car, maybe we can call the sample
>> >> "chevelle" ;-) ), I think the only practical environment would be
>> >> standalone or OSGi since J2EE is going to constrain us too much.
>> >> >
>> >> > On an aside I am currently working on a simple POJO Hibernate
>> >> > application
>> >> > conversion to using SDO and then exposing services via SCA.
>> Kapel
>> >> > and I
>> >> > plan to write a simple tutorial going over the migration and
>> other
>> >> > aspects
>> >> > of this task such as comparing a Hibernate RDB DAS to the SDO
>> DAS,
>> >> > and hte
>> >> > performance cost of using static SDO within our applications
>> POJO
>> >> > model.
>> >> >
>> >> Hmm, that kind of sends the message that people should use SDO/DAS
>> >> instead of O/R technologies such as Hibernate, EJB3, or JDO. How
>> >> about showing how they are complimentary as I think they really
>> >> address different use cases?
>> >>
>> >>
>> >> > . . . thoughts ?
>> >> >
>> >> > Robbie
>> >> >
>> >> > On 8/18/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >>
>> >> >> 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 <si...@googlemail.com> wrote:
>> >> >> >>>
>> >> >> >>> On 8/18/06, ant elder <an...@gmail.com> 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/%
>> >> >> >>>
>> 3c2516867c0604121307y860644cl28b1054f5994bfda@mail.gmail.com
>> >> %3e
>> >> >> >>> >
>> >> >> >>> > 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 <jm...@myromatours.com> 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 <jl...@iona.com> 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:jboynes@apache.org]
>> >> >> >>> > > >> > 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-
>> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >>> > > >> > For additional commands, e-mail: tuscany-dev-
>> >> >> >>> help@ws.apache.org
>> >> >> >>> > > >> >
>> >> >> >>> > > >> >
>> >> >> >>> > > >>
>> >> >> >>> > > >>
>> >> >> >>>
>> >> >>
>> >>
>> --------------------------------------------------------------------
>> >> >> >>> -
>> >> >> >>> > > >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> unsubscribe@ws.apache.org
>> >> >> >>> > > >> For additional commands, e-mail: tuscany-dev-
>> >> >> >>> help@ws.apache.org
>> >> >> >>> > > >>
>> >> >> >>> > > >>
>> >> >> >>> > >
>> >> >> >>> > >
>> >> >> >>> > >
>> >> >> >>>
>> >> >>
>> >>
>> --------------------------------------------------------------------
>> >> >> >>> -
>> >> >> >>> > > To unsubscribe, e-mail: tuscany-dev-
>> >> unsubscribe@ws.apache.org
>> >> >> >>> > > For additional commands, e-mail: tuscany-dev-
>> >> >> help@ws.apache.org
>> >> >> >>> > >
>> >> >> >>> > >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > * * * Charlie * * *
>> >> > Check out some pics of little Charlie at
>> >> > http://www.flickr.com/photos/83388211@N00/sets/
>> >> >
>> >> > * * * Addresss * * *
>> >> > 1914 Overland Drive
>> >> > Chapel Hill
>> >> > NC 27517
>> >> >
>> >> > * * * Number * * *
>> >> > 919-225-1553
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > * * * Charlie * * *
>> > Check out some pics of little Charlie at
>> > http://www.flickr.com/photos/83388211@N00/sets/
>> >
>> > * * * Addresss * * *
>> > 1914 Overland Drive
>> > Chapel Hill
>> > NC 27517
>> >
>> > * * * Number * * *
>> > 919-225-1553
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> * * * Charlie * * *
> Check out some pics of little Charlie at
> http://www.flickr.com/photos/83388211@N00/sets/
>
> * * * Addresss * * *
> 1914 Overland Drive
> Chapel Hill
> NC 27517
>
> * * * Number * * *
> 919-225-1553
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org