tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: [2.x] Samples
Date Wed, 04 Feb 2009 12:17:54 GMT
On Thu, Jan 22, 2009 at 9:56 AM, ant elder <antelder@apache.org> wrote:

> On Thu, Jan 22, 2009 at 8:46 AM, Simon Laws <simonslaws@googlemail.com>wrote:
>> On Thu, Jan 22, 2009 at 7:29 AM, ant elder <ant.elder@gmail.com> wrote:
>>> I think we're both suggesting the same things just with different
>>> terminology. You're using the managed versus unmanaged distinction as to
>>> whether or not the sample starts up a runtime itself or not right, so a
>>> "managed" sample is what I'd called the proper SCA contributions which get
>>> deployed to some runtime as a separate step. That separate step makes it
>>> slightly more complicated but its minimal complexity and would be consistent
>>> across the samples, and doing it this way makes the sample more focused on
>>> what its trying to show - how to write a Java component, how to use a web
>>> service binding, etc - and doesn't mix the code for starting a runtime and
>>> invoking a service into the sample code which I think makes them clearer.
>>>     ...ant
>>> On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <enjoyjava@gmail.com>wrote:
>>>> I would like to see two types of samples:
>>>> 1) Managed: The composite application is developed as one or more
>>>> contributions. There is no explicit code to bootstrap the Tuscany runtime
>>>> the application. A launcher is used to launch the "pure" SCA application.
>>>> 2) Unmanaged: The application has a main() (or other entry point based
>>>> on the hosting environment such as an OSGi activator) to bootstrap the
>>>> Tuscany runtime and access the SCA services.
>>>> [1]
>>>> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>>>> Thanks,
>>>> Raymond
>>>> --------------------------------------------------
>>>> From: "Luciano Resende" <luckbr1975@gmail.com>
>>>> Sent: Wednesday, January 21, 2009 9:00 AM
>>>> To: <dev@tuscany.apache.org>; <antelder@apache.org>
>>>> Subject: Re: [2.x] Samples
>>>>  As you mentioned, this might make our samples more complex then
>>>>> expected from a new user.
>>>>> What would be the user experience here ? Maybe we could do something
>>>>> with the demos, that are already more complex and try to demonstrate
>>>>> more realistic user scenario ?
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <ant.elder@gmail.com>
>>>>> wrote:
>>>>>> With all the 2.x changes going on and runtime starting discussion
>>>>>> was
>>>>>> wondering about changing some of our samples so that most samples
>>>>>> create
>>>>>> proper SCA contribution jars, they get run by deploying the
>>>>>> contribution to
>>>>>> a runtime, they wouldn't include the client impl which invokes the
>>>>>> sample
>>>>>> within the contribution jar, and maybe also have samples use the
>>>>>> contributions from other samples. It would need a launcher if we
>>>>>> it that
>>>>>> way (like what is being discussed on the runtime launching thread),
>>>>>> and we'd
>>>>>> need separate client samples.
>>>>>> It might make the very simplest samples slightly more complicated,
>>>>>> it
>>>>>> makes the sample contributions more reusable across the various
>>>>>> runtime
>>>>>> environments and would demonstrate how to use domains with multiple
>>>>>> contributions and composites and how to swap around different binding
>>>>>> and
>>>>>> implementation types.
>>>>>> I'm in two minds if it would be better than the current approach,
>>>>>> do
>>>>>> others think?
>>>>>>   ...ant
>>>>> --
>>>>> Luciano Resende
>>>>> Apache Tuscany, Apache PhotArk
>>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>>> http://lresende.blogspot.com/
>> I would like the focus to be on what Raymond calls "Managed". I.e. we have
>> samples that rely on the JSE launcher, the OSGi lanucher, the webapp
>> "launcher" etc. We should have some samples that use the node launcher or
>> factory directly to demonstrate the local sca binding in use from a main()
>> method but I think these should be in the minority whereas at the moment
>> nearly all the samples are done this way.
>> Simon
> Yep thats exactly what i think too. So most samples would be demonstrating
> SCA features and therefore be SCA contributions, some other samples would be
> demonstrating Tuscany specific things like how to start different runtime
> environments or get access to the local domain services etc.
>    ...ant
This is being tracked at TUSCANY-2805. A quick update on various realted
points.  I'm using the binding-ws-calculator sample as the test case for
this at the moment.

managed vs unmanaged.

there has been discussion, and I believe agreement, here that we want to
show many more "managed" samples where a launcher is given a contribution as
an alternative to using the node API from a JSE client. The original plan
was to use @Init methods to kick the sample off but we await news from OASIS
on @PostInit before we can go this direction [1]. In the mean time I've
switched binding-ws-calculator back to being driven by a JSE client. If
@PostInit doesn't work out we could start two processes for the sample, one
that runs the composite and a separate client that prods it.


I've produced a new build.xml [2] which takes the basic build.xml from the
rmi samples, adds a run target and does away with the common-build.xml

sample naming

I prefer binding-ws-calculator to calculator-binding-ws as the emphasis is
on binding-ws rather that on calculator. It would be better to have
consistent sample names but I want some kind of agreement between us to
either stay with what we had in 1.x or move to the scheme I'm proposing or
something else.

samples testing

I'm working on itest/samples to run the samples as though they were being
run from the binary distribution.

Comments on any of this most welcome.


[1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04911.html

View raw message