You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/07/03 13:45:28 UTC
Re: Proposed approach for M2
On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip/>
2. Stage the assembly of our M2 runtime.
> I propose that we start a fresh stream for M2 and build the runtime
> through
> baby steps, in parallel with the scenario work. This will get our
> community
> members involved in building the runtime together and will lead to a wider
> knowledge base that makes it possible to quickly implement new
> functionality
> in the future. It will also build a community knowledge base that is
> ready to
> help new community members come on board quickly.
This approach appeals to me. Could we just give it a try for a little while
when everyone is back on Wednesday? If it doesn't work out then all the
other code will still be available in SVN to try another approach.
...ant
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
Comments inline
On Jul 4, 2006, at 7:16 AM, Jojo wrote:
> Hi,
>
> I was trying to understand the sandbox and having difficulty in
> making out
> things. I thought I will bring some of these into this thread. I would
> appreciate if somebody can helpme understand better.
>
> 1. Where is the client programming model ? I find some sample code in
> samples\src\main\java\eagerinit\EagerInitClient.java, but this
> doesn't work
> (fails with an NPE). But there is another class called
> \samples\src\main\java\eagerinit\LifecycleDemonstration.java which
> works.
Just to give a little background, eagerinit was not intended to show
an end-user programming model. Rather, it is just an example of how a
component lifecycle works from the perspective of the internal
workings of the container. This was in response to people wanting to
be able to step through the internal execution flow of core2.
Also we would not expect client code to bootstrap the container in
this manner; it's just for illustrative purposes since people had
questions about the internal workings of the container.
One of the programming models for Tuscany Java will be the SCA Java
C&I spec. Spring will be another. And, there can be many more
depending on what people want to implement.
Related to the Java C&I model, we're in the process of integrating
recent spec changes into the core, including:
1. Switch to nested composites
2. Generified API
3. Tighter definition of property and reference heuristic determination
4. Support for constructor-based injection
5. Changes to scope semantics
One of the key things about SCA (and most IoC containers) is that the
programming model and container are (almost) completely separate.
Most applications should never need to make an API call unless they
require access to a very low-level capability (the Java SCA API fits
onto on slide, normal font size). We on the spec took great care to
make sure we did not unnecessarily "bleed" the container into
application code (I'm sure we missed a few spots though). Those of us
who are also working on Tuscany are committed to making sure this is
also the case with the core implementation as well and that it
reflects the design principals laid out in the specifications.
> But the code there is too complex to be a client programming model.
> Is this
> the proposed client programming model ?
Completely agreed. This is definitely not the proposed client
programming model, the Java C&I spec and Spring are (there are others
such as Groovy too). It sounds as if you have some ideas on client
programming models and possible extensions to the existing ones. I'd
be interested in hearing about those both from a Tuscany and
specification perspective.
> I would expect something like the
> TuscanyRuntime class in M1 which I don't find any more.
There will be something similar to TuscanyRuntime; I believe Rick is
working on it.
>
> 2. I find in
> \sca\core2\src\main\java\org\apache\tuscany\core\launcher
> \MainLauncher.java,
> line number 134, it is loading "eagerinit.composite". Why is it
> doing that ?
> And is this file loaded from the samples project ?
Glancing at it, it's loading the composite SCDL using the system
classloader of the Launcher. Rick did this design and it makes sense
to me as an elegant way to enforce classloader isolation with the
core. I've seen similar approaches work well, including:
- http://jetty.mortbay.org/jetty/index.html
- http://nanocontainer.codehaus.org/Booter
>
> 3. There was a discussion on the container.java in the mailing list.
> (thread:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> msg04165.html) I
> didn't see any conclusion. And there is no container,java in the
> sandbox. So
> is it already merged with core ?
>
The discussion basically ended with no one able to come up with a
"good" solution so I choose what I thought was the lesser of two
evils: merging container.java into the core. This move entailed about
five classes and if someone can come up with a suitable alternative,
I'd be more than willing to implement it since I'm personally not
happy with the current solution (although I am happier with it than
the alternatives we had).
> warm regards,
> jojo.
>
> On 7/4/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On 7/3/06, ant elder <an...@gmail.com> wrote:
>> > I struggle with understanding the what and why of parts of the
>> sandbox
>> code
>> > and hope bringing small bits over one step at a time will help with
>> this.
>> >
>>
>> What things are you struggling with? Perhaps clearing those up would
>> clear the air (as well as help with the documentation).
>>
>> --
>> 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
Re: Proposed approach for M2
Posted by Jojo <jo...@gmail.com>.
Hi,
I was trying to understand the sandbox and having difficulty in making out
things. I thought I will bring some of these into this thread. I would
appreciate if somebody can helpme understand better.
1. Where is the client programming model ? I find some sample code in
samples\src\main\java\eagerinit\EagerInitClient.java, but this doesn't work
(fails with an NPE). But there is another class called
\samples\src\main\java\eagerinit\LifecycleDemonstration.java which works.
But the code there is too complex to be a client programming model. Is this
the proposed client programming model ? I would expect something like the
TuscanyRuntime class in M1 which I don't find any more.
2. I find in
\sca\core2\src\main\java\org\apache\tuscany\core\launcher\MainLauncher.java,
line number 134, it is loading "eagerinit.composite". Why is it doing that ?
And is this file loaded from the samples project ?
3. There was a discussion on the container.java in the mailing list.
(thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04165.html) I
didn't see any conclusion. And there is no container,java in the sandbox. So
is it already merged with core ?
warm regards,
jojo.
On 7/4/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On 7/3/06, ant elder <an...@gmail.com> wrote:
> > I struggle with understanding the what and why of parts of the sandbox
> code
> > and hope bringing small bits over one step at a time will help with
> this.
> >
>
> What things are you struggling with? Perhaps clearing those up would
> clear the air (as well as help with the documentation).
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proposed approach for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On 7/3/06, ant elder <an...@gmail.com> wrote:
> I struggle with understanding the what and why of parts of the sandbox code
> and hope bringing small bits over one step at a time will help with this.
>
What things are you struggling with? Perhaps clearing those up would
clear the air (as well as help with the documentation).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 3, 2006, at 3:30 PM, Kevin Williams wrote:
> My biggest concern is that we not end up with two active code
> streams. That would be very confusing to a potential contributor
> (and me). So, if there is value in both the trunk and the sandbox
> then it seems that a merge is necessary.
I agree on two streams being very confusing. When we did the sandbox
version, we took what we could from the trunk as a starting point.
Maybe there is something we missed amongst all the refactoring that
went on but even if there is, I don't think it is much.
> If only the sandbox has value then why not tag the trunk and copy
> over the entire sandbox? My two cents.
That was Jeremy's proposal as well. I think this makes the most
sense, and even if we missed something in the original M1, it seems
easier just to factor it back into a copy of the sandbox rather than
replaying the merge we did with the initial sandbox development.
> Thanks,
> --Kevin
>
> Jim Marino wrote:
>
>>
>> On Jul 3, 2006, at 5:34 AM, ant elder wrote:
>>
>>> One of the big reasons for me is summed up well in Sebastien's
>>> proposal:
>>>
>>> "This will get our community members involved in building the
>>> runtime
>>> together and will lead to a wider knowledge base that makes it
>>> possible to
>>> quickly implement new functionality in the future. It will also
>>> build a
>>> community knowledge base that is ready to help new community
>>> members come on
>>> board quickly."
>>>
>>> I struggle with understanding the what and why of parts of the
>>> sandbox code
>>> and hope bringing small bits over one step at a time will help
>>> with this.
>>>
>> Could you outline specifically what you don't understand. Perhaps
>> we could do another code walkthrough like we did about a month ago?
>>
>>> Why don't you like this approach? Sure it may take a bit more
>>> time but if in
>>> the long run we end up with more people understanding the
>>> runtime that seems
>>> like time well spent even if we end up with most of the trunk
>>> being just
>>> whats in the sandbox today.
>>>
>> The key point is I like Jeremy's approach better. The thought of
>> merging M1 with the sandbox code (Sebastien's proposal) doesn't
>> seem to fit based on my technical knowledge of both code bases.
>> More importantly, Jeremy's approach strike me as better. Since I
>> have outlined my reasoning in previous posts (not just technical)
>> why I think it is better,I won't repeat them here, as it will
>> just confuse the ongoing threads.
>>
>> So, to turn it around a bit, as I've already outlined some of my
>> reasons for liking Jeremy's approach more, do you have additional
>> reasons other than you are having difficulty understanding the
>> sandbox code and your feeling it will be a worthwhile exercise in
>> knowledge sharing? Regarding the later, I think it's better (and
>> more inclusive) to make a concerted effort to modularize and
>> bring people into the sandbox code as that will allow all of the
>> ongoing initiatives (particularly the ones showing Tuscany value
>> add) to continue alongside the knowledge transfer.
>>
>> Regarding the former, could you outline specifically what you are
>> having difficulty following in the sandbox code so I can try and
>> address it either through explanation or simplification of the code?
>>
>>> ...ant
>>>
>>> On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>>>
>>>>
>>>> Why would we try this approach as opposed to the one Jeremy
>>>> proposed,
>>>> i.e. moving what is already in sandbox to a branch or even trunk?
>>>> Since there are a number of initiatives people are already
>>>> working on
>>>> in the sandbox codebase (e.g. Spring support, deployment,
>>>> conversations, data binding, OSGi support, support for new Java C&I
>>>> annotations, support for pluggable annotations) it is seems that
>>>> making improvements to that according to scenarios people are
>>>> interested in will be a nice way to move things forward
>>>> involving as
>>>> many as possible.
>>>>
>>>> Jim
>>>>
>>>> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>>>>
>>>> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>> > <snip/>
>>>> >
>>>> > 2. Stage the assembly of our M2 runtime.
>>>> >> I propose that we start a fresh stream for M2 and build the
>>>> runtime
>>>> >> through
>>>> >> baby steps, in parallel with the scenario work. This will get
>>>> our
>>>> >> community
>>>> >> members involved in building the runtime together and will
>>>> lead to
>>>> >> a wider
>>>> >> knowledge base that makes it possible to quickly implement new
>>>> >> functionality
>>>> >> in the future. It will also build a community knowledge base
>>>> that is
>>>> >> ready to
>>>> >> help new community members come on board quickly.
>>>> >
>>>> >
>>>> > This approach appeals to me. Could we just give it a try for a
>>>> > little while
>>>> > when everyone is back on Wednesday? If it doesn't work out
>>>> then all
>>>> > the
>>>> > other code will still be available in SVN to try another
>>>> approach.
>>>> >
>>>> > ...ant
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Kevin Williams <ke...@qwest.net>.
My biggest concern is that we not end up with two active code streams.
That would be very confusing to a potential contributor (and me). So,
if there is value in both the trunk and the sandbox then it seems that a
merge is necessary. If only the sandbox has value then why not tag the
trunk and copy over the entire sandbox? My two cents.
Thanks,
--Kevin
Jim Marino wrote:
>
> On Jul 3, 2006, at 5:34 AM, ant elder wrote:
>
>> One of the big reasons for me is summed up well in Sebastien's
>> proposal:
>>
>> "This will get our community members involved in building the runtime
>> together and will lead to a wider knowledge base that makes it
>> possible to
>> quickly implement new functionality in the future. It will also build a
>> community knowledge base that is ready to help new community members
>> come on
>> board quickly."
>>
>> I struggle with understanding the what and why of parts of the
>> sandbox code
>> and hope bringing small bits over one step at a time will help with
>> this.
>>
> Could you outline specifically what you don't understand. Perhaps we
> could do another code walkthrough like we did about a month ago?
>
>> Why don't you like this approach? Sure it may take a bit more time
>> but if in
>> the long run we end up with more people understanding the runtime
>> that seems
>> like time well spent even if we end up with most of the trunk being
>> just
>> whats in the sandbox today.
>>
> The key point is I like Jeremy's approach better. The thought of
> merging M1 with the sandbox code (Sebastien's proposal) doesn't seem
> to fit based on my technical knowledge of both code bases. More
> importantly, Jeremy's approach strike me as better. Since I have
> outlined my reasoning in previous posts (not just technical) why I
> think it is better,I won't repeat them here, as it will just confuse
> the ongoing threads.
>
> So, to turn it around a bit, as I've already outlined some of my
> reasons for liking Jeremy's approach more, do you have additional
> reasons other than you are having difficulty understanding the
> sandbox code and your feeling it will be a worthwhile exercise in
> knowledge sharing? Regarding the later, I think it's better (and more
> inclusive) to make a concerted effort to modularize and bring people
> into the sandbox code as that will allow all of the ongoing
> initiatives (particularly the ones showing Tuscany value add) to
> continue alongside the knowledge transfer.
>
> Regarding the former, could you outline specifically what you are
> having difficulty following in the sandbox code so I can try and
> address it either through explanation or simplification of the code?
>
>> ...ant
>>
>> On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>>
>>> Why would we try this approach as opposed to the one Jeremy proposed,
>>> i.e. moving what is already in sandbox to a branch or even trunk?
>>> Since there are a number of initiatives people are already working on
>>> in the sandbox codebase (e.g. Spring support, deployment,
>>> conversations, data binding, OSGi support, support for new Java C&I
>>> annotations, support for pluggable annotations) it is seems that
>>> making improvements to that according to scenarios people are
>>> interested in will be a nice way to move things forward involving as
>>> many as possible.
>>>
>>> Jim
>>>
>>> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>>>
>>> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> > <snip/>
>>> >
>>> > 2. Stage the assembly of our M2 runtime.
>>> >> I propose that we start a fresh stream for M2 and build the
>>> runtime
>>> >> through
>>> >> baby steps, in parallel with the scenario work. This will get our
>>> >> community
>>> >> members involved in building the runtime together and will lead to
>>> >> a wider
>>> >> knowledge base that makes it possible to quickly implement new
>>> >> functionality
>>> >> in the future. It will also build a community knowledge base
>>> that is
>>> >> ready to
>>> >> help new community members come on board quickly.
>>> >
>>> >
>>> > This approach appeals to me. Could we just give it a try for a
>>> > little while
>>> > when everyone is back on Wednesday? If it doesn't work out then all
>>> > the
>>> > other code will still be available in SVN to try another approach.
>>> >
>>> > ...ant
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
Comments inline, thanks for some of the clarifications...
On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> Jim Marino wrote:
>>
>> On Jul 3, 2006, at 5:34 AM, ant elder wrote:
>>
>>> One of the big reasons for me is summed up well in Sebastien's
>>> proposal:
>>>
>>> "This will get our community members involved in building the
>>> runtime
>>> together and will lead to a wider knowledge base that makes it
>>> possible to
>>> quickly implement new functionality in the future. It will also
>>> build a
>>> community knowledge base that is ready to help new community
>>> members come on
>>> board quickly."
>>>
>>> I struggle with understanding the what and why of parts of the
>>> sandbox code
>>> and hope bringing small bits over one step at a time will help
>>> with this.
>>>
>> Could you outline specifically what you don't understand. Perhaps
>> we could do another code walkthrough like we did about a month ago?
>>
>>> Why don't you like this approach? Sure it may take a bit more
>>> time but if in
>>> the long run we end up with more people understanding the runtime
>>> that seems
>>> like time well spent even if we end up with most of the trunk
>>> being just
>>> whats in the sandbox today.
>>>
>> The key point is I like Jeremy's approach better. The thought of
>> merging M1 with the sandbox code (Sebastien's proposal) doesn't
>> seem to fit based on my technical knowledge of both code bases.
>> More importantly, Jeremy's approach strike me as better. Since I
>> have outlined my reasoning in previous posts (not just technical)
>> why I think it is better,I won't repeat them here, as it will just
>> confuse the ongoing threads.
>>
>
>
> My proposal is not to merge M1 and the core2 sandbox. I am
> proposing to start a new fresh code stream and build the runtime
> through baby steps. We may be able to reuse some pieces of existing
> code, but more important is to engage our community in this
> exercise and integrate the new ideas that will emerge from this.
>
>
> Here's an example where I'm struggling with both M1 and the core2
> sandbox and thinking that we can do better if we start with a new
> fresh stream: our (recursive) assembly metadata model.
>
> - M1 does not implement the recursive composition model and would
> require significant changes to support it. Core2 is an attempt to
> implement it but I'm not sure it's quite right, and also think that
> it can be simplified.
>
It may be able to use a bit of simplification, but why is that an
argument to start over? Why not have the community leverage and
refactor it? That would seem to be much more inclusive since it would
allow a lot of the existing initiatives to proceed and be used to
help drive the simplification.
> - M1 used Lists to represent relationships, Core2 uses Maps, I
> think M1 was better since it allowed to keep the order in the
> relationships.
>
Some specific reasons would be good here. Also, I hardly think this
is a reason to start over.
> - Core2 only defines implementation classes for the model, I think
> we should have interfaces + default implementation classes instead,
> like we had in M1, to allow for alternate implementations of the
> model.
>
The model contains no implementation behavior, it's just a set of
dumb data objects, so interfaces seem superfluous. If you really
wanted to override setter/getter behavior (perhaps for notification,
although I don't understand why one would do that in a runtime as
opposed to tooling) the classes can always be subclassed. Regarding
alternative implementations of the model, what use cases do you have
in mind? The base SCA model shouldn't change that much (it's in the
specification) so I imagine most people will just use the loaders
that come with Tuscany do load the non-extension parts. And when the
spec model does change, writing StAX loaders is dead trivial and well
understood by Java developers (StAX is being included in the JDK).
For extensions, configuration, etc., the framework Jeremy created
supports a pluggable databinding mechanism so SDO, JAXB, XStream,
etc. can *all* be used to load extensions.
Again, though, the fact that the model does not use interfaces is not
a reason to jettison the substantial amount of capability already in it.
> - Over usage of Java Generics breaks flexibility in some cases, for
> example Component<I extends Implementation> will force you to
> recreate an instance of Component to swap its implementation with
> an implementation of a different type (and lose all the wires going
> in/out of the component).
Not at runtime. This will work fine. Could you outline the specific
use-case you have in mind?
>
> - Core2 defines ReferenceDefinitions (without bindings) and
> BoundReferenceDefinitions (with bindings). IMO there are Reference
> types and Reference instances and both can have bindings.
> or Reference.
>
Great. Why can't we work on a "proposal"/modification to extend/
change core2 and see what it looks like together?
> - I think that Remotable should be on Interface and not Service.
>
Service can be on both I believe. Unfortunately, annotations cannot
be restricted to interfaces in Java, though.
> - Scope should be defined in the Java component implementation,
> separate from the core model.
>
No, scopes are a general and very useful concept across
implementation types, e.g. I may want to have a Groovy script that is
conversational, bound to a session or module scoped. In the spec
group, we also decided to keep a general concept of scopes and leave
the specifics to individual language bindings. That's kind of what we
have in core2 today. I say "kind of" since our intent is to provide a
fully extensible set of scope containers. The one issue we are having
that needs fixing is Scope is an Enum and those can't be extended in
Java, so we need to look for an alternative.
If you have some thoughts on how to solve this issue, I'd be
interested in talking about them.
> - Java and WSDL interfaces should be defined separate from the core
> model, we need to support multiple interface definition languages
> supported by plugins, not in the core.
>
Yep that's been brought up and a good way to engage. Jeremy and Ant
had some ideas on this so perhaps the three of you could work
together on that?
> - Implementation should extend ComponentType IMO instead of
> pointing to it, and we may even be able to simplify and just remove
> Implementation. Also I am not sure why we need to distinguish
> between AtomicImplementation and CompositeImplementation.
>
All great feedback for improving core2. Jeremy had some reasons for
this so I'll let him speak up.
> - Support for Composite Includes is missing, this is a significant
> part of the recursive composition model (half of it, one of the two
> ways to nest composites).
>
Yes, because those were a recent addition to the spec. Again, this
would be a fantastic way to add value to core2. Can you help?
>
> This list is not exhaustive... Another idea would be to externalize
> support for Composites in a separate plugin not part of the core
> service model (since there may be other ways to compose services in
> addition to an SCA composite, with Spring or other similar
> programming models), I'd like to know what people think about that.
>
Yes we have a specialized Spring composite type. We could entertain
making composite a separate implementation type, although I think
that may blow the complexity of the core through the proverbial roof.
Let's try it though. Maybe the best way to do this is make a copy of
core2 and start moving packages around and set what happens? My one
recommendation on this would be do first look at separating API from
SPI per Jeremy's suggestion posted in a previous email.
> I just checked in sandbox/sebastien/m2-design/model.spi a set of
> new interfaces. This is just an initial strawman to trigger a
> constructive discussion and ideas on how to best represent the
> recursive model. I also need help to define a scenario (not unit
> test cases, but an end to end sample application) to help put the
> recursive composition model in perspective and make sure we all
> understand it the same way.
>
> Comments, feedback and help are welcome...
Great, why don't we compare that model and try and see what happens
when we fit it into core2? Could you summarize the main differences?
To summarize, I think all of the issues you laid out are a reason to
engage and start from core2, not afresh. By doing so, I'm sure your
suggestions will lead to substantial improvements in what we have
today and help the broader community implement things they are
interested in.
Jim
>
>
>> So, to turn it around a bit, as I've already outlined some of my
>> reasons for liking Jeremy's approach more, do you have additional
>> reasons other than you are having difficulty understanding the
>> sandbox code and your feeling it will be a worthwhile exercise in
>> knowledge sharing? Regarding the later, I think it's better (and
>> more inclusive) to make a concerted effort to modularize and bring
>> people into the sandbox code as that will allow all of the ongoing
>> initiatives (particularly the ones showing Tuscany value add) to
>> continue alongside the knowledge transfer.
>>
>> Regarding the former, could you outline specifically what you are
>> having difficulty following in the sandbox code so I can try and
>> address it either through explanation or simplification of the code?
>>
>>> ...ant
>>>
>>> On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>>>>
>>>> Why would we try this approach as opposed to the one Jeremy
>>>> proposed,
>>>> i.e. moving what is already in sandbox to a branch or even trunk?
>>>> Since there are a number of initiatives people are already
>>>> working on
>>>> in the sandbox codebase (e.g. Spring support, deployment,
>>>> conversations, data binding, OSGi support, support for new Java C&I
>>>> annotations, support for pluggable annotations) it is seems that
>>>> making improvements to that according to scenarios people are
>>>> interested in will be a nice way to move things forward
>>>> involving as
>>>> many as possible.
>>>>
>>>> Jim
>>>>
>>>> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>>>>
>>>> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>> > <snip/>
>>>> >
>>>> > 2. Stage the assembly of our M2 runtime.
>>>> >> I propose that we start a fresh stream for M2 and build the
>>>> runtime
>>>> >> through
>>>> >> baby steps, in parallel with the scenario work. This will get
>>>> our
>>>> >> community
>>>> >> members involved in building the runtime together and will
>>>> lead to
>>>> >> a wider
>>>> >> knowledge base that makes it possible to quickly implement new
>>>> >> functionality
>>>> >> in the future. It will also build a community knowledge base
>>>> that is
>>>> >> ready to
>>>> >> help new community members come on board quickly.
>>>> >
>>>> >
>>>> > This approach appeals to me. Could we just give it a try for a
>>>> > little while
>>>> > when everyone is back on Wednesday? If it doesn't work out
>>>> then all
>>>> > the
>>>> > other code will still be available in SVN to try another
>>>> approach.
>>>> >
>>>> > ...ant
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: Rules for Revolutionaries [was: M2]
Posted by ant elder <an...@gmail.com>.
I agree with Simon 100%. Its really bad we've let the main trunk lose
momentum, we should all start working on it again. I'll start that tomorrow
and hope others will come and help.
...ant
(and as a sign of good faith and commitment to the main trunk code I've
deleted miral)
On 7/12/06, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Thanks, Sam; this is very helpful. One part in particular of the
> James Duncan Davidson post caught my eye:
>
> <jdd>
> 4) The trunk is the official versioned line of the project. All
> evolutionary minded people are welcome to work on it to improve it.
> Evolutionary work is important and should not stop as it is always
> unclear when any particular revolution will be ready for prime time
> or whether it will be officially accepted.
> </jdd>
>
> I think we have failed to follow this guideline over recent weeks.
> People have submitted patches for the trunk and they have not been
> applied (or applied to a sandbox instead). Technical discussions
> have started that in the normal course of events would have led to
> commits and patches, but these commits and patches have not been
> forthcoming. This has generally led to progress on the project
> (except for sandbox activity) being stalled, presumably because
> people were waiting to see what would happen with the sandbox code.
>
> I believe we need to get the project moving forward again. At the
> present time, we have an evolutionary trunk and a revolutionary
> sandbox. We should therefore continue (in reality restart) doing
> evolutionary work on the trunk for the reasons that JDD gives in
> the quote above. There is evolutionary work that can usefully
> be done, such as Raymond's work on databindings, the work on
> interface represenation that Ant and others have been discussing,
> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
> there are other things too. If at some point there is a revolution,
> then we will deal with it when it happens and rework existing code
> as necessary.
>
> Revolutionaries can work in the "chianti" sandbox, or if they
> prefer a different brand of revolution, they can create another
> sandbox to do this. The latter is perfectly legitimate according
> to the Rules for Revolutionaries, and I think it is healthy for
> the project for people to be able to show their new ideas in the
> form of code, as long as the project as a whole (i.e., the whole
> community) keeps moving forward with ongoing work on the trunk
> and doesn't focus exclusively on what is happening in the
> sandboxes.
>
> Simon
>
> Sam Ruby wrote:
>
> > Jeremy Boynes wrote:
> >
> >> Ant
> >>
> >> I'm disappointed that you have chosen this path. I will ask one more
> >> time if you and Sebastien would consider collaborating with those of
> >> us working on core2.
> >
> >
> > A while ago, I agreed to be a mentor for this project. I guess it is
> > about time that I start acting like one.
> >
> > If this project ever hopes to exit incubation, it had better start
> > acting like an ASF project. For starters, I suggest that all committers
> > read the Rules for Revolutionaries[1][2][3].
> >
> > For those who want the Cliff notes version: anybody who wants to work in
> > an evolutionary fashion on the main trunk is welcome to do so. Anybody
> > who wants to work on a revolutionary branch is welcome to do so.
> > Multiple concurrent revolutionary branches are OK too.
> >
> > One thing that is decidedly NOT OK is to include a version number in the
> > name, as it causes friction. Hence, I'd suggest that "core2"
> > immediately get renamed to something that neither reflects the term
> > "core" or the number "2".
> >
> > Something implicit in the R4R document is that the burden of proof is on
> > the revolutionaries. If you would like to see your particular branch
> > merged back onto the trunk, be prepared to demonstrate why your
> > particular branch is not merely better, but necessary. My experience it
> > that the more concrete and the less hand-wavy the argument, the more
> > likely it will be accepted. So, if you chose to believe that scenarios
> > and test cases are optional, just remember, merging your sandbox back to
> > the trunk is optional too. That does not mean that scenarios and test
> > cases are required, but it does mean that if these aren't present, you
> > need to come up with something just as compelling.
> >
> > - Sam Ruby
> >
> > [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
> > [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
> > [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
So I hope you don't mind if we also move core2 since I also don't
like working in others' sandboxes? This is not the best way to forge
consensus and community building in my opinion. If you want to go
down this direction I am truly sorry you have chosen not to engage on
core2. Perhaps you will reconsider and we'd be happy to have your
input at any point in improving core2.
Jim
On Jul 7, 2006, at 11:53 PM, ant elder wrote:
> Sebastien, lets just do it...this debate is going no where and as
> choosing
> with a vote wasn't popular lets try your approach and see how it
> works.
> After a couple of weeks take a checkpoint and decide whether or not to
> continue. I don't like working in other peoples sandbox so I've
> created a
> folder named miral and as a start copied your model.spi folder
> there. We'll
> all have to be dedicated and hard working so as to quickly get
> something
> going which demonstrates that this is the best way forward. I'm up
> for it,
> how about the rest of you?
>
> https://svn.apache.org/repos/asf/incubator/tuscany/miral/
>
> ...ant
>
> On 7/7/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> More comments inline.
>>
>> Jim Marino wrote:
>> > Comments inline
>> > On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
>> >
>> >> Jeremy,
>> >>
>> >> I won't comment on your attacks at the bottom of this email. I was
>> >> hoping for a more constructive technical discussion. I added my
>> >> answers and comments on the specific technical issues inline.
>> >>
>> >> Jeremy Boynes wrote:
>> >>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>> >>>>
>> >>>> My proposal is not to merge M1 and the core2 sandbox. I am
>> >>>> proposing to start a new fresh code stream and build the runtime
>> >>>> through baby steps. We may be able to reuse some pieces of
>> existing
>> >>>> code, but more important is to engage our community in this
>> >>>> exercise and integrate the new ideas that will emerge from this.
>> >>>>
>> >>>
>> >>> I don't believe the two issues are necessarily coupled. Quite
>> a few
>> >>> members of the community are engaged on the sandbox code
>> already and
>> >>> we could work with you to improve that rather having to throw
>> >>> everything out and start over with all new ideas.
>> >>>
>> >>>>
>> >>>> Here's an example where I'm struggling with both M1 and the
>> core2
>> >>>> sandbox and thinking that we can do better if we start with a
>> new
>> >>>> fresh stream: our (recursive) assembly metadata model.
>> >>>>
>> >>>> - M1 does not implement the recursive composition model and
>> would
>> >>>> require significant changes to support it. Core2 is an
>> attempt to
>> >>>> implement it but I'm not sure it's quite right, and also
>> think that
>> >>>> it can be simplified.
>> >>>
>> >>> It would really help if you could come up with concrete areas
>> where
>> >>> it is not right or where it could be simplified - for example,
>> end
>> >>> user scenarios that are not supported.
>> >>>
>> >>>>
>> >>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>> >>>> think M1 was better since it allowed to keep the order in the
>> >>>> relationships.
>> >>>
>> >>> There's nothing I remember in the assembly spec where order
>> matters.
>> >>> On the other hand there are many areas where things are keyed
>> by a
>> >>> name which has to be unique. This seems like a natural mapping
>> >>> (sorry) to a Map. In M1 I started to move toward simple map
>> >>> structures but you replaced it with what seemed like a fairly
>> >>> complicated specialized List implementation that sent
>> notifications
>> >>> that updated a Map anyway. Given the desire for
>> simplification, are
>> >>> there any end-user scenarios that require ordering to be
>> preserved
>> >>> and that can't be supported with a basic HashMap or
>> LinkedHashMap?
>> >>>
>> >> As an administrator I'll want my administration tool to display
>> >> components displayed in the order I declared them in SCDL.
>> > SCDL isn't the only form assembly can be serialized to/from.
>> Also, if
>> > I were an admin, I'd probably want to sort the components
>> according to
>> > some useful criteria, not how they are listed in a SCDL as most
>> admins
>> > will never look at XML. One could always use LikedHashMap though.
>> >
>> Maybe SCDL isn't the only form but this is not relevant, we need to
>> support SCDL don't we? As soon as you put assembly elements in a
>> document that a user/developer can edit the order is relevant.
>>
>> I disagree with your statement about administrators. They often
>> look at
>> and work with XML configuration files. If you want to support
>> other sort
>> criteria in addition that's fine, but admin, config and editing tools
>> need to at least support the order from the XML document.
>>
>> >> I'll also want a configuration or admin tool loading/saving
>> modified
>> >> SCDL to write things in the order that they were initially, not
>> in a
>> >> random order. As an application developer I'd like to have an SCA
>> >> debugging tool showing me my components in a list in the right
>> order
>> >> as well. Also if I want to implement the model defined by the XML
>> >> schemas in the spec using any of the DataBinding technologies out
>> >> there, I'll end up with Lists, not Maps.
>> >>
>> > We have been using StAX just fine for this and it accommodates a
>> > number of databinding solutions for extensions. Are you
>> proposing we
>> > revisit this decision made back before the M1 release to go with
>> STaX
>> > loading? If so, for what reasons? BTW, not all databinding
>> solutions
>> > will have problems - XStream will work just fine with what we have.
>> > Also, are you sure about XMLBeans and JAXB or are you just speaking
>> > about a current implementation of SDO?
>>
>> Not quite correct, the decision we made back before M1 was to go with
>> StAX loading, write the loaders by hand for now, and see how the SDO
>> team could generate this code after M1. Independent of that, I don't
>> want to tie us to any specific data binding, so we better pick
>> representations for model relationships that are commonly used by
>> most
>> databindings to represent XSD <element... maxOccurs="unbounded"/>,
>> i.e.
>> Lists, not Maps.
>>
>> >
>> >> Finally even if we decided to use Maps in some cases to provide
>> keyed
>> >> access to some elements of the model, we'd have to do it
>> differently.
>> >> For example a single Map containing all components, references and
>> >> services in a composite (according to the spec they cannot have
>> the
>> >> same names) instead of three Maps like you have in Core2.
>> >>
>> And this is why LinkedHashMap will not help you here.
>>
>> >>>>
>> >>>> - Core2 only defines implementation classes for the model, I
>> think
>> >>>> we should have interfaces + default implementation classes
>> instead,
>> >>>> like we had in M1, to allow for alternate implementations of the
>> >>>> model.
>> >>>
>> >>> One of the most complex things with the M1 model was all the
>> >>> interfaces involved, the need to pass factory implementations
>> >>> around, the number of different factories involved (one per
>> >>> extension implementation) and the potential issues with code
>> >>> assuming its implementation of the factory was the one used.
>> >>>
>> >>> The core2 model uses concrete classes which are really just data
>> >>> holders - there's no behaviour in them to be abstracted
>> through the
>> >>> interface. This gives a much simpler programming model for
>> >>> extensions using the model.
>> >>>
>> >>> Do you have any scenarios that would require different
>> >>> implementations of the model? Are they so different that they
>> might
>> >>> as well just use different classes?
>> >>>
>> >>
>> >> I don't think that having just implementation classes is much
>> >> simpler. If you interact with the model SPI, reading interfaces is
>> >> simpler IMO and more suitable for inclusion in a specification
>> >> document... allowing multiple implementations of these interfaces.
>> >> Also we have to support the whole lifecycle of an SCA application
>> >> (development, deploy/install, runtime, admin etc.) and I'd like to
>> >> allow some flexibility for different tools, running at different
>> >> times to use different implementations of the assembly model
>> interfaces.
>> >>
>> > Oisin from the STP project said the POJO based approach would suit
>> > them just fine. I don't see the complexity. On the contrary, all of
>> > the AssemblyFactories we had in M1 lead IMO to a massive
>> antipattern
>> > where they were passed throughout the core. I'm happy to walk
>> through
>> > the relevant code if people are interested. All the factories
>> did was
>> > new up a POJO. Not worth the complexity in my opinion but I'm
>> happy to
>> > compare the work in the sandbox with your proposal if you'd like to
>> > walk us through it.
>>
>> When the runtime depends on too many factories, this is the
>> manifestation of bigger coupling problems. The factories for all the
>> extensions should not be visible at all from the core runtime, and
>> if we
>> externalize the WSDL and Java interface support and the Java
>> implementation support our of core like I'm proposing, you're not
>> dealing with many factories.
>>
>> I am sure that tooling projects will need to add much to this model,
>> support for events, change tracking, tracking between XML elements
>> and
>> model objects to provider proper feedback to application developers,
>> integration with modeling technologies used in the tooling world,
>> support for cloning maybe... tons of things. I spent several years
>> developing tools so I think I know what I'm talking about here. The
>> first thing I'll ask as a tooling developer is: please give me
>> interfaces so I can hook what I need in the implementations.
>>
>> I'm happy to walk people through the interfaces or answer any
>> questions
>> on the list,
>>
>> >>>>
>> >>>> - Over usage of Java Generics breaks flexibility in some
>> cases, for
>> >>>> example Component<I extends Implementation> will force you to
>> >>>> recreate an instance of Component to swap its implementation
>> with
>> >>>> an implementation of a different type (and lose all the wires
>> going
>> >>>> in/out of the component).
>> >>>
>> >>> There may be cases where generics may be overkill but I don't
>> think
>> >>> that really requires us to throw out the model. There are other
>> >>> cases where the use of wildcards would be appropriate; for
>> example,
>> >>> in the scenario you give here you could just create a
>> >>> Component<Implementation> to allow different types of
>> implementation
>> >>> to be used.
>> >>>
>> >> Then instead of
>> >> Component<Implementation> {
>> >> Implementation getImplementation();
>> >> }
>> >> I think we can just do
>> >> Component {
>> >> Implementation getImplementation();
>> >> }
>> >> What we have now in core2 is overkill IMO.
>> >>
>> > then do we need to cast to the right impl type?
>>
>> The core runtime should not have to cast, simply because it should
>> not
>> depend on any component implementation type (not even the Java or
>> System
>> implementation types).
>>
>> >
>> >>>>
>> >>>> - Core2 defines ReferenceDefinitions (without bindings) and
>> >>>> BoundReferenceDefinitions (with bindings). IMO there are
>> Reference
>> >>>> types and Reference instances and both can have bindings.
>> >>>> or Reference.
>> >>>
>> >>> I'm with you here - we need to refactor the way bindings are
>> handled
>> >>> for both Service and Reference. One thing the sandbox model is
>> >>> missing is the ability to associate multiple bindings with a
>> single
>> >>> Service/Reference.
>> >>
>> >> My main point is not about supporting multiple bindings on a
>> Service
>> >> or Reference. I think this is secondary and the interfaces I
>> put in
>> >> my sandbox to support a design discussion don't even have that
>> >> either. My point is that Services, References, and their
>> >> instantiation by Components are at the foundation of the SCA
>> assembly
>> >> model... and therefore need to be modeled correctly. I'm
>> proposing a
>> >> different design, illustrated by the interfaces I checked in.
>> >>
>> > Could you elaborate?
>>
>> I think it should be very simple:
>> - Component types have service and reference types
>> - Components are instances of component types and have services and
>> references, which are instances of the service and reference types
>> - Service and reference types can have bindings
>> - Bindings can be overriden in service and reference instances
>> This is clear when you look at a Composite. A composite is a
>> Component
>> Type, has service and reference types (aka composite services and
>> references) which can have bindings.
>> A component can be implemented by a Composite, has services and
>> references, which can use the (default) bindings from their
>> respective
>> service and reference types, or specify (override) bindings.
>>
>> >>>
>> >>>>
>> >>>> - I think that Remotable should be on Interface and not Service.
>> >>>
>> >>> I agree Service is wrong and that it should be on
>> ServiceContract.
>> >>> Thanks for catching it.
>> >>>
>> >>>>
>> >>>> - Scope should be defined in the Java component implementation,
>> >>>> separate from the core model.
>> >>>
>> >>> Scope is not a Java specific concept.
>> >>> Interaction scope (stateless vs. stateful) can apply to any
>> >>> ServiceContract.
>> >>> Container scope is the contract between an implementation and a
>> >>> ScopeContainer and applies to any implementation type that can
>> >>> support stateful interactions. This would include JavaScript,
>> >>> Groovy, C++, ... I think that means that support for state
>> >>> management (which is what scope is configuring) belongs in the
>> core
>> >>> with the configuration metadata supplied by the implementation
>> type.
>> >>>
>> >>
>> >> I don't think it's quite right. First interaction scopes are
>> defined
>> >> on interfaces and not service contracts. Also they control
>> whether
>> >> an interface is conversational or not, independent from any state
>> >> management.
>> >> Anyway I was talking about a different scope, the implementation
>> >> scope defined in the Java C&I spec, which governs the lifecycle of
>> >> Java component implementation instances. I think the definition
>> and
>> >> implementation of lifecycle management will vary greatly
>> depending on
>> >> the component implementation type, for example Java component
>> >> implementations and BPEL component implementations typically deal
>> >> with this in a very different way.
>> > Well, I don't think that's the case at all and actually there is a
>> > concept of implementation scope in assembly - it just varies by
>> > implementation type, which is entirely consistent with our design.
>> > BPEL is the odd case, and this came up as we wrote the scope
>> changes
>> > into the spec (Ken did a lot of the work here). Across many
>> > implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
>> > (maybe even C++) I see use for the same scopes as in Java. Do you
>> > disagree?
>> >
>> > Also, I'm curious why you think the scope containers complicate the
>> > core and need to be moved out? Or are you saying this based on your
>> > reading of the spec? They seem quite simple to me.
>>
>> I'm saying that scope management is specific to the implementation
>> type
>> and therefore needs to be made pluggable, i.e. moved out of core. The
>> Java scope management is just one example of scope management.
>>
>> >
>> >> Therefore, in my view state/lifecycle management should be left to
>> >> the component implementation contributions and not belong to core.
>> >>
>> > I think this would lead to over-complication, particularly for the
>> > extension developer. Right now, scope containers can be reused. In
>> > particular, how would conversational services be handled? If I
>> want to
>> > use module or session scope containers for my Groovy script,
>> then I'd
>> > have to write those rather then just reuse what the core gives me?
>> > Also, be reusing, we also allow an additional extension type in
>> terms
>> > of scope. For example, someone could add a distributed cache
>> scope and
>> > have that shared by Groovy, Java, whatever.
>> >
>> > I'll also note two things. Getting scope containers to work
>> properly
>> > with instance tracking is not trivial. I'd hate to push that on
>> > extension developers. Second, this basic design has been there
>> since
>> > before M1. Why wasn't this brought up before since it is such a
>> > significant issue?
>> >>
>> >>>>
>> >>>> - Java and WSDL interfaces should be defined separate from
>> the core
>> >>>> model, we need to support multiple interface definition
>> languages
>> >>>> supported by plugins, not in the core.
>> >>>
>> >>> The model supports generic IDL through the use of
>> ServiceContract.
>> >>> Java and WSDL are two forms of IDL that are mandated by the
>> >>> specification. This is really just a question of where those
>> >>> implementations are packaged and again I don't think this
>> warrants a
>> >>> rewrite.
>> >>>
>> >>
>> >> Packaging issues are important and often hide bigger
>> >> dependency/coupling problems. I think we should package the
>> support
>> >> for Java and WSDL interfaces separate from the core to prevent any
>> >> coupling between the two, and also give people who will have to
>> >> support new interface definition languages a better template to
>> follow.
>> >>
>> >> Individual issues do not warrant a rewrite. What about the sum of
>> >> many issues?
>> >>
>> > None of the issues warrant a rewrite, not even the sum. Most of
>> your
>> > criticisms seem centered around the model which is fairly decoupled
>> > from the bulk of the core2 runtime. Even if we adopted your changes
>> > wholesale, I'd doubt they would change the core2 runtime
>> > significantly. Even the scope containers could be moved out without
>> > breaking anything and very little code changes, although that
>> would be
>> > a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
>>
>> I am not proposing a rewrite of the whole runtime, see my original
>> email, it's not a whole rewrite. I'm proposing a staged / baby step
>> approach integrating the good work from M1 and the sandbox and new
>> discussions where I think what we have is not right or where new
>> ideas
>> from the group come up.
>>
>> I'm starting with the model SPI because I think that having the
>> assembly
>> model right is critical for an assembly runtime. Most of the ideas
>> here
>> have an impact on the architecture of the runtime, so I thought
>> this was
>> a good starting point, and also a good base of discussion to help
>> all in
>> our community discuss and understand better the new recursive
>> composition model.
>>
>>
>> >>>> - Implementation should extend ComponentType IMO instead of
>> >>>> pointing to it, and we may even be able to simplify and just
>> remove
>> >>>> Implementation. Also I am not sure why we need to distinguish
>> >>>> between AtomicImplementation and CompositeImplementation.
>> >>>
>> >>> One of the problems the assembly spec has is that it is
>> difficult to
>> >>> do top-down design because you cannot link a component to a
>> >>> componentType without having an implementation. I agree this
>> is an
>> >>> area that we (and the spec) need to sort out.
>> >>>
>> >>> IMO a component is associated with one componentType but may have
>> >>> multiple implementations so I don't think they are quite the same
>> >>> thing or that either can be removed.
>> >>>
>> >>> AtomicImplementation is a marker for implementations that cannot
>> >>> have children.
>> >>
>> >> In my view a component has a type. The ComponentType is either
>> >> abstract (just defining the types of services offered, references
>> >> used, and properties that can be configured), or concrete. A POJO
>> >> component implementation is a concrete ComponentType.
>> >>
>> > Perhaps we could walk through your model?
>>
>> Yes, the interfaces I put under m2-design are there to illustrate
>> ideas
>> and support a design discussion. I'm working on some UML diagrams
>> that I
>> think will help too.
>>
>> >>>
>> >>>
>> >>>>
>> >>>> - Support for Composite Includes is missing, this is a
>> significant
>> >>>> part of the recursive composition model (half of it, one of
>> the two
>> >>>> ways to nest composites).
>> >>>
>> >>> It's not really half - it's really just a very small part of the
>> >>> model, comparable to the <import> element we used to support
>> in M1.
>> >>> Again, I don't see why we need to rewrite the model to add
>> this in.
>> >>> Quite the opposite: you've said you've been looking for way to
>> >>> engage and this could be it.
>> >>
>> >> I disagree. Includes are a very significant part of the assembly
>> >> model (the other part is the ability to use a composite as a
>> >> component implementation). Two examples:
>> >> - An included composite is the equivalent of a module fragment
>> in the
>> >> 0.9 spec. This concept is key to allowing a team to work on
>> various
>> >> pieces of an application, split in multiple composites,
>> included in a
>> >> composite representing the application.
>> >> - When (formerly subsystems) composites get deployed to an SCA
>> >> system, they are actually included in that system, rather than
>> being
>> >> used as component implementations.
>> >>
>> > It's not "half" of the recursive model. In fact, most of the
>> time we
>> > spent in the spec group was grappling with other issues related to
>> > recursion.
>>
>> I don't see an immediate relation between the time spent by the spec
>> group on a specific item and its importance for application
>> developers.
>> I am looking at this from an application developer point of view and
>> saying that I'll use Includes as much as composition through
>> (composite)
>> components. Includes will allow a team to distribute work on an SCA
>> application and also represent a key concept for system
>> composition. I
>> am starting to look at scenarios and can actually see the usage of
>> Includes in almost all of them, but having trouble finding good use
>> cases for the other form of composition (nested component
>> implementations). So I stand by my statement that understanding how
>> includes work is key here.
>>
>> >
>> >>>
>> >>>>
>> >>>> This list is not exhaustive... Another idea would be to
>> externalize
>> >>>> support for Composites in a separate plugin not part of the core
>> >>>> service model (since there may be other ways to compose
>> services in
>> >>>> addition to an SCA composite, with Spring or other similar
>> >>>> programming models), I'd like to know what people think about
>> that.
>> >>>>
>> >>>
>> >>> Having the composite implementation type in the core does not
>> >>> preclude that - again, it's just packaging for ease-of-use.
>> >>
>> >> I think it's more significant than packaging. Are you saying
>> that we
>> >> could move the code supporting composites out of core2 without
>> >> breaking the code in core2?
>> >>
>> > Why would we do this? We can already support multiple composite
>> > implementation types - have a look at the Spring extension. That
>> just
>> > sounds like unnecessary complication.
>> Why? to avoid unecessary and dangerous coupling that will hurt us
>> when
>> we try to evolve this runtime. How to illustrate that? how about
>> trying
>> to move code supporting composites out of core2? I'm realizing I'm
>> asking the same question again... but I think it's an important
>> question, sill unanswered.
>>
>> >
>> >>
>> >>>
>> >>> You seem to have the impression that the core is sealed and
>> that we
>> >>> only support things that are included within it. That is not the
>> >>> case. The only place we need things bundled with the core is
>> in the
>> >>> bootstrap phase - specifically, we need them bundled with the
>> >>> primordial deployer. The actual runtime is created from the SCDL
>> >>> passed to that primordial deployer, can contain any mix of
>> >>> components and need not contain any of the infrastructure used to
>> >>> boot it.
>> >>>
>> >>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>> >>>> new interfaces. This is just an initial strawman to trigger a
>> >>>> constructive discussion and ideas on how to best represent the
>> >>>> recursive model. I also need help to define a scenario (not unit
>> >>>> test cases, but an end to end sample application) to help put
>> the
>> >>>> recursive composition model in perspective and make sure we all
>> >>>> understand it the same way.
>> >>>>
>> >>>
>> >>> I am troubled that you have chosen to start on your own
>> codebase at
>> >>> a time when most of us have been trying to have constructive
>> >>> discussion on this list. Based on the approach you proposed in
>> your
>> >>> original email I would have hoped that we could have started with
>> >>> your end-user scenarios and had a chance to explore how they
>> could
>> >>> be supported by M1, the sandbox, or some other code before
>> starting
>> >>> another codebase. I'm disappointed that, having started this very
>> >>> thread nearly a week ago with the premise of community, your
>> first
>> >>> response on it was to commit a large chunk of independent code
>> >>> rather than follow up with any of the other people who have
>> already
>> >>> contributed to the discussion.
>> >>>
>> >>> I think discussion led to compromise and consensus on the
>> >>> scenario-driven approach that you proposed. As shown above and in
>> >>> other recent threads, there's plenty of room for improvements
>> and/or
>> >>> new features in our current code and a willingness to discuss
>> them,
>> >>> albeit in terms of technical merit rather than personal
>> opinion. I
>> >>> hope you can find a way to join in rather than forge your own
>> path.
>> >>>
>> >>> --Jeremy
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >> --Jean-Sebastien
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>>
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Proposed approach for M2
Posted by Kevin Williams <ke...@qwest.net>.
I have not contributed to either the trunk or sandbox SCA code streams
so I hope you do not mind me commenting on this issue. I wonder if some
compromise could be reached at this point since I am certain the project
will suffer otherwise. Instead of starting from scratch, could we start
with a few foundation components from core2 and build incrementally from
there?
Thanks,
--Kevin
Jeremy Boynes wrote:
> Ant
>
> I'm disappointed that you have chosen this path. I will ask one more
> time if you and Sebastien would consider collaborating with those of
> us working on core2.
>
> --
> Jeremy
>
> On Jul 7, 2006, at 11:53 PM, ant elder wrote:
>
>> Sebastien, lets just do it...this debate is going no where and as
>> choosing
>> with a vote wasn't popular lets try your approach and see how it works.
>> After a couple of weeks take a checkpoint and decide whether or not to
>> continue. I don't like working in other peoples sandbox so I've
>> created a
>> folder named miral and as a start copied your model.spi folder
>> there. We'll
>> all have to be dedicated and hard working so as to quickly get
>> something
>> going which demonstrates that this is the best way forward. I'm up
>> for it,
>> how about the rest of you?
>>
>> https://svn.apache.org/repos/asf/incubator/tuscany/miral/
>>
>> ...ant
>>
>> On 7/7/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>>>
>>> More comments inline.
>>>
>>> Jim Marino wrote:
>>> > Comments inline
>>> > On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
>>> >
>>> >> Jeremy,
>>> >>
>>> >> I won't comment on your attacks at the bottom of this email. I was
>>> >> hoping for a more constructive technical discussion. I added my
>>> >> answers and comments on the specific technical issues inline.
>>> >>
>>> >> Jeremy Boynes wrote:
>>> >>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>>> >>>>
>>> >>>> My proposal is not to merge M1 and the core2 sandbox. I am
>>> >>>> proposing to start a new fresh code stream and build the runtime
>>> >>>> through baby steps. We may be able to reuse some pieces of
>>> existing
>>> >>>> code, but more important is to engage our community in this
>>> >>>> exercise and integrate the new ideas that will emerge from this.
>>> >>>>
>>> >>>
>>> >>> I don't believe the two issues are necessarily coupled. Quite a
>>> few
>>> >>> members of the community are engaged on the sandbox code
>>> already and
>>> >>> we could work with you to improve that rather having to throw
>>> >>> everything out and start over with all new ideas.
>>> >>>
>>> >>>>
>>> >>>> Here's an example where I'm struggling with both M1 and the core2
>>> >>>> sandbox and thinking that we can do better if we start with a new
>>> >>>> fresh stream: our (recursive) assembly metadata model.
>>> >>>>
>>> >>>> - M1 does not implement the recursive composition model and would
>>> >>>> require significant changes to support it. Core2 is an attempt to
>>> >>>> implement it but I'm not sure it's quite right, and also think
>>> that
>>> >>>> it can be simplified.
>>> >>>
>>> >>> It would really help if you could come up with concrete areas
>>> where
>>> >>> it is not right or where it could be simplified - for example, end
>>> >>> user scenarios that are not supported.
>>> >>>
>>> >>>>
>>> >>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>>> >>>> think M1 was better since it allowed to keep the order in the
>>> >>>> relationships.
>>> >>>
>>> >>> There's nothing I remember in the assembly spec where order
>>> matters.
>>> >>> On the other hand there are many areas where things are keyed by a
>>> >>> name which has to be unique. This seems like a natural mapping
>>> >>> (sorry) to a Map. In M1 I started to move toward simple map
>>> >>> structures but you replaced it with what seemed like a fairly
>>> >>> complicated specialized List implementation that sent
>>> notifications
>>> >>> that updated a Map anyway. Given the desire for simplification,
>>> are
>>> >>> there any end-user scenarios that require ordering to be preserved
>>> >>> and that can't be supported with a basic HashMap or LinkedHashMap?
>>> >>>
>>> >> As an administrator I'll want my administration tool to display
>>> >> components displayed in the order I declared them in SCDL.
>>> > SCDL isn't the only form assembly can be serialized to/from.
>>> Also, if
>>> > I were an admin, I'd probably want to sort the components
>>> according to
>>> > some useful criteria, not how they are listed in a SCDL as most
>>> admins
>>> > will never look at XML. One could always use LikedHashMap though.
>>> >
>>> Maybe SCDL isn't the only form but this is not relevant, we need to
>>> support SCDL don't we? As soon as you put assembly elements in a
>>> document that a user/developer can edit the order is relevant.
>>>
>>> I disagree with your statement about administrators. They often
>>> look at
>>> and work with XML configuration files. If you want to support other
>>> sort
>>> criteria in addition that's fine, but admin, config and editing tools
>>> need to at least support the order from the XML document.
>>>
>>> >> I'll also want a configuration or admin tool loading/saving
>>> modified
>>> >> SCDL to write things in the order that they were initially, not
>>> in a
>>> >> random order. As an application developer I'd like to have an SCA
>>> >> debugging tool showing me my components in a list in the right
>>> order
>>> >> as well. Also if I want to implement the model defined by the XML
>>> >> schemas in the spec using any of the DataBinding technologies out
>>> >> there, I'll end up with Lists, not Maps.
>>> >>
>>> > We have been using StAX just fine for this and it accommodates a
>>> > number of databinding solutions for extensions. Are you proposing we
>>> > revisit this decision made back before the M1 release to go with
>>> STaX
>>> > loading? If so, for what reasons? BTW, not all databinding solutions
>>> > will have problems - XStream will work just fine with what we have.
>>> > Also, are you sure about XMLBeans and JAXB or are you just speaking
>>> > about a current implementation of SDO?
>>>
>>> Not quite correct, the decision we made back before M1 was to go with
>>> StAX loading, write the loaders by hand for now, and see how the SDO
>>> team could generate this code after M1. Independent of that, I don't
>>> want to tie us to any specific data binding, so we better pick
>>> representations for model relationships that are commonly used by most
>>> databindings to represent XSD <element... maxOccurs="unbounded"/>,
>>> i.e.
>>> Lists, not Maps.
>>>
>>> >
>>> >> Finally even if we decided to use Maps in some cases to provide
>>> keyed
>>> >> access to some elements of the model, we'd have to do it
>>> differently.
>>> >> For example a single Map containing all components, references and
>>> >> services in a composite (according to the spec they cannot have the
>>> >> same names) instead of three Maps like you have in Core2.
>>> >>
>>> And this is why LinkedHashMap will not help you here.
>>>
>>> >>>>
>>> >>>> - Core2 only defines implementation classes for the model, I
>>> think
>>> >>>> we should have interfaces + default implementation classes
>>> instead,
>>> >>>> like we had in M1, to allow for alternate implementations of the
>>> >>>> model.
>>> >>>
>>> >>> One of the most complex things with the M1 model was all the
>>> >>> interfaces involved, the need to pass factory implementations
>>> >>> around, the number of different factories involved (one per
>>> >>> extension implementation) and the potential issues with code
>>> >>> assuming its implementation of the factory was the one used.
>>> >>>
>>> >>> The core2 model uses concrete classes which are really just data
>>> >>> holders - there's no behaviour in them to be abstracted through
>>> the
>>> >>> interface. This gives a much simpler programming model for
>>> >>> extensions using the model.
>>> >>>
>>> >>> Do you have any scenarios that would require different
>>> >>> implementations of the model? Are they so different that they
>>> might
>>> >>> as well just use different classes?
>>> >>>
>>> >>
>>> >> I don't think that having just implementation classes is much
>>> >> simpler. If you interact with the model SPI, reading interfaces is
>>> >> simpler IMO and more suitable for inclusion in a specification
>>> >> document... allowing multiple implementations of these interfaces.
>>> >> Also we have to support the whole lifecycle of an SCA application
>>> >> (development, deploy/install, runtime, admin etc.) and I'd like to
>>> >> allow some flexibility for different tools, running at different
>>> >> times to use different implementations of the assembly model
>>> interfaces.
>>> >>
>>> > Oisin from the STP project said the POJO based approach would suit
>>> > them just fine. I don't see the complexity. On the contrary, all of
>>> > the AssemblyFactories we had in M1 lead IMO to a massive antipattern
>>> > where they were passed throughout the core. I'm happy to walk
>>> through
>>> > the relevant code if people are interested. All the factories did
>>> was
>>> > new up a POJO. Not worth the complexity in my opinion but I'm
>>> happy to
>>> > compare the work in the sandbox with your proposal if you'd like to
>>> > walk us through it.
>>>
>>> When the runtime depends on too many factories, this is the
>>> manifestation of bigger coupling problems. The factories for all the
>>> extensions should not be visible at all from the core runtime, and
>>> if we
>>> externalize the WSDL and Java interface support and the Java
>>> implementation support our of core like I'm proposing, you're not
>>> dealing with many factories.
>>>
>>> I am sure that tooling projects will need to add much to this model,
>>> support for events, change tracking, tracking between XML elements and
>>> model objects to provider proper feedback to application developers,
>>> integration with modeling technologies used in the tooling world,
>>> support for cloning maybe... tons of things. I spent several years
>>> developing tools so I think I know what I'm talking about here. The
>>> first thing I'll ask as a tooling developer is: please give me
>>> interfaces so I can hook what I need in the implementations.
>>>
>>> I'm happy to walk people through the interfaces or answer any
>>> questions
>>> on the list,
>>>
>>> >>>>
>>> >>>> - Over usage of Java Generics breaks flexibility in some
>>> cases, for
>>> >>>> example Component<I extends Implementation> will force you to
>>> >>>> recreate an instance of Component to swap its implementation with
>>> >>>> an implementation of a different type (and lose all the wires
>>> going
>>> >>>> in/out of the component).
>>> >>>
>>> >>> There may be cases where generics may be overkill but I don't
>>> think
>>> >>> that really requires us to throw out the model. There are other
>>> >>> cases where the use of wildcards would be appropriate; for
>>> example,
>>> >>> in the scenario you give here you could just create a
>>> >>> Component<Implementation> to allow different types of
>>> implementation
>>> >>> to be used.
>>> >>>
>>> >> Then instead of
>>> >> Component<Implementation> {
>>> >> Implementation getImplementation();
>>> >> }
>>> >> I think we can just do
>>> >> Component {
>>> >> Implementation getImplementation();
>>> >> }
>>> >> What we have now in core2 is overkill IMO.
>>> >>
>>> > then do we need to cast to the right impl type?
>>>
>>> The core runtime should not have to cast, simply because it should not
>>> depend on any component implementation type (not even the Java or
>>> System
>>> implementation types).
>>>
>>> >
>>> >>>>
>>> >>>> - Core2 defines ReferenceDefinitions (without bindings) and
>>> >>>> BoundReferenceDefinitions (with bindings). IMO there are
>>> Reference
>>> >>>> types and Reference instances and both can have bindings.
>>> >>>> or Reference.
>>> >>>
>>> >>> I'm with you here - we need to refactor the way bindings are
>>> handled
>>> >>> for both Service and Reference. One thing the sandbox model is
>>> >>> missing is the ability to associate multiple bindings with a
>>> single
>>> >>> Service/Reference.
>>> >>
>>> >> My main point is not about supporting multiple bindings on a
>>> Service
>>> >> or Reference. I think this is secondary and the interfaces I put in
>>> >> my sandbox to support a design discussion don't even have that
>>> >> either. My point is that Services, References, and their
>>> >> instantiation by Components are at the foundation of the SCA
>>> assembly
>>> >> model... and therefore need to be modeled correctly. I'm
>>> proposing a
>>> >> different design, illustrated by the interfaces I checked in.
>>> >>
>>> > Could you elaborate?
>>>
>>> I think it should be very simple:
>>> - Component types have service and reference types
>>> - Components are instances of component types and have services and
>>> references, which are instances of the service and reference types
>>> - Service and reference types can have bindings
>>> - Bindings can be overriden in service and reference instances
>>> This is clear when you look at a Composite. A composite is a Component
>>> Type, has service and reference types (aka composite services and
>>> references) which can have bindings.
>>> A component can be implemented by a Composite, has services and
>>> references, which can use the (default) bindings from their respective
>>> service and reference types, or specify (override) bindings.
>>>
>>> >>>
>>> >>>>
>>> >>>> - I think that Remotable should be on Interface and not Service.
>>> >>>
>>> >>> I agree Service is wrong and that it should be on ServiceContract.
>>> >>> Thanks for catching it.
>>> >>>
>>> >>>>
>>> >>>> - Scope should be defined in the Java component implementation,
>>> >>>> separate from the core model.
>>> >>>
>>> >>> Scope is not a Java specific concept.
>>> >>> Interaction scope (stateless vs. stateful) can apply to any
>>> >>> ServiceContract.
>>> >>> Container scope is the contract between an implementation and a
>>> >>> ScopeContainer and applies to any implementation type that can
>>> >>> support stateful interactions. This would include JavaScript,
>>> >>> Groovy, C++, ... I think that means that support for state
>>> >>> management (which is what scope is configuring) belongs in the
>>> core
>>> >>> with the configuration metadata supplied by the implementation
>>> type.
>>> >>>
>>> >>
>>> >> I don't think it's quite right. First interaction scopes are
>>> defined
>>> >> on interfaces and not service contracts. Also they control whether
>>> >> an interface is conversational or not, independent from any state
>>> >> management.
>>> >> Anyway I was talking about a different scope, the implementation
>>> >> scope defined in the Java C&I spec, which governs the lifecycle of
>>> >> Java component implementation instances. I think the definition and
>>> >> implementation of lifecycle management will vary greatly
>>> depending on
>>> >> the component implementation type, for example Java component
>>> >> implementations and BPEL component implementations typically deal
>>> >> with this in a very different way.
>>> > Well, I don't think that's the case at all and actually there is a
>>> > concept of implementation scope in assembly - it just varies by
>>> > implementation type, which is entirely consistent with our design.
>>> > BPEL is the odd case, and this came up as we wrote the scope changes
>>> > into the spec (Ken did a lot of the work here). Across many
>>> > implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
>>> > (maybe even C++) I see use for the same scopes as in Java. Do you
>>> > disagree?
>>> >
>>> > Also, I'm curious why you think the scope containers complicate the
>>> > core and need to be moved out? Or are you saying this based on your
>>> > reading of the spec? They seem quite simple to me.
>>>
>>> I'm saying that scope management is specific to the implementation
>>> type
>>> and therefore needs to be made pluggable, i.e. moved out of core. The
>>> Java scope management is just one example of scope management.
>>>
>>> >
>>> >> Therefore, in my view state/lifecycle management should be left to
>>> >> the component implementation contributions and not belong to core.
>>> >>
>>> > I think this would lead to over-complication, particularly for the
>>> > extension developer. Right now, scope containers can be reused. In
>>> > particular, how would conversational services be handled? If I
>>> want to
>>> > use module or session scope containers for my Groovy script, then
>>> I'd
>>> > have to write those rather then just reuse what the core gives me?
>>> > Also, be reusing, we also allow an additional extension type in
>>> terms
>>> > of scope. For example, someone could add a distributed cache
>>> scope and
>>> > have that shared by Groovy, Java, whatever.
>>> >
>>> > I'll also note two things. Getting scope containers to work properly
>>> > with instance tracking is not trivial. I'd hate to push that on
>>> > extension developers. Second, this basic design has been there since
>>> > before M1. Why wasn't this brought up before since it is such a
>>> > significant issue?
>>> >>
>>> >>>>
>>> >>>> - Java and WSDL interfaces should be defined separate from the
>>> core
>>> >>>> model, we need to support multiple interface definition languages
>>> >>>> supported by plugins, not in the core.
>>> >>>
>>> >>> The model supports generic IDL through the use of ServiceContract.
>>> >>> Java and WSDL are two forms of IDL that are mandated by the
>>> >>> specification. This is really just a question of where those
>>> >>> implementations are packaged and again I don't think this
>>> warrants a
>>> >>> rewrite.
>>> >>>
>>> >>
>>> >> Packaging issues are important and often hide bigger
>>> >> dependency/coupling problems. I think we should package the support
>>> >> for Java and WSDL interfaces separate from the core to prevent any
>>> >> coupling between the two, and also give people who will have to
>>> >> support new interface definition languages a better template to
>>> follow.
>>> >>
>>> >> Individual issues do not warrant a rewrite. What about the sum of
>>> >> many issues?
>>> >>
>>> > None of the issues warrant a rewrite, not even the sum. Most of your
>>> > criticisms seem centered around the model which is fairly decoupled
>>> > from the bulk of the core2 runtime. Even if we adopted your changes
>>> > wholesale, I'd doubt they would change the core2 runtime
>>> > significantly. Even the scope containers could be moved out without
>>> > breaking anything and very little code changes, although that
>>> would be
>>> > a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
>>>
>>> I am not proposing a rewrite of the whole runtime, see my original
>>> email, it's not a whole rewrite. I'm proposing a staged / baby step
>>> approach integrating the good work from M1 and the sandbox and new
>>> discussions where I think what we have is not right or where new ideas
>>> from the group come up.
>>>
>>> I'm starting with the model SPI because I think that having the
>>> assembly
>>> model right is critical for an assembly runtime. Most of the ideas
>>> here
>>> have an impact on the architecture of the runtime, so I thought
>>> this was
>>> a good starting point, and also a good base of discussion to help
>>> all in
>>> our community discuss and understand better the new recursive
>>> composition model.
>>>
>>>
>>> >>>> - Implementation should extend ComponentType IMO instead of
>>> >>>> pointing to it, and we may even be able to simplify and just
>>> remove
>>> >>>> Implementation. Also I am not sure why we need to distinguish
>>> >>>> between AtomicImplementation and CompositeImplementation.
>>> >>>
>>> >>> One of the problems the assembly spec has is that it is
>>> difficult to
>>> >>> do top-down design because you cannot link a component to a
>>> >>> componentType without having an implementation. I agree this is an
>>> >>> area that we (and the spec) need to sort out.
>>> >>>
>>> >>> IMO a component is associated with one componentType but may have
>>> >>> multiple implementations so I don't think they are quite the same
>>> >>> thing or that either can be removed.
>>> >>>
>>> >>> AtomicImplementation is a marker for implementations that cannot
>>> >>> have children.
>>> >>
>>> >> In my view a component has a type. The ComponentType is either
>>> >> abstract (just defining the types of services offered, references
>>> >> used, and properties that can be configured), or concrete. A POJO
>>> >> component implementation is a concrete ComponentType.
>>> >>
>>> > Perhaps we could walk through your model?
>>>
>>> Yes, the interfaces I put under m2-design are there to illustrate
>>> ideas
>>> and support a design discussion. I'm working on some UML diagrams
>>> that I
>>> think will help too.
>>>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>> - Support for Composite Includes is missing, this is a
>>> significant
>>> >>>> part of the recursive composition model (half of it, one of
>>> the two
>>> >>>> ways to nest composites).
>>> >>>
>>> >>> It's not really half - it's really just a very small part of the
>>> >>> model, comparable to the <import> element we used to support in
>>> M1.
>>> >>> Again, I don't see why we need to rewrite the model to add this
>>> in.
>>> >>> Quite the opposite: you've said you've been looking for way to
>>> >>> engage and this could be it.
>>> >>
>>> >> I disagree. Includes are a very significant part of the assembly
>>> >> model (the other part is the ability to use a composite as a
>>> >> component implementation). Two examples:
>>> >> - An included composite is the equivalent of a module fragment
>>> in the
>>> >> 0.9 spec. This concept is key to allowing a team to work on various
>>> >> pieces of an application, split in multiple composites, included
>>> in a
>>> >> composite representing the application.
>>> >> - When (formerly subsystems) composites get deployed to an SCA
>>> >> system, they are actually included in that system, rather than
>>> being
>>> >> used as component implementations.
>>> >>
>>> > It's not "half" of the recursive model. In fact, most of the time we
>>> > spent in the spec group was grappling with other issues related to
>>> > recursion.
>>>
>>> I don't see an immediate relation between the time spent by the spec
>>> group on a specific item and its importance for application
>>> developers.
>>> I am looking at this from an application developer point of view and
>>> saying that I'll use Includes as much as composition through
>>> (composite)
>>> components. Includes will allow a team to distribute work on an SCA
>>> application and also represent a key concept for system composition. I
>>> am starting to look at scenarios and can actually see the usage of
>>> Includes in almost all of them, but having trouble finding good use
>>> cases for the other form of composition (nested component
>>> implementations). So I stand by my statement that understanding how
>>> includes work is key here.
>>>
>>> >
>>> >>>
>>> >>>>
>>> >>>> This list is not exhaustive... Another idea would be to
>>> externalize
>>> >>>> support for Composites in a separate plugin not part of the core
>>> >>>> service model (since there may be other ways to compose
>>> services in
>>> >>>> addition to an SCA composite, with Spring or other similar
>>> >>>> programming models), I'd like to know what people think about
>>> that.
>>> >>>>
>>> >>>
>>> >>> Having the composite implementation type in the core does not
>>> >>> preclude that - again, it's just packaging for ease-of-use.
>>> >>
>>> >> I think it's more significant than packaging. Are you saying
>>> that we
>>> >> could move the code supporting composites out of core2 without
>>> >> breaking the code in core2?
>>> >>
>>> > Why would we do this? We can already support multiple composite
>>> > implementation types - have a look at the Spring extension. That
>>> just
>>> > sounds like unnecessary complication.
>>> Why? to avoid unecessary and dangerous coupling that will hurt us when
>>> we try to evolve this runtime. How to illustrate that? how about
>>> trying
>>> to move code supporting composites out of core2? I'm realizing I'm
>>> asking the same question again... but I think it's an important
>>> question, sill unanswered.
>>>
>>> >
>>> >>
>>> >>>
>>> >>> You seem to have the impression that the core is sealed and
>>> that we
>>> >>> only support things that are included within it. That is not the
>>> >>> case. The only place we need things bundled with the core is in
>>> the
>>> >>> bootstrap phase - specifically, we need them bundled with the
>>> >>> primordial deployer. The actual runtime is created from the SCDL
>>> >>> passed to that primordial deployer, can contain any mix of
>>> >>> components and need not contain any of the infrastructure used to
>>> >>> boot it.
>>> >>>
>>> >>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>> >>>> new interfaces. This is just an initial strawman to trigger a
>>> >>>> constructive discussion and ideas on how to best represent the
>>> >>>> recursive model. I also need help to define a scenario (not unit
>>> >>>> test cases, but an end to end sample application) to help put the
>>> >>>> recursive composition model in perspective and make sure we all
>>> >>>> understand it the same way.
>>> >>>>
>>> >>>
>>> >>> I am troubled that you have chosen to start on your own
>>> codebase at
>>> >>> a time when most of us have been trying to have constructive
>>> >>> discussion on this list. Based on the approach you proposed in
>>> your
>>> >>> original email I would have hoped that we could have started with
>>> >>> your end-user scenarios and had a chance to explore how they could
>>> >>> be supported by M1, the sandbox, or some other code before
>>> starting
>>> >>> another codebase. I'm disappointed that, having started this very
>>> >>> thread nearly a week ago with the premise of community, your first
>>> >>> response on it was to commit a large chunk of independent code
>>> >>> rather than follow up with any of the other people who have
>>> already
>>> >>> contributed to the discussion.
>>> >>>
>>> >>> I think discussion led to compromise and consensus on the
>>> >>> scenario-driven approach that you proposed. As shown above and in
>>> >>> other recent threads, there's plenty of room for improvements
>>> and/or
>>> >>> new features in our current code and a willingness to discuss
>>> them,
>>> >>> albeit in terms of technical merit rather than personal opinion. I
>>> >>> hope you can find a way to join in rather than forge your own
>>> path.
>>> >>>
>>> >>> --Jeremy
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >> --Jean-Sebastien
>>> >>
>>> >>
>>> >>
>>> ---------------------------------------------------------------------
>>> >> 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
>>> >
>>> >
>>>
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Bigbank application, was Rules for Revolutionaries
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Rick wrote:
> If there are no issues I'd like to look at the bigbank sample
> converting to the new composite spec. Besides the obvious need to
> change the SCDL, I suppose refactoring the server (account) side to
> take advantage of the composite nature maybe see if includes can be
> used too. Was there immediately more that you were thinking of ?
>
> Jean-Sebastien Delfino wrote:
>> Simon Nash wrote:
>>> Thanks, Sam; this is very helpful. One part in particular of the
>>> James Duncan Davidson post caught my eye:
>>>
>>> <jdd>
>>> 4) The trunk is the official versioned line of the project. All
>>> evolutionary minded people are welcome to work on it to improve it.
>>> Evolutionary work is important and should not stop as it is always
>>> unclear when any particular revolution will be ready for prime time
>>> or whether it will be officially accepted.
>>> </jdd>
>>>
>>> I think we have failed to follow this guideline over recent weeks.
>>> People have submitted patches for the trunk and they have not been
>>> applied (or applied to a sandbox instead). Technical discussions
>>> have started that in the normal course of events would have led to
>>> commits and patches, but these commits and patches have not been
>>> forthcoming. This has generally led to progress on the project
>>> (except for sandbox activity) being stalled, presumably because
>>> people were waiting to see what would happen with the sandbox code.
>>>
>>> I believe we need to get the project moving forward again. At the
>>> present time, we have an evolutionary trunk and a revolutionary
>>> sandbox. We should therefore continue (in reality restart) doing
>>> evolutionary work on the trunk for the reasons that JDD gives in
>>> the quote above. There is evolutionary work that can usefully
>>> be done, such as Raymond's work on databindings, the work on
>>> interface represenation that Ant and others have been discussing,
>>> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
>>> there are other things too. If at some point there is a revolution,
>>> then we will deal with it when it happens and rework existing code
>>> as necessary.
>>>
>>> Revolutionaries can work in the "chianti" sandbox, or if they
>>> prefer a different brand of revolution, they can create another
>>> sandbox to do this. The latter is perfectly legitimate according
>>> to the Rules for Revolutionaries, and I think it is healthy for
>>> the project for people to be able to show their new ideas in the
>>> form of code, as long as the project as a whole (i.e., the whole
>>> community) keeps moving forward with ongoing work on the trunk
>>> and doesn't focus exclusively on what is happening in the
>>> sandboxes.
>>>
>>> Simon
>>>
>>> Sam Ruby wrote:
>>>
>>>> Jeremy Boynes wrote:
>>>>
>>>>> Ant
>>>>>
>>>>> I'm disappointed that you have chosen this path. I will ask one
>>>>> more time if you and Sebastien would consider collaborating with
>>>>> those of us working on core2.
>>>>
>>>>
>>>> A while ago, I agreed to be a mentor for this project. I guess it
>>>> is about time that I start acting like one.
>>>>
>>>> If this project ever hopes to exit incubation, it had better start
>>>> acting like an ASF project. For starters, I suggest that all
>>>> committers read the Rules for Revolutionaries[1][2][3].
>>>>
>>>> For those who want the Cliff notes version: anybody who wants to
>>>> work in an evolutionary fashion on the main trunk is welcome to do
>>>> so. Anybody who wants to work on a revolutionary branch is welcome
>>>> to do so. Multiple concurrent revolutionary branches are OK too.
>>>>
>>>> One thing that is decidedly NOT OK is to include a version number
>>>> in the name, as it causes friction. Hence, I'd suggest that
>>>> "core2" immediately get renamed to something that neither reflects
>>>> the term "core" or the number "2".
>>>>
>>>> Something implicit in the R4R document is that the burden of proof
>>>> is on the revolutionaries. If you would like to see your
>>>> particular branch merged back onto the trunk, be prepared to
>>>> demonstrate why your particular branch is not merely better, but
>>>> necessary. My experience it that the more concrete and the less
>>>> hand-wavy the argument, the more likely it will be accepted. So,
>>>> if you chose to believe that scenarios and test cases are optional,
>>>> just remember, merging your sandbox back to the trunk is optional
>>>> too. That does not mean that scenarios and test cases are
>>>> required, but it does mean that if these aren't present, you need
>>>> to come up with something just as compelling.
>>>>
>>>> - Sam Ruby
>>>>
>>>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>>>> [3]
>>>> http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>> Simon,
>>
>> I agree. I'm going to do some work on the samples in the trunk, I'd
>> like to evolve some of them (starting with the Calculator sample and
>> then Bigbank) to start showing some of the concepts in the evolving
>> SCA specification.
>>
>> In addition, I searched through our JIRA backlog and found the
>> following patches, which should be reviewed and potentially applied
>> to the trunk:
>> TUSCANY-120 - Java2WSDL patches to generate correct XSDs
>> TUSCANY-454 - Fixes WSDLs in some of the samples
>> TUSCANY-457 - Fixes an NPE in TuscanyContextListener
>> TUSCANY-477 - Improve unresolved type error handling
>> TUSCANY-520 - Fixes build to handle folder names containing spaces
>> TUSCANY-535 - Implements XSDHelper.generate()
>>
>> I'm going to start by looking at TUSCANY-120.
>>
>> I may have missed some patches (I wished JIRA had a query listing all
>> issues with pending patches...) so could people waiting for their
>> patches to be reviewed and applied please speak up and point us to
>> the JIRA issue numbers? Thanks.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Rick,
Sounds like a good plan, we could port the SCDL first and adjust to the
new APIs (for example ModuleContext becomes CompositeContext). After
this first pass, I suggest to write a Composite around the bigbank
moduleComponents (equivalent to an SCA 0.9 subsystem), and maybe also
use composite includes and/or nested composite implementations inside
the account composite.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Rick <cr...@gmail.com>.
If there are no issues I'd like to look at the bigbank sample converting
to the new composite spec. Besides the obvious need to change the
SCDL, I suppose refactoring the server (account) side to take advantage
of the composite nature maybe see if includes can be used too. Was
there immediately more that you were thinking of ?
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>> Thanks, Sam; this is very helpful. One part in particular of the
>> James Duncan Davidson post caught my eye:
>>
>> <jdd>
>> 4) The trunk is the official versioned line of the project. All
>> evolutionary minded people are welcome to work on it to improve it.
>> Evolutionary work is important and should not stop as it is always
>> unclear when any particular revolution will be ready for prime time
>> or whether it will be officially accepted.
>> </jdd>
>>
>> I think we have failed to follow this guideline over recent weeks.
>> People have submitted patches for the trunk and they have not been
>> applied (or applied to a sandbox instead). Technical discussions
>> have started that in the normal course of events would have led to
>> commits and patches, but these commits and patches have not been
>> forthcoming. This has generally led to progress on the project
>> (except for sandbox activity) being stalled, presumably because
>> people were waiting to see what would happen with the sandbox code.
>>
>> I believe we need to get the project moving forward again. At the
>> present time, we have an evolutionary trunk and a revolutionary
>> sandbox. We should therefore continue (in reality restart) doing
>> evolutionary work on the trunk for the reasons that JDD gives in
>> the quote above. There is evolutionary work that can usefully
>> be done, such as Raymond's work on databindings, the work on
>> interface represenation that Ant and others have been discussing,
>> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
>> there are other things too. If at some point there is a revolution,
>> then we will deal with it when it happens and rework existing code
>> as necessary.
>>
>> Revolutionaries can work in the "chianti" sandbox, or if they
>> prefer a different brand of revolution, they can create another
>> sandbox to do this. The latter is perfectly legitimate according
>> to the Rules for Revolutionaries, and I think it is healthy for
>> the project for people to be able to show their new ideas in the
>> form of code, as long as the project as a whole (i.e., the whole
>> community) keeps moving forward with ongoing work on the trunk
>> and doesn't focus exclusively on what is happening in the
>> sandboxes.
>>
>> Simon
>>
>> Sam Ruby wrote:
>>
>>> Jeremy Boynes wrote:
>>>
>>>> Ant
>>>>
>>>> I'm disappointed that you have chosen this path. I will ask one
>>>> more time if you and Sebastien would consider collaborating with
>>>> those of us working on core2.
>>>
>>>
>>> A while ago, I agreed to be a mentor for this project. I guess it
>>> is about time that I start acting like one.
>>>
>>> If this project ever hopes to exit incubation, it had better start
>>> acting like an ASF project. For starters, I suggest that all
>>> committers read the Rules for Revolutionaries[1][2][3].
>>>
>>> For those who want the Cliff notes version: anybody who wants to
>>> work in an evolutionary fashion on the main trunk is welcome to do
>>> so. Anybody who wants to work on a revolutionary branch is welcome
>>> to do so. Multiple concurrent revolutionary branches are OK too.
>>>
>>> One thing that is decidedly NOT OK is to include a version number in
>>> the name, as it causes friction. Hence, I'd suggest that "core2"
>>> immediately get renamed to something that neither reflects the term
>>> "core" or the number "2".
>>>
>>> Something implicit in the R4R document is that the burden of proof
>>> is on the revolutionaries. If you would like to see your particular
>>> branch merged back onto the trunk, be prepared to demonstrate why
>>> your particular branch is not merely better, but necessary. My
>>> experience it that the more concrete and the less hand-wavy the
>>> argument, the more likely it will be accepted. So, if you chose to
>>> believe that scenarios and test cases are optional, just remember,
>>> merging your sandbox back to the trunk is optional too. That does
>>> not mean that scenarios and test cases are required, but it does
>>> mean that if these aren't present, you need to come up with
>>> something just as compelling.
>>>
>>> - Sam Ruby
>>>
>>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>>> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>>
>>
> Simon,
>
> I agree. I'm going to do some work on the samples in the trunk, I'd
> like to evolve some of them (starting with the Calculator sample and
> then Bigbank) to start showing some of the concepts in the evolving
> SCA specification.
>
> In addition, I searched through our JIRA backlog and found the
> following patches, which should be reviewed and potentially applied to
> the trunk:
> TUSCANY-120 - Java2WSDL patches to generate correct XSDs
> TUSCANY-454 - Fixes WSDLs in some of the samples
> TUSCANY-457 - Fixes an NPE in TuscanyContextListener
> TUSCANY-477 - Improve unresolved type error handling
> TUSCANY-520 - Fixes build to handle folder names containing spaces
> TUSCANY-535 - Implements XSDHelper.generate()
>
> I'm going to start by looking at TUSCANY-120.
>
> I may have missed some patches (I wished JIRA had a query listing all
> issues with pending patches...) so could people waiting for their
> patches to be reviewed and applied please speak up and point us to the
> JIRA issue numbers? Thanks.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Calculator sample
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 12, 2006, at 3:07 PM, Jean-Sebastien Delfino wrote:
>
> I agree. I'm going to do some work on the samples in the trunk, I'd
> like to evolve some of them (starting with the Calculator sample
> and then Bigbank) to start showing some of the concepts in the
> evolving SCA specification.
If it helps, I ported the calculator sample to chianti.
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/chianti/
sca/samples/calculator
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Thanks, Sam; this is very helpful. One part in particular of the
> James Duncan Davidson post caught my eye:
>
> <jdd>
> 4) The trunk is the official versioned line of the project. All
> evolutionary minded people are welcome to work on it to improve it.
> Evolutionary work is important and should not stop as it is always
> unclear when any particular revolution will be ready for prime time
> or whether it will be officially accepted.
> </jdd>
>
> I think we have failed to follow this guideline over recent weeks.
> People have submitted patches for the trunk and they have not been
> applied (or applied to a sandbox instead). Technical discussions
> have started that in the normal course of events would have led to
> commits and patches, but these commits and patches have not been
> forthcoming. This has generally led to progress on the project
> (except for sandbox activity) being stalled, presumably because
> people were waiting to see what would happen with the sandbox code.
>
> I believe we need to get the project moving forward again. At the
> present time, we have an evolutionary trunk and a revolutionary
> sandbox. We should therefore continue (in reality restart) doing
> evolutionary work on the trunk for the reasons that JDD gives in
> the quote above. There is evolutionary work that can usefully
> be done, such as Raymond's work on databindings, the work on
> interface represenation that Ant and others have been discussing,
> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
> there are other things too. If at some point there is a revolution,
> then we will deal with it when it happens and rework existing code
> as necessary.
>
> Revolutionaries can work in the "chianti" sandbox, or if they
> prefer a different brand of revolution, they can create another
> sandbox to do this. The latter is perfectly legitimate according
> to the Rules for Revolutionaries, and I think it is healthy for
> the project for people to be able to show their new ideas in the
> form of code, as long as the project as a whole (i.e., the whole
> community) keeps moving forward with ongoing work on the trunk
> and doesn't focus exclusively on what is happening in the
> sandboxes.
>
> Simon
>
> Sam Ruby wrote:
>
>> Jeremy Boynes wrote:
>>
>>> Ant
>>>
>>> I'm disappointed that you have chosen this path. I will ask one more
>>> time if you and Sebastien would consider collaborating with those of
>>> us working on core2.
>>
>>
>> A while ago, I agreed to be a mentor for this project. I guess it is
>> about time that I start acting like one.
>>
>> If this project ever hopes to exit incubation, it had better start
>> acting like an ASF project. For starters, I suggest that all
>> committers read the Rules for Revolutionaries[1][2][3].
>>
>> For those who want the Cliff notes version: anybody who wants to work
>> in an evolutionary fashion on the main trunk is welcome to do so.
>> Anybody who wants to work on a revolutionary branch is welcome to do
>> so. Multiple concurrent revolutionary branches are OK too.
>>
>> One thing that is decidedly NOT OK is to include a version number in
>> the name, as it causes friction. Hence, I'd suggest that "core2"
>> immediately get renamed to something that neither reflects the term
>> "core" or the number "2".
>>
>> Something implicit in the R4R document is that the burden of proof is
>> on the revolutionaries. If you would like to see your particular
>> branch merged back onto the trunk, be prepared to demonstrate why
>> your particular branch is not merely better, but necessary. My
>> experience it that the more concrete and the less hand-wavy the
>> argument, the more likely it will be accepted. So, if you chose to
>> believe that scenarios and test cases are optional, just remember,
>> merging your sandbox back to the trunk is optional too. That does
>> not mean that scenarios and test cases are required, but it does mean
>> that if these aren't present, you need to come up with something just
>> as compelling.
>>
>> - Sam Ruby
>>
>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>
>
Simon,
I agree. I'm going to do some work on the samples in the trunk, I'd like
to evolve some of them (starting with the Calculator sample and then
Bigbank) to start showing some of the concepts in the evolving SCA
specification.
In addition, I searched through our JIRA backlog and found the following
patches, which should be reviewed and potentially applied to the trunk:
TUSCANY-120 - Java2WSDL patches to generate correct XSDs
TUSCANY-454 - Fixes WSDLs in some of the samples
TUSCANY-457 - Fixes an NPE in TuscanyContextListener
TUSCANY-477 - Improve unresolved type error handling
TUSCANY-520 - Fixes build to handle folder names containing spaces
TUSCANY-535 - Implements XSDHelper.generate()
I'm going to start by looking at TUSCANY-120.
I may have missed some patches (I wished JIRA had a query listing all
issues with pending patches...) so could people waiting for their
patches to be reviewed and applied please speak up and point us to the
JIRA issue numbers? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks, Sam; this is very helpful. One part in particular of the
James Duncan Davidson post caught my eye:
<jdd>
4) The trunk is the official versioned line of the project. All
evolutionary minded people are welcome to work on it to improve it.
Evolutionary work is important and should not stop as it is always
unclear when any particular revolution will be ready for prime time
or whether it will be officially accepted.
</jdd>
I think we have failed to follow this guideline over recent weeks.
People have submitted patches for the trunk and they have not been
applied (or applied to a sandbox instead). Technical discussions
have started that in the normal course of events would have led to
commits and patches, but these commits and patches have not been
forthcoming. This has generally led to progress on the project
(except for sandbox activity) being stalled, presumably because
people were waiting to see what would happen with the sandbox code.
I believe we need to get the project moving forward again. At the
present time, we have an evolutionary trunk and a revolutionary
sandbox. We should therefore continue (in reality restart) doing
evolutionary work on the trunk for the reasons that JDD gives in
the quote above. There is evolutionary work that can usefully
be done, such as Raymond's work on databindings, the work on
interface represenation that Ant and others have been discussing,
Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
there are other things too. If at some point there is a revolution,
then we will deal with it when it happens and rework existing code
as necessary.
Revolutionaries can work in the "chianti" sandbox, or if they
prefer a different brand of revolution, they can create another
sandbox to do this. The latter is perfectly legitimate according
to the Rules for Revolutionaries, and I think it is healthy for
the project for people to be able to show their new ideas in the
form of code, as long as the project as a whole (i.e., the whole
community) keeps moving forward with ongoing work on the trunk
and doesn't focus exclusively on what is happening in the
sandboxes.
Simon
Sam Ruby wrote:
> Jeremy Boynes wrote:
>
>> Ant
>>
>> I'm disappointed that you have chosen this path. I will ask one more
>> time if you and Sebastien would consider collaborating with those of
>> us working on core2.
>
>
> A while ago, I agreed to be a mentor for this project. I guess it is
> about time that I start acting like one.
>
> If this project ever hopes to exit incubation, it had better start
> acting like an ASF project. For starters, I suggest that all committers
> read the Rules for Revolutionaries[1][2][3].
>
> For those who want the Cliff notes version: anybody who wants to work in
> an evolutionary fashion on the main trunk is welcome to do so. Anybody
> who wants to work on a revolutionary branch is welcome to do so.
> Multiple concurrent revolutionary branches are OK too.
>
> One thing that is decidedly NOT OK is to include a version number in the
> name, as it causes friction. Hence, I'd suggest that "core2"
> immediately get renamed to something that neither reflects the term
> "core" or the number "2".
>
> Something implicit in the R4R document is that the burden of proof is on
> the revolutionaries. If you would like to see your particular branch
> merged back onto the trunk, be prepared to demonstrate why your
> particular branch is not merely better, but necessary. My experience it
> that the more concrete and the less hand-wavy the argument, the more
> likely it will be accepted. So, if you chose to believe that scenarios
> and test cases are optional, just remember, merging your sandbox back to
> the trunk is optional too. That does not mean that scenarios and test
> cases are required, but it does mean that if these aren't present, you
> need to come up with something just as compelling.
>
> - Sam Ruby
>
> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Chianti, was: Rules for Revolutionaries [was: M2]
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote:
> On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote:
>>
>> One thing that is decidedly NOT OK is to include a version number
>> in the name, as it causes friction. Hence, I'd suggest that
>> "core2" immediately get renamed to something that neither reflects
>> the term "core" or the number "2".
>>
>
> To resolve this I propose that we move the code from my sandbox to
> its own location based on a codename. Once I get the build issues
> resolved, I plan to move the tree from "sandbox/jboynes" to
> "sandbox/chianti" and will rename the "core2" module back to "core"
This should now be complete - if you cd to sandbox and "svn up
chianti" you should get a buildable tree.
I changed the artifact versions to "1.0-chianti-SNAPSHOT" - the "1.0"
is only there to keep maven happy by starting the version with a number.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Chianti, was: Rules for Revolutionaries [was: M2]
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote:
>
> One thing that is decidedly NOT OK is to include a version number
> in the name, as it causes friction. Hence, I'd suggest that
> "core2" immediately get renamed to something that neither reflects
> the term "core" or the number "2".
>
To resolve this I propose that we move the code from my sandbox to
its own location based on a codename. Once I get the build issues
resolved, I plan to move the tree from "sandbox/jboynes" to "sandbox/
chianti" and will rename the "core2" module back to "core"
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Rules for Revolutionaries [was: M2]
Posted by Sam Ruby <ru...@apache.org>.
Jeremy Boynes wrote:
> Ant
>
> I'm disappointed that you have chosen this path. I will ask one more
> time if you and Sebastien would consider collaborating with those of us
> working on core2.
A while ago, I agreed to be a mentor for this project. I guess it is
about time that I start acting like one.
If this project ever hopes to exit incubation, it had better start
acting like an ASF project. For starters, I suggest that all committers
read the Rules for Revolutionaries[1][2][3].
For those who want the Cliff notes version: anybody who wants to work in
an evolutionary fashion on the main trunk is welcome to do so. Anybody
who wants to work on a revolutionary branch is welcome to do so.
Multiple concurrent revolutionary branches are OK too.
One thing that is decidedly NOT OK is to include a version number in the
name, as it causes friction. Hence, I'd suggest that "core2"
immediately get renamed to something that neither reflects the term
"core" or the number "2".
Something implicit in the R4R document is that the burden of proof is on
the revolutionaries. If you would like to see your particular branch
merged back onto the trunk, be prepared to demonstrate why your
particular branch is not merely better, but necessary. My experience it
that the more concrete and the less hand-wavy the argument, the more
likely it will be accepted. So, if you chose to believe that scenarios
and test cases are optional, just remember, merging your sandbox back to
the trunk is optional too. That does not mean that scenarios and test
cases are required, but it does mean that if these aren't present, you
need to come up with something just as compelling.
- Sam Ruby
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
[2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
[3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jeremy Boynes <jb...@apache.org>.
Ant
I'm disappointed that you have chosen this path. I will ask one more
time if you and Sebastien would consider collaborating with those of
us working on core2.
--
Jeremy
On Jul 7, 2006, at 11:53 PM, ant elder wrote:
> Sebastien, lets just do it...this debate is going no where and as
> choosing
> with a vote wasn't popular lets try your approach and see how it
> works.
> After a couple of weeks take a checkpoint and decide whether or not to
> continue. I don't like working in other peoples sandbox so I've
> created a
> folder named miral and as a start copied your model.spi folder
> there. We'll
> all have to be dedicated and hard working so as to quickly get
> something
> going which demonstrates that this is the best way forward. I'm up
> for it,
> how about the rest of you?
>
> https://svn.apache.org/repos/asf/incubator/tuscany/miral/
>
> ...ant
>
> On 7/7/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> More comments inline.
>>
>> Jim Marino wrote:
>> > Comments inline
>> > On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
>> >
>> >> Jeremy,
>> >>
>> >> I won't comment on your attacks at the bottom of this email. I was
>> >> hoping for a more constructive technical discussion. I added my
>> >> answers and comments on the specific technical issues inline.
>> >>
>> >> Jeremy Boynes wrote:
>> >>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>> >>>>
>> >>>> My proposal is not to merge M1 and the core2 sandbox. I am
>> >>>> proposing to start a new fresh code stream and build the runtime
>> >>>> through baby steps. We may be able to reuse some pieces of
>> existing
>> >>>> code, but more important is to engage our community in this
>> >>>> exercise and integrate the new ideas that will emerge from this.
>> >>>>
>> >>>
>> >>> I don't believe the two issues are necessarily coupled. Quite
>> a few
>> >>> members of the community are engaged on the sandbox code
>> already and
>> >>> we could work with you to improve that rather having to throw
>> >>> everything out and start over with all new ideas.
>> >>>
>> >>>>
>> >>>> Here's an example where I'm struggling with both M1 and the
>> core2
>> >>>> sandbox and thinking that we can do better if we start with a
>> new
>> >>>> fresh stream: our (recursive) assembly metadata model.
>> >>>>
>> >>>> - M1 does not implement the recursive composition model and
>> would
>> >>>> require significant changes to support it. Core2 is an
>> attempt to
>> >>>> implement it but I'm not sure it's quite right, and also
>> think that
>> >>>> it can be simplified.
>> >>>
>> >>> It would really help if you could come up with concrete areas
>> where
>> >>> it is not right or where it could be simplified - for example,
>> end
>> >>> user scenarios that are not supported.
>> >>>
>> >>>>
>> >>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>> >>>> think M1 was better since it allowed to keep the order in the
>> >>>> relationships.
>> >>>
>> >>> There's nothing I remember in the assembly spec where order
>> matters.
>> >>> On the other hand there are many areas where things are keyed
>> by a
>> >>> name which has to be unique. This seems like a natural mapping
>> >>> (sorry) to a Map. In M1 I started to move toward simple map
>> >>> structures but you replaced it with what seemed like a fairly
>> >>> complicated specialized List implementation that sent
>> notifications
>> >>> that updated a Map anyway. Given the desire for
>> simplification, are
>> >>> there any end-user scenarios that require ordering to be
>> preserved
>> >>> and that can't be supported with a basic HashMap or
>> LinkedHashMap?
>> >>>
>> >> As an administrator I'll want my administration tool to display
>> >> components displayed in the order I declared them in SCDL.
>> > SCDL isn't the only form assembly can be serialized to/from.
>> Also, if
>> > I were an admin, I'd probably want to sort the components
>> according to
>> > some useful criteria, not how they are listed in a SCDL as most
>> admins
>> > will never look at XML. One could always use LikedHashMap though.
>> >
>> Maybe SCDL isn't the only form but this is not relevant, we need to
>> support SCDL don't we? As soon as you put assembly elements in a
>> document that a user/developer can edit the order is relevant.
>>
>> I disagree with your statement about administrators. They often
>> look at
>> and work with XML configuration files. If you want to support
>> other sort
>> criteria in addition that's fine, but admin, config and editing tools
>> need to at least support the order from the XML document.
>>
>> >> I'll also want a configuration or admin tool loading/saving
>> modified
>> >> SCDL to write things in the order that they were initially, not
>> in a
>> >> random order. As an application developer I'd like to have an SCA
>> >> debugging tool showing me my components in a list in the right
>> order
>> >> as well. Also if I want to implement the model defined by the XML
>> >> schemas in the spec using any of the DataBinding technologies out
>> >> there, I'll end up with Lists, not Maps.
>> >>
>> > We have been using StAX just fine for this and it accommodates a
>> > number of databinding solutions for extensions. Are you
>> proposing we
>> > revisit this decision made back before the M1 release to go with
>> STaX
>> > loading? If so, for what reasons? BTW, not all databinding
>> solutions
>> > will have problems - XStream will work just fine with what we have.
>> > Also, are you sure about XMLBeans and JAXB or are you just speaking
>> > about a current implementation of SDO?
>>
>> Not quite correct, the decision we made back before M1 was to go with
>> StAX loading, write the loaders by hand for now, and see how the SDO
>> team could generate this code after M1. Independent of that, I don't
>> want to tie us to any specific data binding, so we better pick
>> representations for model relationships that are commonly used by
>> most
>> databindings to represent XSD <element... maxOccurs="unbounded"/>,
>> i.e.
>> Lists, not Maps.
>>
>> >
>> >> Finally even if we decided to use Maps in some cases to provide
>> keyed
>> >> access to some elements of the model, we'd have to do it
>> differently.
>> >> For example a single Map containing all components, references and
>> >> services in a composite (according to the spec they cannot have
>> the
>> >> same names) instead of three Maps like you have in Core2.
>> >>
>> And this is why LinkedHashMap will not help you here.
>>
>> >>>>
>> >>>> - Core2 only defines implementation classes for the model, I
>> think
>> >>>> we should have interfaces + default implementation classes
>> instead,
>> >>>> like we had in M1, to allow for alternate implementations of the
>> >>>> model.
>> >>>
>> >>> One of the most complex things with the M1 model was all the
>> >>> interfaces involved, the need to pass factory implementations
>> >>> around, the number of different factories involved (one per
>> >>> extension implementation) and the potential issues with code
>> >>> assuming its implementation of the factory was the one used.
>> >>>
>> >>> The core2 model uses concrete classes which are really just data
>> >>> holders - there's no behaviour in them to be abstracted
>> through the
>> >>> interface. This gives a much simpler programming model for
>> >>> extensions using the model.
>> >>>
>> >>> Do you have any scenarios that would require different
>> >>> implementations of the model? Are they so different that they
>> might
>> >>> as well just use different classes?
>> >>>
>> >>
>> >> I don't think that having just implementation classes is much
>> >> simpler. If you interact with the model SPI, reading interfaces is
>> >> simpler IMO and more suitable for inclusion in a specification
>> >> document... allowing multiple implementations of these interfaces.
>> >> Also we have to support the whole lifecycle of an SCA application
>> >> (development, deploy/install, runtime, admin etc.) and I'd like to
>> >> allow some flexibility for different tools, running at different
>> >> times to use different implementations of the assembly model
>> interfaces.
>> >>
>> > Oisin from the STP project said the POJO based approach would suit
>> > them just fine. I don't see the complexity. On the contrary, all of
>> > the AssemblyFactories we had in M1 lead IMO to a massive
>> antipattern
>> > where they were passed throughout the core. I'm happy to walk
>> through
>> > the relevant code if people are interested. All the factories
>> did was
>> > new up a POJO. Not worth the complexity in my opinion but I'm
>> happy to
>> > compare the work in the sandbox with your proposal if you'd like to
>> > walk us through it.
>>
>> When the runtime depends on too many factories, this is the
>> manifestation of bigger coupling problems. The factories for all the
>> extensions should not be visible at all from the core runtime, and
>> if we
>> externalize the WSDL and Java interface support and the Java
>> implementation support our of core like I'm proposing, you're not
>> dealing with many factories.
>>
>> I am sure that tooling projects will need to add much to this model,
>> support for events, change tracking, tracking between XML elements
>> and
>> model objects to provider proper feedback to application developers,
>> integration with modeling technologies used in the tooling world,
>> support for cloning maybe... tons of things. I spent several years
>> developing tools so I think I know what I'm talking about here. The
>> first thing I'll ask as a tooling developer is: please give me
>> interfaces so I can hook what I need in the implementations.
>>
>> I'm happy to walk people through the interfaces or answer any
>> questions
>> on the list,
>>
>> >>>>
>> >>>> - Over usage of Java Generics breaks flexibility in some
>> cases, for
>> >>>> example Component<I extends Implementation> will force you to
>> >>>> recreate an instance of Component to swap its implementation
>> with
>> >>>> an implementation of a different type (and lose all the wires
>> going
>> >>>> in/out of the component).
>> >>>
>> >>> There may be cases where generics may be overkill but I don't
>> think
>> >>> that really requires us to throw out the model. There are other
>> >>> cases where the use of wildcards would be appropriate; for
>> example,
>> >>> in the scenario you give here you could just create a
>> >>> Component<Implementation> to allow different types of
>> implementation
>> >>> to be used.
>> >>>
>> >> Then instead of
>> >> Component<Implementation> {
>> >> Implementation getImplementation();
>> >> }
>> >> I think we can just do
>> >> Component {
>> >> Implementation getImplementation();
>> >> }
>> >> What we have now in core2 is overkill IMO.
>> >>
>> > then do we need to cast to the right impl type?
>>
>> The core runtime should not have to cast, simply because it should
>> not
>> depend on any component implementation type (not even the Java or
>> System
>> implementation types).
>>
>> >
>> >>>>
>> >>>> - Core2 defines ReferenceDefinitions (without bindings) and
>> >>>> BoundReferenceDefinitions (with bindings). IMO there are
>> Reference
>> >>>> types and Reference instances and both can have bindings.
>> >>>> or Reference.
>> >>>
>> >>> I'm with you here - we need to refactor the way bindings are
>> handled
>> >>> for both Service and Reference. One thing the sandbox model is
>> >>> missing is the ability to associate multiple bindings with a
>> single
>> >>> Service/Reference.
>> >>
>> >> My main point is not about supporting multiple bindings on a
>> Service
>> >> or Reference. I think this is secondary and the interfaces I
>> put in
>> >> my sandbox to support a design discussion don't even have that
>> >> either. My point is that Services, References, and their
>> >> instantiation by Components are at the foundation of the SCA
>> assembly
>> >> model... and therefore need to be modeled correctly. I'm
>> proposing a
>> >> different design, illustrated by the interfaces I checked in.
>> >>
>> > Could you elaborate?
>>
>> I think it should be very simple:
>> - Component types have service and reference types
>> - Components are instances of component types and have services and
>> references, which are instances of the service and reference types
>> - Service and reference types can have bindings
>> - Bindings can be overriden in service and reference instances
>> This is clear when you look at a Composite. A composite is a
>> Component
>> Type, has service and reference types (aka composite services and
>> references) which can have bindings.
>> A component can be implemented by a Composite, has services and
>> references, which can use the (default) bindings from their
>> respective
>> service and reference types, or specify (override) bindings.
>>
>> >>>
>> >>>>
>> >>>> - I think that Remotable should be on Interface and not Service.
>> >>>
>> >>> I agree Service is wrong and that it should be on
>> ServiceContract.
>> >>> Thanks for catching it.
>> >>>
>> >>>>
>> >>>> - Scope should be defined in the Java component implementation,
>> >>>> separate from the core model.
>> >>>
>> >>> Scope is not a Java specific concept.
>> >>> Interaction scope (stateless vs. stateful) can apply to any
>> >>> ServiceContract.
>> >>> Container scope is the contract between an implementation and a
>> >>> ScopeContainer and applies to any implementation type that can
>> >>> support stateful interactions. This would include JavaScript,
>> >>> Groovy, C++, ... I think that means that support for state
>> >>> management (which is what scope is configuring) belongs in the
>> core
>> >>> with the configuration metadata supplied by the implementation
>> type.
>> >>>
>> >>
>> >> I don't think it's quite right. First interaction scopes are
>> defined
>> >> on interfaces and not service contracts. Also they control
>> whether
>> >> an interface is conversational or not, independent from any state
>> >> management.
>> >> Anyway I was talking about a different scope, the implementation
>> >> scope defined in the Java C&I spec, which governs the lifecycle of
>> >> Java component implementation instances. I think the definition
>> and
>> >> implementation of lifecycle management will vary greatly
>> depending on
>> >> the component implementation type, for example Java component
>> >> implementations and BPEL component implementations typically deal
>> >> with this in a very different way.
>> > Well, I don't think that's the case at all and actually there is a
>> > concept of implementation scope in assembly - it just varies by
>> > implementation type, which is entirely consistent with our design.
>> > BPEL is the odd case, and this came up as we wrote the scope
>> changes
>> > into the spec (Ken did a lot of the work here). Across many
>> > implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
>> > (maybe even C++) I see use for the same scopes as in Java. Do you
>> > disagree?
>> >
>> > Also, I'm curious why you think the scope containers complicate the
>> > core and need to be moved out? Or are you saying this based on your
>> > reading of the spec? They seem quite simple to me.
>>
>> I'm saying that scope management is specific to the implementation
>> type
>> and therefore needs to be made pluggable, i.e. moved out of core. The
>> Java scope management is just one example of scope management.
>>
>> >
>> >> Therefore, in my view state/lifecycle management should be left to
>> >> the component implementation contributions and not belong to core.
>> >>
>> > I think this would lead to over-complication, particularly for the
>> > extension developer. Right now, scope containers can be reused. In
>> > particular, how would conversational services be handled? If I
>> want to
>> > use module or session scope containers for my Groovy script,
>> then I'd
>> > have to write those rather then just reuse what the core gives me?
>> > Also, be reusing, we also allow an additional extension type in
>> terms
>> > of scope. For example, someone could add a distributed cache
>> scope and
>> > have that shared by Groovy, Java, whatever.
>> >
>> > I'll also note two things. Getting scope containers to work
>> properly
>> > with instance tracking is not trivial. I'd hate to push that on
>> > extension developers. Second, this basic design has been there
>> since
>> > before M1. Why wasn't this brought up before since it is such a
>> > significant issue?
>> >>
>> >>>>
>> >>>> - Java and WSDL interfaces should be defined separate from
>> the core
>> >>>> model, we need to support multiple interface definition
>> languages
>> >>>> supported by plugins, not in the core.
>> >>>
>> >>> The model supports generic IDL through the use of
>> ServiceContract.
>> >>> Java and WSDL are two forms of IDL that are mandated by the
>> >>> specification. This is really just a question of where those
>> >>> implementations are packaged and again I don't think this
>> warrants a
>> >>> rewrite.
>> >>>
>> >>
>> >> Packaging issues are important and often hide bigger
>> >> dependency/coupling problems. I think we should package the
>> support
>> >> for Java and WSDL interfaces separate from the core to prevent any
>> >> coupling between the two, and also give people who will have to
>> >> support new interface definition languages a better template to
>> follow.
>> >>
>> >> Individual issues do not warrant a rewrite. What about the sum of
>> >> many issues?
>> >>
>> > None of the issues warrant a rewrite, not even the sum. Most of
>> your
>> > criticisms seem centered around the model which is fairly decoupled
>> > from the bulk of the core2 runtime. Even if we adopted your changes
>> > wholesale, I'd doubt they would change the core2 runtime
>> > significantly. Even the scope containers could be moved out without
>> > breaking anything and very little code changes, although that
>> would be
>> > a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
>>
>> I am not proposing a rewrite of the whole runtime, see my original
>> email, it's not a whole rewrite. I'm proposing a staged / baby step
>> approach integrating the good work from M1 and the sandbox and new
>> discussions where I think what we have is not right or where new
>> ideas
>> from the group come up.
>>
>> I'm starting with the model SPI because I think that having the
>> assembly
>> model right is critical for an assembly runtime. Most of the ideas
>> here
>> have an impact on the architecture of the runtime, so I thought
>> this was
>> a good starting point, and also a good base of discussion to help
>> all in
>> our community discuss and understand better the new recursive
>> composition model.
>>
>>
>> >>>> - Implementation should extend ComponentType IMO instead of
>> >>>> pointing to it, and we may even be able to simplify and just
>> remove
>> >>>> Implementation. Also I am not sure why we need to distinguish
>> >>>> between AtomicImplementation and CompositeImplementation.
>> >>>
>> >>> One of the problems the assembly spec has is that it is
>> difficult to
>> >>> do top-down design because you cannot link a component to a
>> >>> componentType without having an implementation. I agree this
>> is an
>> >>> area that we (and the spec) need to sort out.
>> >>>
>> >>> IMO a component is associated with one componentType but may have
>> >>> multiple implementations so I don't think they are quite the same
>> >>> thing or that either can be removed.
>> >>>
>> >>> AtomicImplementation is a marker for implementations that cannot
>> >>> have children.
>> >>
>> >> In my view a component has a type. The ComponentType is either
>> >> abstract (just defining the types of services offered, references
>> >> used, and properties that can be configured), or concrete. A POJO
>> >> component implementation is a concrete ComponentType.
>> >>
>> > Perhaps we could walk through your model?
>>
>> Yes, the interfaces I put under m2-design are there to illustrate
>> ideas
>> and support a design discussion. I'm working on some UML diagrams
>> that I
>> think will help too.
>>
>> >>>
>> >>>
>> >>>>
>> >>>> - Support for Composite Includes is missing, this is a
>> significant
>> >>>> part of the recursive composition model (half of it, one of
>> the two
>> >>>> ways to nest composites).
>> >>>
>> >>> It's not really half - it's really just a very small part of the
>> >>> model, comparable to the <import> element we used to support
>> in M1.
>> >>> Again, I don't see why we need to rewrite the model to add
>> this in.
>> >>> Quite the opposite: you've said you've been looking for way to
>> >>> engage and this could be it.
>> >>
>> >> I disagree. Includes are a very significant part of the assembly
>> >> model (the other part is the ability to use a composite as a
>> >> component implementation). Two examples:
>> >> - An included composite is the equivalent of a module fragment
>> in the
>> >> 0.9 spec. This concept is key to allowing a team to work on
>> various
>> >> pieces of an application, split in multiple composites,
>> included in a
>> >> composite representing the application.
>> >> - When (formerly subsystems) composites get deployed to an SCA
>> >> system, they are actually included in that system, rather than
>> being
>> >> used as component implementations.
>> >>
>> > It's not "half" of the recursive model. In fact, most of the
>> time we
>> > spent in the spec group was grappling with other issues related to
>> > recursion.
>>
>> I don't see an immediate relation between the time spent by the spec
>> group on a specific item and its importance for application
>> developers.
>> I am looking at this from an application developer point of view and
>> saying that I'll use Includes as much as composition through
>> (composite)
>> components. Includes will allow a team to distribute work on an SCA
>> application and also represent a key concept for system
>> composition. I
>> am starting to look at scenarios and can actually see the usage of
>> Includes in almost all of them, but having trouble finding good use
>> cases for the other form of composition (nested component
>> implementations). So I stand by my statement that understanding how
>> includes work is key here.
>>
>> >
>> >>>
>> >>>>
>> >>>> This list is not exhaustive... Another idea would be to
>> externalize
>> >>>> support for Composites in a separate plugin not part of the core
>> >>>> service model (since there may be other ways to compose
>> services in
>> >>>> addition to an SCA composite, with Spring or other similar
>> >>>> programming models), I'd like to know what people think about
>> that.
>> >>>>
>> >>>
>> >>> Having the composite implementation type in the core does not
>> >>> preclude that - again, it's just packaging for ease-of-use.
>> >>
>> >> I think it's more significant than packaging. Are you saying
>> that we
>> >> could move the code supporting composites out of core2 without
>> >> breaking the code in core2?
>> >>
>> > Why would we do this? We can already support multiple composite
>> > implementation types - have a look at the Spring extension. That
>> just
>> > sounds like unnecessary complication.
>> Why? to avoid unecessary and dangerous coupling that will hurt us
>> when
>> we try to evolve this runtime. How to illustrate that? how about
>> trying
>> to move code supporting composites out of core2? I'm realizing I'm
>> asking the same question again... but I think it's an important
>> question, sill unanswered.
>>
>> >
>> >>
>> >>>
>> >>> You seem to have the impression that the core is sealed and
>> that we
>> >>> only support things that are included within it. That is not the
>> >>> case. The only place we need things bundled with the core is
>> in the
>> >>> bootstrap phase - specifically, we need them bundled with the
>> >>> primordial deployer. The actual runtime is created from the SCDL
>> >>> passed to that primordial deployer, can contain any mix of
>> >>> components and need not contain any of the infrastructure used to
>> >>> boot it.
>> >>>
>> >>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>> >>>> new interfaces. This is just an initial strawman to trigger a
>> >>>> constructive discussion and ideas on how to best represent the
>> >>>> recursive model. I also need help to define a scenario (not unit
>> >>>> test cases, but an end to end sample application) to help put
>> the
>> >>>> recursive composition model in perspective and make sure we all
>> >>>> understand it the same way.
>> >>>>
>> >>>
>> >>> I am troubled that you have chosen to start on your own
>> codebase at
>> >>> a time when most of us have been trying to have constructive
>> >>> discussion on this list. Based on the approach you proposed in
>> your
>> >>> original email I would have hoped that we could have started with
>> >>> your end-user scenarios and had a chance to explore how they
>> could
>> >>> be supported by M1, the sandbox, or some other code before
>> starting
>> >>> another codebase. I'm disappointed that, having started this very
>> >>> thread nearly a week ago with the premise of community, your
>> first
>> >>> response on it was to commit a large chunk of independent code
>> >>> rather than follow up with any of the other people who have
>> already
>> >>> contributed to the discussion.
>> >>>
>> >>> I think discussion led to compromise and consensus on the
>> >>> scenario-driven approach that you proposed. As shown above and in
>> >>> other recent threads, there's plenty of room for improvements
>> and/or
>> >>> new features in our current code and a willingness to discuss
>> them,
>> >>> albeit in terms of technical merit rather than personal
>> opinion. I
>> >>> hope you can find a way to join in rather than forge your own
>> path.
>> >>>
>> >>> --Jeremy
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >> --Jean-Sebastien
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>>
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Proposed approach for M2
Posted by ant elder <an...@gmail.com>.
Sebastien, lets just do it...this debate is going no where and as choosing
with a vote wasn't popular lets try your approach and see how it works.
After a couple of weeks take a checkpoint and decide whether or not to
continue. I don't like working in other peoples sandbox so I've created a
folder named miral and as a start copied your model.spi folder there. We'll
all have to be dedicated and hard working so as to quickly get something
going which demonstrates that this is the best way forward. I'm up for it,
how about the rest of you?
https://svn.apache.org/repos/asf/incubator/tuscany/miral/
...ant
On 7/7/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> More comments inline.
>
> Jim Marino wrote:
> > Comments inline
> > On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
> >
> >> Jeremy,
> >>
> >> I won't comment on your attacks at the bottom of this email. I was
> >> hoping for a more constructive technical discussion. I added my
> >> answers and comments on the specific technical issues inline.
> >>
> >> Jeremy Boynes wrote:
> >>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> >>>>
> >>>> My proposal is not to merge M1 and the core2 sandbox. I am
> >>>> proposing to start a new fresh code stream and build the runtime
> >>>> through baby steps. We may be able to reuse some pieces of existing
> >>>> code, but more important is to engage our community in this
> >>>> exercise and integrate the new ideas that will emerge from this.
> >>>>
> >>>
> >>> I don't believe the two issues are necessarily coupled. Quite a few
> >>> members of the community are engaged on the sandbox code already and
> >>> we could work with you to improve that rather having to throw
> >>> everything out and start over with all new ideas.
> >>>
> >>>>
> >>>> Here's an example where I'm struggling with both M1 and the core2
> >>>> sandbox and thinking that we can do better if we start with a new
> >>>> fresh stream: our (recursive) assembly metadata model.
> >>>>
> >>>> - M1 does not implement the recursive composition model and would
> >>>> require significant changes to support it. Core2 is an attempt to
> >>>> implement it but I'm not sure it's quite right, and also think that
> >>>> it can be simplified.
> >>>
> >>> It would really help if you could come up with concrete areas where
> >>> it is not right or where it could be simplified - for example, end
> >>> user scenarios that are not supported.
> >>>
> >>>>
> >>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
> >>>> think M1 was better since it allowed to keep the order in the
> >>>> relationships.
> >>>
> >>> There's nothing I remember in the assembly spec where order matters.
> >>> On the other hand there are many areas where things are keyed by a
> >>> name which has to be unique. This seems like a natural mapping
> >>> (sorry) to a Map. In M1 I started to move toward simple map
> >>> structures but you replaced it with what seemed like a fairly
> >>> complicated specialized List implementation that sent notifications
> >>> that updated a Map anyway. Given the desire for simplification, are
> >>> there any end-user scenarios that require ordering to be preserved
> >>> and that can't be supported with a basic HashMap or LinkedHashMap?
> >>>
> >> As an administrator I'll want my administration tool to display
> >> components displayed in the order I declared them in SCDL.
> > SCDL isn't the only form assembly can be serialized to/from. Also, if
> > I were an admin, I'd probably want to sort the components according to
> > some useful criteria, not how they are listed in a SCDL as most admins
> > will never look at XML. One could always use LikedHashMap though.
> >
> Maybe SCDL isn't the only form but this is not relevant, we need to
> support SCDL don't we? As soon as you put assembly elements in a
> document that a user/developer can edit the order is relevant.
>
> I disagree with your statement about administrators. They often look at
> and work with XML configuration files. If you want to support other sort
> criteria in addition that's fine, but admin, config and editing tools
> need to at least support the order from the XML document.
>
> >> I'll also want a configuration or admin tool loading/saving modified
> >> SCDL to write things in the order that they were initially, not in a
> >> random order. As an application developer I'd like to have an SCA
> >> debugging tool showing me my components in a list in the right order
> >> as well. Also if I want to implement the model defined by the XML
> >> schemas in the spec using any of the DataBinding technologies out
> >> there, I'll end up with Lists, not Maps.
> >>
> > We have been using StAX just fine for this and it accommodates a
> > number of databinding solutions for extensions. Are you proposing we
> > revisit this decision made back before the M1 release to go with STaX
> > loading? If so, for what reasons? BTW, not all databinding solutions
> > will have problems - XStream will work just fine with what we have.
> > Also, are you sure about XMLBeans and JAXB or are you just speaking
> > about a current implementation of SDO?
>
> Not quite correct, the decision we made back before M1 was to go with
> StAX loading, write the loaders by hand for now, and see how the SDO
> team could generate this code after M1. Independent of that, I don't
> want to tie us to any specific data binding, so we better pick
> representations for model relationships that are commonly used by most
> databindings to represent XSD <element... maxOccurs="unbounded"/>, i.e.
> Lists, not Maps.
>
> >
> >> Finally even if we decided to use Maps in some cases to provide keyed
> >> access to some elements of the model, we'd have to do it differently.
> >> For example a single Map containing all components, references and
> >> services in a composite (according to the spec they cannot have the
> >> same names) instead of three Maps like you have in Core2.
> >>
> And this is why LinkedHashMap will not help you here.
>
> >>>>
> >>>> - Core2 only defines implementation classes for the model, I think
> >>>> we should have interfaces + default implementation classes instead,
> >>>> like we had in M1, to allow for alternate implementations of the
> >>>> model.
> >>>
> >>> One of the most complex things with the M1 model was all the
> >>> interfaces involved, the need to pass factory implementations
> >>> around, the number of different factories involved (one per
> >>> extension implementation) and the potential issues with code
> >>> assuming its implementation of the factory was the one used.
> >>>
> >>> The core2 model uses concrete classes which are really just data
> >>> holders - there's no behaviour in them to be abstracted through the
> >>> interface. This gives a much simpler programming model for
> >>> extensions using the model.
> >>>
> >>> Do you have any scenarios that would require different
> >>> implementations of the model? Are they so different that they might
> >>> as well just use different classes?
> >>>
> >>
> >> I don't think that having just implementation classes is much
> >> simpler. If you interact with the model SPI, reading interfaces is
> >> simpler IMO and more suitable for inclusion in a specification
> >> document... allowing multiple implementations of these interfaces.
> >> Also we have to support the whole lifecycle of an SCA application
> >> (development, deploy/install, runtime, admin etc.) and I'd like to
> >> allow some flexibility for different tools, running at different
> >> times to use different implementations of the assembly model
> interfaces.
> >>
> > Oisin from the STP project said the POJO based approach would suit
> > them just fine. I don't see the complexity. On the contrary, all of
> > the AssemblyFactories we had in M1 lead IMO to a massive antipattern
> > where they were passed throughout the core. I'm happy to walk through
> > the relevant code if people are interested. All the factories did was
> > new up a POJO. Not worth the complexity in my opinion but I'm happy to
> > compare the work in the sandbox with your proposal if you'd like to
> > walk us through it.
>
> When the runtime depends on too many factories, this is the
> manifestation of bigger coupling problems. The factories for all the
> extensions should not be visible at all from the core runtime, and if we
> externalize the WSDL and Java interface support and the Java
> implementation support our of core like I'm proposing, you're not
> dealing with many factories.
>
> I am sure that tooling projects will need to add much to this model,
> support for events, change tracking, tracking between XML elements and
> model objects to provider proper feedback to application developers,
> integration with modeling technologies used in the tooling world,
> support for cloning maybe... tons of things. I spent several years
> developing tools so I think I know what I'm talking about here. The
> first thing I'll ask as a tooling developer is: please give me
> interfaces so I can hook what I need in the implementations.
>
> I'm happy to walk people through the interfaces or answer any questions
> on the list,
>
> >>>>
> >>>> - Over usage of Java Generics breaks flexibility in some cases, for
> >>>> example Component<I extends Implementation> will force you to
> >>>> recreate an instance of Component to swap its implementation with
> >>>> an implementation of a different type (and lose all the wires going
> >>>> in/out of the component).
> >>>
> >>> There may be cases where generics may be overkill but I don't think
> >>> that really requires us to throw out the model. There are other
> >>> cases where the use of wildcards would be appropriate; for example,
> >>> in the scenario you give here you could just create a
> >>> Component<Implementation> to allow different types of implementation
> >>> to be used.
> >>>
> >> Then instead of
> >> Component<Implementation> {
> >> Implementation getImplementation();
> >> }
> >> I think we can just do
> >> Component {
> >> Implementation getImplementation();
> >> }
> >> What we have now in core2 is overkill IMO.
> >>
> > then do we need to cast to the right impl type?
>
> The core runtime should not have to cast, simply because it should not
> depend on any component implementation type (not even the Java or System
> implementation types).
>
> >
> >>>>
> >>>> - Core2 defines ReferenceDefinitions (without bindings) and
> >>>> BoundReferenceDefinitions (with bindings). IMO there are Reference
> >>>> types and Reference instances and both can have bindings.
> >>>> or Reference.
> >>>
> >>> I'm with you here - we need to refactor the way bindings are handled
> >>> for both Service and Reference. One thing the sandbox model is
> >>> missing is the ability to associate multiple bindings with a single
> >>> Service/Reference.
> >>
> >> My main point is not about supporting multiple bindings on a Service
> >> or Reference. I think this is secondary and the interfaces I put in
> >> my sandbox to support a design discussion don't even have that
> >> either. My point is that Services, References, and their
> >> instantiation by Components are at the foundation of the SCA assembly
> >> model... and therefore need to be modeled correctly. I'm proposing a
> >> different design, illustrated by the interfaces I checked in.
> >>
> > Could you elaborate?
>
> I think it should be very simple:
> - Component types have service and reference types
> - Components are instances of component types and have services and
> references, which are instances of the service and reference types
> - Service and reference types can have bindings
> - Bindings can be overriden in service and reference instances
> This is clear when you look at a Composite. A composite is a Component
> Type, has service and reference types (aka composite services and
> references) which can have bindings.
> A component can be implemented by a Composite, has services and
> references, which can use the (default) bindings from their respective
> service and reference types, or specify (override) bindings.
>
> >>>
> >>>>
> >>>> - I think that Remotable should be on Interface and not Service.
> >>>
> >>> I agree Service is wrong and that it should be on ServiceContract.
> >>> Thanks for catching it.
> >>>
> >>>>
> >>>> - Scope should be defined in the Java component implementation,
> >>>> separate from the core model.
> >>>
> >>> Scope is not a Java specific concept.
> >>> Interaction scope (stateless vs. stateful) can apply to any
> >>> ServiceContract.
> >>> Container scope is the contract between an implementation and a
> >>> ScopeContainer and applies to any implementation type that can
> >>> support stateful interactions. This would include JavaScript,
> >>> Groovy, C++, ... I think that means that support for state
> >>> management (which is what scope is configuring) belongs in the core
> >>> with the configuration metadata supplied by the implementation type.
> >>>
> >>
> >> I don't think it's quite right. First interaction scopes are defined
> >> on interfaces and not service contracts. Also they control whether
> >> an interface is conversational or not, independent from any state
> >> management.
> >> Anyway I was talking about a different scope, the implementation
> >> scope defined in the Java C&I spec, which governs the lifecycle of
> >> Java component implementation instances. I think the definition and
> >> implementation of lifecycle management will vary greatly depending on
> >> the component implementation type, for example Java component
> >> implementations and BPEL component implementations typically deal
> >> with this in a very different way.
> > Well, I don't think that's the case at all and actually there is a
> > concept of implementation scope in assembly - it just varies by
> > implementation type, which is entirely consistent with our design.
> > BPEL is the odd case, and this came up as we wrote the scope changes
> > into the spec (Ken did a lot of the work here). Across many
> > implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
> > (maybe even C++) I see use for the same scopes as in Java. Do you
> > disagree?
> >
> > Also, I'm curious why you think the scope containers complicate the
> > core and need to be moved out? Or are you saying this based on your
> > reading of the spec? They seem quite simple to me.
>
> I'm saying that scope management is specific to the implementation type
> and therefore needs to be made pluggable, i.e. moved out of core. The
> Java scope management is just one example of scope management.
>
> >
> >> Therefore, in my view state/lifecycle management should be left to
> >> the component implementation contributions and not belong to core.
> >>
> > I think this would lead to over-complication, particularly for the
> > extension developer. Right now, scope containers can be reused. In
> > particular, how would conversational services be handled? If I want to
> > use module or session scope containers for my Groovy script, then I'd
> > have to write those rather then just reuse what the core gives me?
> > Also, be reusing, we also allow an additional extension type in terms
> > of scope. For example, someone could add a distributed cache scope and
> > have that shared by Groovy, Java, whatever.
> >
> > I'll also note two things. Getting scope containers to work properly
> > with instance tracking is not trivial. I'd hate to push that on
> > extension developers. Second, this basic design has been there since
> > before M1. Why wasn't this brought up before since it is such a
> > significant issue?
> >>
> >>>>
> >>>> - Java and WSDL interfaces should be defined separate from the core
> >>>> model, we need to support multiple interface definition languages
> >>>> supported by plugins, not in the core.
> >>>
> >>> The model supports generic IDL through the use of ServiceContract.
> >>> Java and WSDL are two forms of IDL that are mandated by the
> >>> specification. This is really just a question of where those
> >>> implementations are packaged and again I don't think this warrants a
> >>> rewrite.
> >>>
> >>
> >> Packaging issues are important and often hide bigger
> >> dependency/coupling problems. I think we should package the support
> >> for Java and WSDL interfaces separate from the core to prevent any
> >> coupling between the two, and also give people who will have to
> >> support new interface definition languages a better template to follow.
> >>
> >> Individual issues do not warrant a rewrite. What about the sum of
> >> many issues?
> >>
> > None of the issues warrant a rewrite, not even the sum. Most of your
> > criticisms seem centered around the model which is fairly decoupled
> > from the bulk of the core2 runtime. Even if we adopted your changes
> > wholesale, I'd doubt they would change the core2 runtime
> > significantly. Even the scope containers could be moved out without
> > breaking anything and very little code changes, although that would be
> > a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
>
> I am not proposing a rewrite of the whole runtime, see my original
> email, it's not a whole rewrite. I'm proposing a staged / baby step
> approach integrating the good work from M1 and the sandbox and new
> discussions where I think what we have is not right or where new ideas
> from the group come up.
>
> I'm starting with the model SPI because I think that having the assembly
> model right is critical for an assembly runtime. Most of the ideas here
> have an impact on the architecture of the runtime, so I thought this was
> a good starting point, and also a good base of discussion to help all in
> our community discuss and understand better the new recursive
> composition model.
>
>
> >>>> - Implementation should extend ComponentType IMO instead of
> >>>> pointing to it, and we may even be able to simplify and just remove
> >>>> Implementation. Also I am not sure why we need to distinguish
> >>>> between AtomicImplementation and CompositeImplementation.
> >>>
> >>> One of the problems the assembly spec has is that it is difficult to
> >>> do top-down design because you cannot link a component to a
> >>> componentType without having an implementation. I agree this is an
> >>> area that we (and the spec) need to sort out.
> >>>
> >>> IMO a component is associated with one componentType but may have
> >>> multiple implementations so I don't think they are quite the same
> >>> thing or that either can be removed.
> >>>
> >>> AtomicImplementation is a marker for implementations that cannot
> >>> have children.
> >>
> >> In my view a component has a type. The ComponentType is either
> >> abstract (just defining the types of services offered, references
> >> used, and properties that can be configured), or concrete. A POJO
> >> component implementation is a concrete ComponentType.
> >>
> > Perhaps we could walk through your model?
>
> Yes, the interfaces I put under m2-design are there to illustrate ideas
> and support a design discussion. I'm working on some UML diagrams that I
> think will help too.
>
> >>>
> >>>
> >>>>
> >>>> - Support for Composite Includes is missing, this is a significant
> >>>> part of the recursive composition model (half of it, one of the two
> >>>> ways to nest composites).
> >>>
> >>> It's not really half - it's really just a very small part of the
> >>> model, comparable to the <import> element we used to support in M1.
> >>> Again, I don't see why we need to rewrite the model to add this in.
> >>> Quite the opposite: you've said you've been looking for way to
> >>> engage and this could be it.
> >>
> >> I disagree. Includes are a very significant part of the assembly
> >> model (the other part is the ability to use a composite as a
> >> component implementation). Two examples:
> >> - An included composite is the equivalent of a module fragment in the
> >> 0.9 spec. This concept is key to allowing a team to work on various
> >> pieces of an application, split in multiple composites, included in a
> >> composite representing the application.
> >> - When (formerly subsystems) composites get deployed to an SCA
> >> system, they are actually included in that system, rather than being
> >> used as component implementations.
> >>
> > It's not "half" of the recursive model. In fact, most of the time we
> > spent in the spec group was grappling with other issues related to
> > recursion.
>
> I don't see an immediate relation between the time spent by the spec
> group on a specific item and its importance for application developers.
> I am looking at this from an application developer point of view and
> saying that I'll use Includes as much as composition through (composite)
> components. Includes will allow a team to distribute work on an SCA
> application and also represent a key concept for system composition. I
> am starting to look at scenarios and can actually see the usage of
> Includes in almost all of them, but having trouble finding good use
> cases for the other form of composition (nested component
> implementations). So I stand by my statement that understanding how
> includes work is key here.
>
> >
> >>>
> >>>>
> >>>> This list is not exhaustive... Another idea would be to externalize
> >>>> support for Composites in a separate plugin not part of the core
> >>>> service model (since there may be other ways to compose services in
> >>>> addition to an SCA composite, with Spring or other similar
> >>>> programming models), I'd like to know what people think about that.
> >>>>
> >>>
> >>> Having the composite implementation type in the core does not
> >>> preclude that - again, it's just packaging for ease-of-use.
> >>
> >> I think it's more significant than packaging. Are you saying that we
> >> could move the code supporting composites out of core2 without
> >> breaking the code in core2?
> >>
> > Why would we do this? We can already support multiple composite
> > implementation types - have a look at the Spring extension. That just
> > sounds like unnecessary complication.
> Why? to avoid unecessary and dangerous coupling that will hurt us when
> we try to evolve this runtime. How to illustrate that? how about trying
> to move code supporting composites out of core2? I'm realizing I'm
> asking the same question again... but I think it's an important
> question, sill unanswered.
>
> >
> >>
> >>>
> >>> You seem to have the impression that the core is sealed and that we
> >>> only support things that are included within it. That is not the
> >>> case. The only place we need things bundled with the core is in the
> >>> bootstrap phase - specifically, we need them bundled with the
> >>> primordial deployer. The actual runtime is created from the SCDL
> >>> passed to that primordial deployer, can contain any mix of
> >>> components and need not contain any of the infrastructure used to
> >>> boot it.
> >>>
> >>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
> >>>> new interfaces. This is just an initial strawman to trigger a
> >>>> constructive discussion and ideas on how to best represent the
> >>>> recursive model. I also need help to define a scenario (not unit
> >>>> test cases, but an end to end sample application) to help put the
> >>>> recursive composition model in perspective and make sure we all
> >>>> understand it the same way.
> >>>>
> >>>
> >>> I am troubled that you have chosen to start on your own codebase at
> >>> a time when most of us have been trying to have constructive
> >>> discussion on this list. Based on the approach you proposed in your
> >>> original email I would have hoped that we could have started with
> >>> your end-user scenarios and had a chance to explore how they could
> >>> be supported by M1, the sandbox, or some other code before starting
> >>> another codebase. I'm disappointed that, having started this very
> >>> thread nearly a week ago with the premise of community, your first
> >>> response on it was to commit a large chunk of independent code
> >>> rather than follow up with any of the other people who have already
> >>> contributed to the discussion.
> >>>
> >>> I think discussion led to compromise and consensus on the
> >>> scenario-driven approach that you proposed. As shown above and in
> >>> other recent threads, there's plenty of room for improvements and/or
> >>> new features in our current code and a willingness to discuss them,
> >>> albeit in terms of technical merit rather than personal opinion. I
> >>> hope you can find a way to join in rather than forge your own path.
> >>>
> >>> --Jeremy
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >> --Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
I have a lot of comments inline but want to overall summarize by
saying I think we should address all of your concerns by
incrementally improving core2. As you said below, you are not arguing
for a rewrite and I think that would be the best way to accommodate
the wide variety of things the community is interested in working on
(not everyone wants to work on the "baby steps", as valuable as they
are).
Having worked with you for over a year, I'm absolutely sure you can
make significant contributions to improving what we have in core2.
How about it?
Jim
On Jul 7, 2006, at 10:17 AM, Jean-Sebastien Delfino wrote:
> More comments inline.
>
> Jim Marino wrote:
>> Comments inline
>> On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
>>
>>> Jeremy,
>>>
>>> I won't comment on your attacks at the bottom of this email. I
>>> was hoping for a more constructive technical discussion. I added
>>> my answers and comments on the specific technical issues inline.
>>>
>>> Jeremy Boynes wrote:
>>>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>>>>>
>>>>> My proposal is not to merge M1 and the core2 sandbox. I am
>>>>> proposing to start a new fresh code stream and build the
>>>>> runtime through baby steps. We may be able to reuse some pieces
>>>>> of existing code, but more important is to engage our community
>>>>> in this exercise and integrate the new ideas that will emerge
>>>>> from this.
>>>>>
>>>>
>>>> I don't believe the two issues are necessarily coupled. Quite a
>>>> few members of the community are engaged on the sandbox code
>>>> already and we could work with you to improve that rather having
>>>> to throw everything out and start over with all new ideas.
>>>>
>>>>>
>>>>> Here's an example where I'm struggling with both M1 and the
>>>>> core2 sandbox and thinking that we can do better if we start
>>>>> with a new fresh stream: our (recursive) assembly metadata model.
>>>>>
>>>>> - M1 does not implement the recursive composition model and
>>>>> would require significant changes to support it. Core2 is an
>>>>> attempt to implement it but I'm not sure it's quite right, and
>>>>> also think that it can be simplified.
>>>>
>>>> It would really help if you could come up with concrete areas
>>>> where it is not right or where it could be simplified - for
>>>> example, end user scenarios that are not supported.
>>>>
>>>>>
>>>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>>>>> think M1 was better since it allowed to keep the order in the
>>>>> relationships.
>>>>
>>>> There's nothing I remember in the assembly spec where order
>>>> matters. On the other hand there are many areas where things are
>>>> keyed by a name which has to be unique. This seems like a
>>>> natural mapping (sorry) to a Map. In M1 I started to move toward
>>>> simple map structures but you replaced it with what seemed like
>>>> a fairly complicated specialized List implementation that sent
>>>> notifications that updated a Map anyway. Given the desire for
>>>> simplification, are there any end-user scenarios that require
>>>> ordering to be preserved and that can't be supported with a
>>>> basic HashMap or LinkedHashMap?
>>>>
>>> As an administrator I'll want my administration tool to display
>>> components displayed in the order I declared them in SCDL.
>> SCDL isn't the only form assembly can be serialized to/from. Also,
>> if I were an admin, I'd probably want to sort the components
>> according to some useful criteria, not how they are listed in a
>> SCDL as most admins will never look at XML. One could always use
>> LikedHashMap though.
>>
> Maybe SCDL isn't the only form but this is not relevant, we need to
> support SCDL don't we? As soon as you put assembly elements in a
> document that a user/developer can edit the order is relevant.
>
> I disagree with your statement about administrators. They often
> look at and work with XML configuration files. If you want to
> support other sort criteria in addition that's fine, but admin,
> config and editing tools need to at least support the order from
> the XML document.
Actually that is generally not the case regarding XML in a
datacenter. In my experience, most admins in datacenters change
things through admin consoles or scripts so that there is an audit
history (in U.S. financial services institutions it is obligatory).
Of course admins in less bureaucratic environments may tweak XML
configuration files (I should have worded my previous response
better), but my point was very few admins crack deployment archives
and mess with application artifacts. That is extremely bad practice
and something we should never encourage. This was a fundamental
design principal we had in the spec group (i.e. deployment units
should not be cracked) and hence we included an override mechanism in
the Assembly Specification. For dynamic wiring, assemblers (a
different role than admins) would use some kind of tool - having them
edit an XML file would not be the best approach to this problem.
So, I just don't see the value in this use-case, although it would be
trivial for us to implement even if it promotes an anti-pattern and
unnecessarily complicates what we currently have.
>
>>> I'll also want a configuration or admin tool loading/saving
>>> modified SCDL to write things in the order that they were
>>> initially, not in a random order. As an application developer I'd
>>> like to have an SCA debugging tool showing me my components in a
>>> list in the right order as well. Also if I want to implement the
>>> model defined by the XML schemas in the spec using any of the
>>> DataBinding technologies out there, I'll end up with Lists, not
>>> Maps.
>>>
>> We have been using StAX just fine for this and it accommodates a
>> number of databinding solutions for extensions. Are you proposing
>> we revisit this decision made back before the M1 release to go
>> with STaX loading? If so, for what reasons? BTW, not all
>> databinding solutions will have problems - XStream will work just
>> fine with what we have. Also, are you sure about XMLBeans and JAXB
>> or are you just speaking about a current implementation of SDO?
>
> Not quite correct, the decision we made back before M1 was to go
> with StAX loading, write the loaders by hand for now, and see how
> the SDO team could generate this code after M1. Independent of
> that, I don't want to tie us to any specific data binding, so we
> better pick representations for model relationships that are
> commonly used by most databindings to represent XSD <element...
> maxOccurs="unbounded"/>, i.e. Lists, not Maps.
JAXB, Castor, XStream, and JiBX (through an shipped extension)
support Maps, and probably a number of other databinding solutions do
as well. But let's set that aside since there is a more important
issue...
The decision as I recall was twofold. First, go with a runtime model
that was natural for Java developers and supported Java idioms, not
the constraints of a particular databinding solution. In my book, if
a databinding solution cannot accommodate the requirements of the
runtime, it is not the right tool for the job, in this case, loading
of core configuration data (not extension configuration). Jeremy
chose to implement this requirement with StAX. It worked, was simple,
and provided the ability to have extension developers use their
databinding framework of choice to load required configuration
information (which may involve evaluating artifacts other than XML).
This last feature was important, as the runtime must be able to
handle multiple databinding technologies simultaneously.
The second part of the decision was to decouple the runtime from SDO,
not because people don't like SDO, but because it promotes choice,
modularity, and simplicity. This is entirely consistent with SCA,
which does not mandate SDO and which I imagine will be used with a
variety of databinding technologies (e.g. JAXB). This also promotes
modularity and simplicity as it allows people to come and work on (or
extend) the runtime without having to learn a SDO (or another
particular databinding technology).
Also, just to beat a dead horse further (how long have we been having
this debate ;-) ), to me, and probably a lot of other Java
developers, StAX is a pervasive and simple way of dealing with XML -
its in the javax namespace, pervasive in open source, and will be in
the JDK. Given that we can use SDO, JAXB, etc. to handle extensions,
what's the problem with using what we have? What benefit do we gain
by constraining the runtime model's use of very common (and in my
opinion effective) Java idioms?
>
>>
>>> Finally even if we decided to use Maps in some cases to provide
>>> keyed access to some elements of the model, we'd have to do it
>>> differently. For example a single Map containing all components,
>>> references and services in a composite (according to the spec
>>> they cannot have the same names) instead of three Maps like you
>>> have in Core2.
>>>
> And this is why LinkedHashMap will not help you here.
Again, this is trivial to implement and LinkedHashMap will do just
fine with many of the databinding solutions available today.
>
>>>>>
>>>>> - Core2 only defines implementation classes for the model, I
>>>>> think we should have interfaces + default implementation
>>>>> classes instead, like we had in M1, to allow for alternate
>>>>> implementations of the model.
>>>>
>>>> One of the most complex things with the M1 model was all the
>>>> interfaces involved, the need to pass factory implementations
>>>> around, the number of different factories involved (one per
>>>> extension implementation) and the potential issues with code
>>>> assuming its implementation of the factory was the one used.
>>>>
>>>> The core2 model uses concrete classes which are really just data
>>>> holders - there's no behaviour in them to be abstracted through
>>>> the interface. This gives a much simpler programming model for
>>>> extensions using the model.
>>>>
>>>> Do you have any scenarios that would require different
>>>> implementations of the model? Are they so different that they
>>>> might as well just use different classes?
>>>>
>>>
>>> I don't think that having just implementation classes is much
>>> simpler. If you interact with the model SPI, reading interfaces
>>> is simpler IMO and more suitable for inclusion in a specification
>>> document... allowing multiple implementations of these
>>> interfaces. Also we have to support the whole lifecycle of an SCA
>>> application (development, deploy/install, runtime, admin etc.)
>>> and I'd like to allow some flexibility for different tools,
>>> running at different times to use different implementations of
>>> the assembly model interfaces.
>>>
>> Oisin from the STP project said the POJO based approach would suit
>> them just fine. I don't see the complexity. On the contrary, all
>> of the AssemblyFactories we had in M1 lead IMO to a massive
>> antipattern where they were passed throughout the core. I'm happy
>> to walk through the relevant code if people are interested. All
>> the factories did was new up a POJO. Not worth the complexity in
>> my opinion but I'm happy to compare the work in the sandbox with
>> your proposal if you'd like to walk us through it.
>
> When the runtime depends on too many factories, this is the
> manifestation of bigger coupling problems. The factories for all
> the extensions should not be visible at all from the core runtime,
> and if we externalize the WSDL and Java interface support and the
> Java implementation support our of core like I'm proposing, you're
> not dealing with many factories.
>
But we will be. Factories will be proliferated through the entire
loader infrastructure unless the loaders new the factories up and
that seems a bit superfluous given the factories themselves just new
up POJOs. Just new the POJOs up and things are simple. Also,
factories will be proliferated across or testcases which was also a
cause of needless complexity in M1.
> I am sure that tooling projects will need to add much to this
> model, support for events, change tracking, tracking between XML
> elements and model objects to provider proper feedback to
> application developers, integration with modeling technologies used
> in the tooling world, support for cloning maybe... tons of things.
> I spent several years developing tools so I think I know what I'm
> talking about here. The first thing I'll ask as a tooling developer
> is: please give me interfaces so I can hook what I need in the
> implementations.
>
And the tooling people should go do all of that (if they want to) but
keep it out of the runtime (and vice versa) ;-) ! We are writing code
for a runtime, not a tooling environment. Use change notification,
interfaces, round-tripping support, cloning, whatever when writing a
tool. In other words, tooling people should build the technology that
is right for them and the runtime people likewise. Sharing a discrete
(and relatively small) number of classes really doesn't buy that much
given the divergence in use cases between tooling and runtime. If we
can do it, great, but we should not compromise the runtime or tooling
to do so.
Also, I'm not sure your requirement for interfaces is shared by
everyone on the tooling side. Oisin (Eclipse STP) indicated he would
be fine with the POJO approach.
> I'm happy to walk people through the interfaces or answer any
> questions on the list,
Great, how about doing a diff between core2 and your proposed
approach and how core2 could be improved to accomodate your issues?
>
>>>>>
>>>>> - Over usage of Java Generics breaks flexibility in some cases,
>>>>> for example Component<I extends Implementation> will force you
>>>>> to recreate an instance of Component to swap its implementation
>>>>> with an implementation of a different type (and lose all the
>>>>> wires going in/out of the component).
>>>>
>>>> There may be cases where generics may be overkill but I don't
>>>> think that really requires us to throw out the model. There are
>>>> other cases where the use of wildcards would be appropriate; for
>>>> example, in the scenario you give here you could just create a
>>>> Component<Implementation> to allow different types of
>>>> implementation to be used.
>>>>
>>> Then instead of
>>> Component<Implementation> {
>>> Implementation getImplementation();
>>> }
>>> I think we can just do
>>> Component {
>>> Implementation getImplementation();
>>> }
>>> What we have now in core2 is overkill IMO.
>>>
>> then do we need to cast to the right impl type?
>
> The core runtime should not have to cast, simply because it should
> not depend on any component implementation type (not even the Java
> or System implementation types).
A loader will need to cast the above.
>
>>
>>>>>
>>>>> - Core2 defines ReferenceDefinitions (without bindings) and
>>>>> BoundReferenceDefinitions (with bindings). IMO there are
>>>>> Reference types and Reference instances and both can have
>>>>> bindings.
>>>>> or Reference.
>>>>
>>>> I'm with you here - we need to refactor the way bindings are
>>>> handled for both Service and Reference. One thing the sandbox
>>>> model is missing is the ability to associate multiple bindings
>>>> with a single Service/Reference.
>>>
>>> My main point is not about supporting multiple bindings on a
>>> Service or Reference. I think this is secondary and the
>>> interfaces I put in my sandbox to support a design discussion
>>> don't even have that either. My point is that Services,
>>> References, and their instantiation by Components are at the
>>> foundation of the SCA assembly model... and therefore need to be
>>> modeled correctly. I'm proposing a different design, illustrated
>>> by the interfaces I checked in.
>>>
>> Could you elaborate?
>
> I think it should be very simple:
> - Component types have service and reference types
> - Components are instances of component types and have services and
> references, which are instances of the service and reference types
> - Service and reference types can have bindings
> - Bindings can be overriden in service and reference instances
> This is clear when you look at a Composite. A composite is a
> Component Type, has service and reference types (aka composite
> services and references) which can have bindings.
> A component can be implemented by a Composite, has services and
> references, which can use the (default) bindings from their
> respective service and reference types, or specify (override)
> bindings.
>
I would find it extremely useful if you could perhaps compare this
with what we have in core2 and point to how core2 could be improved
to accommodate some of your concerns in this area.
>>>>
>>>>>
>>>>> - I think that Remotable should be on Interface and not Service.
>>>>
>>>> I agree Service is wrong and that it should be on
>>>> ServiceContract. Thanks for catching it.
>>>>
>>>>>
>>>>> - Scope should be defined in the Java component implementation,
>>>>> separate from the core model.
>>>>
>>>> Scope is not a Java specific concept.
>>>> Interaction scope (stateless vs. stateful) can apply to any
>>>> ServiceContract.
>>>> Container scope is the contract between an implementation and a
>>>> ScopeContainer and applies to any implementation type that can
>>>> support stateful interactions. This would include JavaScript,
>>>> Groovy, C++, ... I think that means that support for state
>>>> management (which is what scope is configuring) belongs in the
>>>> core with the configuration metadata supplied by the
>>>> implementation type.
>>>>
>>>
>>> I don't think it's quite right. First interaction scopes are
>>> defined on interfaces and not service contracts. Also they
>>> control whether an interface is conversational or not,
>>> independent from any state management.
>>> Anyway I was talking about a different scope, the implementation
>>> scope defined in the Java C&I spec, which governs the lifecycle
>>> of Java component implementation instances. I think the
>>> definition and implementation of lifecycle management will vary
>>> greatly depending on the component implementation type, for
>>> example Java component implementations and BPEL component
>>> implementations typically deal with this in a very different way.
>> Well, I don't think that's the case at all and actually there is a
>> concept of implementation scope in assembly - it just varies by
>> implementation type, which is entirely consistent with our design.
>> BPEL is the odd case, and this came up as we wrote the scope
>> changes into the spec (Ken did a lot of the work here). Across
>> many implementation types, e.g. Groovy, JavaScript, Ruby, Jython,
>> etc. (maybe even C++) I see use for the same scopes as in Java. Do
>> you disagree?
>>
>> Also, I'm curious why you think the scope containers complicate
>> the core and need to be moved out? Or are you saying this based on
>> your reading of the spec? They seem quite simple to me.
>
> I'm saying that scope management is specific to the implementation
> type and therefore needs to be made pluggable, i.e. moved out of
> core. The Java scope management is just one example of scope
> management.
>
We have it partly pluggable. There are just a few more things to do.
Would you care to help out on this?
I think it makes sense to keep commonly used scopes in core and have
implementation specific ones as plugins, not necessarily tied to an
implementation (outside of BPEL, most scopes are probably applicable
to a wide variety of types).
>>
>>> Therefore, in my view state/lifecycle management should be left
>>> to the component implementation contributions and not belong to
>>> core.
>>>
>> I think this would lead to over-complication, particularly for the
>> extension developer. Right now, scope containers can be reused. In
>> particular, how would conversational services be handled? If I
>> want to use module or session scope containers for my Groovy
>> script, then I'd have to write those rather then just reuse what
>> the core gives me? Also, be reusing, we also allow an additional
>> extension type in terms of scope. For example, someone could add a
>> distributed cache scope and have that shared by Groovy, Java,
>> whatever.
>>
>> I'll also note two things. Getting scope containers to work
>> properly with instance tracking is not trivial. I'd hate to push
>> that on extension developers. Second, this basic design has been
>> there since before M1. Why wasn't this brought up before since it
>> is such a significant issue?
>>>
>>>>>
>>>>> - Java and WSDL interfaces should be defined separate from the
>>>>> core model, we need to support multiple interface definition
>>>>> languages supported by plugins, not in the core.
>>>>
>>>> The model supports generic IDL through the use of
>>>> ServiceContract. Java and WSDL are two forms of IDL that are
>>>> mandated by the specification. This is really just a question of
>>>> where those implementations are packaged and again I don't think
>>>> this warrants a rewrite.
>>>>
>>>
>>> Packaging issues are important and often hide bigger dependency/
>>> coupling problems. I think we should package the support for Java
>>> and WSDL interfaces separate from the core to prevent any
>>> coupling between the two, and also give people who will have to
>>> support new interface definition languages a better template to
>>> follow.
>>>
>>> Individual issues do not warrant a rewrite. What about the sum of
>>> many issues?
>>>
>> None of the issues warrant a rewrite, not even the sum. Most of
>> your criticisms seem centered around the model which is fairly
>> decoupled from the bulk of the core2 runtime. Even if we adopted
>> your changes wholesale, I'd doubt they would change the core2
>> runtime significantly. Even the scope containers could be moved
>> out without breaking anything and very little code changes,
>> although that would be a mistake IMO. I'm sorry but I fail to see
>> the need for a rewrite.
>
> I am not proposing a rewrite of the whole runtime, see my original
> email, it's not a whole rewrite. I'm proposing a staged / baby step
> approach integrating the good work from M1 and the sandbox and new
> discussions where I think what we have is not right or where new
> ideas from the group come up.
>
Why not just do this starting from core2? If it's not a rewrite, then
it sounds like incremental improvements. We could start from
scenarios and go through doing this. I think this approach would
accommodate those that wish to focus on end-user scenarios and those
that are focused on more technology scenarios such as conversations.
I believe we need to be inclusive of both, and cannot force one
approach to doing scenarios on the entire community. Also, I think
this is the correct *long-term* way to getting more people involved.
We will always have newcomers and we need to ensure the runtime is
modular enough so they can work their way in as deep as they are
interested. Doing a "baby-step" rebuild just for the people that are
part of the community now doesn't really teach us how to continuously
grow the community.
> I'm starting with the model SPI because I think that having the
> assembly model right is critical for an assembly runtime. Most of
> the ideas here have an impact on the architecture of the runtime,
> so I thought this was a good starting point, and also a good base
> of discussion to help all in our community discuss and understand
> better the new recursive composition model.
>
And here's where I think the crux of the disagreement lies...and it's
the same debate that started over a year ago and I thought we had
gotten past. The *configuration* model should be decoupled from the
rest of the runtime, not determine its architecture. Also, the
configuration model is only one small part of the SPI/API (I think we
need to begin to make this distinction as suggested by Jeremy).
Similarly, the SCA specifications are not blueprints for a runtime
design; they describe a wiring and programming model for service-
based applications. If multiple runtimes with divergent architectures
cannot implement SCA, then it will have failed as a set of
specifications.
Of course, that is not to say we should not have SCA concepts
reflected in the runtime architecture. Along these lines, one of the
key changes we made in core2 was to do this better with the actual
runtime structures. Namely, we reserved the "Component" naming scheme
for runtime artifacts as opposed to the configuration model (they
used to be called "Context"), as those will be dealt with by
developers working on core and extenders much more than the
configuration model will be.
Also, the model is just an in-memory representation of configuration
data, nothing more and nothing less. One of the key culprits in the
M1 architecture was the fact that we did not have this clean
distinction. We did agree to have it, we just did not evolve the code
enough in that direction, and that was one of the key driving factors
for creating core2.
>
>>>>> - Implementation should extend ComponentType IMO instead of
>>>>> pointing to it, and we may even be able to simplify and just
>>>>> remove Implementation. Also I am not sure why we need to
>>>>> distinguish between AtomicImplementation and
>>>>> CompositeImplementation.
>>>>
>>>> One of the problems the assembly spec has is that it is
>>>> difficult to do top-down design because you cannot link a
>>>> component to a componentType without having an implementation. I
>>>> agree this is an area that we (and the spec) need to sort out.
>>>>
>>>> IMO a component is associated with one componentType but may
>>>> have multiple implementations so I don't think they are quite
>>>> the same thing or that either can be removed.
>>>>
>>>> AtomicImplementation is a marker for implementations that cannot
>>>> have children.
>>>
>>> In my view a component has a type. The ComponentType is either
>>> abstract (just defining the types of services offered, references
>>> used, and properties that can be configured), or concrete. A POJO
>>> component implementation is a concrete ComponentType.
>>>
>> Perhaps we could walk through your model?
>
> Yes, the interfaces I put under m2-design are there to illustrate
> ideas and support a design discussion. I'm working on some UML
> diagrams that I think will help too.
Great, perhaps another area we could discuss in the context of
improvements to core2?
>
>>>>
>>>>
>>>>>
>>>>> - Support for Composite Includes is missing, this is a
>>>>> significant part of the recursive composition model (half of
>>>>> it, one of the two ways to nest composites).
>>>>
>>>> It's not really half - it's really just a very small part of the
>>>> model, comparable to the <import> element we used to support in
>>>> M1. Again, I don't see why we need to rewrite the model to add
>>>> this in. Quite the opposite: you've said you've been looking for
>>>> way to engage and this could be it.
>>>
>>> I disagree. Includes are a very significant part of the assembly
>>> model (the other part is the ability to use a composite as a
>>> component implementation). Two examples:
>>> - An included composite is the equivalent of a module fragment in
>>> the 0.9 spec. This concept is key to allowing a team to work on
>>> various pieces of an application, split in multiple composites,
>>> included in a composite representing the application.
>>> - When (formerly subsystems) composites get deployed to an SCA
>>> system, they are actually included in that system, rather than
>>> being used as component implementations.
>>>
>> It's not "half" of the recursive model. In fact, most of the time
>> we spent in the spec group was grappling with other issues related
>> to recursion.
>
> I don't see an immediate relation between the time spent by the
> spec group on a specific item and its importance for application
> developers. I am looking at this from an application developer
> point of view and saying that I'll use Includes as much as
> composition through (composite) components. Includes will allow a
> team to distribute work on an SCA application and also represent a
> key concept for system composition. I am starting to look at
> scenarios and can actually see the usage of Includes in almost all
> of them, but having trouble finding good use cases for the other
> form of composition (nested component implementations). So I stand
> by my statement that understanding how includes work is key here.
>
Yep, and that's why I originally pushed the include mechanism in the
spec group over a year ago (I didn't push the fragment classpath
approach though, so don't blame me for that one). However, to say
that is "half" of implementing the recursive model leaves the detail
out. In this context Jeremy's metaphor of the paddling duck is
apropos. The runtime should be like a duck in that on the surface it
just merrily moves along the water but under the surface it is
paddling away. The same for the runtime: from the app developer's
perspective things just work and they are simple, but under the
covers the runtime is managing all of the complexity. In my opinion,
there is a lot more complexity to recursion than what the app
developer sees. Hopefully in the end, the runtime architecture is
graceful and we don't wind up with an ugly duckling as we did in M1 ;-)
>>
>>>>
>>>>>
>>>>> This list is not exhaustive... Another idea would be to
>>>>> externalize support for Composites in a separate plugin not
>>>>> part of the core service model (since there may be other ways
>>>>> to compose services in addition to an SCA composite, with
>>>>> Spring or other similar programming models), I'd like to know
>>>>> what people think about that.
>>>>>
>>>>
>>>> Having the composite implementation type in the core does not
>>>> preclude that - again, it's just packaging for ease-of-use.
>>>
>>> I think it's more significant than packaging. Are you saying that
>>> we could move the code supporting composites out of core2 without
>>> breaking the code in core2?
>>>
>> Why would we do this? We can already support multiple composite
>> implementation types - have a look at the Spring extension. That
>> just sounds like unnecessary complication.
> Why? to avoid unecessary and dangerous coupling that will hurt us
> when we try to evolve this runtime. How to illustrate that? how
> about trying to move code supporting composites out of core2? I'm
> realizing I'm asking the same question again... but I think it's an
> important question, sill unanswered.
I don't think moving packages around guarantees dangerous coupling;
pluralism, vigilance, and good design do. It may, though,
unnecessarily compound complexity. We have a Spring extension. How
about adding more composite types to core2? This way, we can expand
the number of containers, achieve a level of pluralism, watch that we
don't over-couple, and derive a good extension design?
>
>>
>>>
>>>>
>>>> You seem to have the impression that the core is sealed and that
>>>> we only support things that are included within it. That is not
>>>> the case. The only place we need things bundled with the core is
>>>> in the bootstrap phase - specifically, we need them bundled with
>>>> the primordial deployer. The actual runtime is created from the
>>>> SCDL passed to that primordial deployer, can contain any mix of
>>>> components and need not contain any of the infrastructure used
>>>> to boot it.
>>>>
>>>>> I just checked in sandbox/sebastien/m2-design/model.spi a set
>>>>> of new interfaces. This is just an initial strawman to trigger
>>>>> a constructive discussion and ideas on how to best represent
>>>>> the recursive model. I also need help to define a scenario (not
>>>>> unit test cases, but an end to end sample application) to help
>>>>> put the recursive composition model in perspective and make
>>>>> sure we all understand it the same way.
>>>>>
>>>>
>>>> I am troubled that you have chosen to start on your own codebase
>>>> at a time when most of us have been trying to have constructive
>>>> discussion on this list. Based on the approach you proposed in
>>>> your original email I would have hoped that we could have
>>>> started with your end-user scenarios and had a chance to explore
>>>> how they could be supported by M1, the sandbox, or some other
>>>> code before starting another codebase. I'm disappointed that,
>>>> having started this very thread nearly a week ago with the
>>>> premise of community, your first response on it was to commit a
>>>> large chunk of independent code rather than follow up with any
>>>> of the other people who have already contributed to the discussion.
>>>>
>>>> I think discussion led to compromise and consensus on the
>>>> scenario-driven approach that you proposed. As shown above and
>>>> in other recent threads, there's plenty of room for improvements
>>>> and/or new features in our current code and a willingness to
>>>> discuss them, albeit in terms of technical merit rather than
>>>> personal opinion. I hope you can find a way to join in rather
>>>> than forge your own path.
>>>>
>>>> --Jeremy
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>> --Jean-Sebastien
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: Proposed approach for M2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
More comments inline.
Jim Marino wrote:
> Comments inline
> On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
>
>> Jeremy,
>>
>> I won't comment on your attacks at the bottom of this email. I was
>> hoping for a more constructive technical discussion. I added my
>> answers and comments on the specific technical issues inline.
>>
>> Jeremy Boynes wrote:
>>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>>>>
>>>> My proposal is not to merge M1 and the core2 sandbox. I am
>>>> proposing to start a new fresh code stream and build the runtime
>>>> through baby steps. We may be able to reuse some pieces of existing
>>>> code, but more important is to engage our community in this
>>>> exercise and integrate the new ideas that will emerge from this.
>>>>
>>>
>>> I don't believe the two issues are necessarily coupled. Quite a few
>>> members of the community are engaged on the sandbox code already and
>>> we could work with you to improve that rather having to throw
>>> everything out and start over with all new ideas.
>>>
>>>>
>>>> Here's an example where I'm struggling with both M1 and the core2
>>>> sandbox and thinking that we can do better if we start with a new
>>>> fresh stream: our (recursive) assembly metadata model.
>>>>
>>>> - M1 does not implement the recursive composition model and would
>>>> require significant changes to support it. Core2 is an attempt to
>>>> implement it but I'm not sure it's quite right, and also think that
>>>> it can be simplified.
>>>
>>> It would really help if you could come up with concrete areas where
>>> it is not right or where it could be simplified - for example, end
>>> user scenarios that are not supported.
>>>
>>>>
>>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>>>> think M1 was better since it allowed to keep the order in the
>>>> relationships.
>>>
>>> There's nothing I remember in the assembly spec where order matters.
>>> On the other hand there are many areas where things are keyed by a
>>> name which has to be unique. This seems like a natural mapping
>>> (sorry) to a Map. In M1 I started to move toward simple map
>>> structures but you replaced it with what seemed like a fairly
>>> complicated specialized List implementation that sent notifications
>>> that updated a Map anyway. Given the desire for simplification, are
>>> there any end-user scenarios that require ordering to be preserved
>>> and that can't be supported with a basic HashMap or LinkedHashMap?
>>>
>> As an administrator I'll want my administration tool to display
>> components displayed in the order I declared them in SCDL.
> SCDL isn't the only form assembly can be serialized to/from. Also, if
> I were an admin, I'd probably want to sort the components according to
> some useful criteria, not how they are listed in a SCDL as most admins
> will never look at XML. One could always use LikedHashMap though.
>
Maybe SCDL isn't the only form but this is not relevant, we need to
support SCDL don't we? As soon as you put assembly elements in a
document that a user/developer can edit the order is relevant.
I disagree with your statement about administrators. They often look at
and work with XML configuration files. If you want to support other sort
criteria in addition that's fine, but admin, config and editing tools
need to at least support the order from the XML document.
>> I'll also want a configuration or admin tool loading/saving modified
>> SCDL to write things in the order that they were initially, not in a
>> random order. As an application developer I'd like to have an SCA
>> debugging tool showing me my components in a list in the right order
>> as well. Also if I want to implement the model defined by the XML
>> schemas in the spec using any of the DataBinding technologies out
>> there, I'll end up with Lists, not Maps.
>>
> We have been using StAX just fine for this and it accommodates a
> number of databinding solutions for extensions. Are you proposing we
> revisit this decision made back before the M1 release to go with STaX
> loading? If so, for what reasons? BTW, not all databinding solutions
> will have problems - XStream will work just fine with what we have.
> Also, are you sure about XMLBeans and JAXB or are you just speaking
> about a current implementation of SDO?
Not quite correct, the decision we made back before M1 was to go with
StAX loading, write the loaders by hand for now, and see how the SDO
team could generate this code after M1. Independent of that, I don't
want to tie us to any specific data binding, so we better pick
representations for model relationships that are commonly used by most
databindings to represent XSD <element... maxOccurs="unbounded"/>, i.e.
Lists, not Maps.
>
>> Finally even if we decided to use Maps in some cases to provide keyed
>> access to some elements of the model, we'd have to do it differently.
>> For example a single Map containing all components, references and
>> services in a composite (according to the spec they cannot have the
>> same names) instead of three Maps like you have in Core2.
>>
And this is why LinkedHashMap will not help you here.
>>>>
>>>> - Core2 only defines implementation classes for the model, I think
>>>> we should have interfaces + default implementation classes instead,
>>>> like we had in M1, to allow for alternate implementations of the
>>>> model.
>>>
>>> One of the most complex things with the M1 model was all the
>>> interfaces involved, the need to pass factory implementations
>>> around, the number of different factories involved (one per
>>> extension implementation) and the potential issues with code
>>> assuming its implementation of the factory was the one used.
>>>
>>> The core2 model uses concrete classes which are really just data
>>> holders - there's no behaviour in them to be abstracted through the
>>> interface. This gives a much simpler programming model for
>>> extensions using the model.
>>>
>>> Do you have any scenarios that would require different
>>> implementations of the model? Are they so different that they might
>>> as well just use different classes?
>>>
>>
>> I don't think that having just implementation classes is much
>> simpler. If you interact with the model SPI, reading interfaces is
>> simpler IMO and more suitable for inclusion in a specification
>> document... allowing multiple implementations of these interfaces.
>> Also we have to support the whole lifecycle of an SCA application
>> (development, deploy/install, runtime, admin etc.) and I'd like to
>> allow some flexibility for different tools, running at different
>> times to use different implementations of the assembly model interfaces.
>>
> Oisin from the STP project said the POJO based approach would suit
> them just fine. I don't see the complexity. On the contrary, all of
> the AssemblyFactories we had in M1 lead IMO to a massive antipattern
> where they were passed throughout the core. I'm happy to walk through
> the relevant code if people are interested. All the factories did was
> new up a POJO. Not worth the complexity in my opinion but I'm happy to
> compare the work in the sandbox with your proposal if you'd like to
> walk us through it.
When the runtime depends on too many factories, this is the
manifestation of bigger coupling problems. The factories for all the
extensions should not be visible at all from the core runtime, and if we
externalize the WSDL and Java interface support and the Java
implementation support our of core like I'm proposing, you're not
dealing with many factories.
I am sure that tooling projects will need to add much to this model,
support for events, change tracking, tracking between XML elements and
model objects to provider proper feedback to application developers,
integration with modeling technologies used in the tooling world,
support for cloning maybe... tons of things. I spent several years
developing tools so I think I know what I'm talking about here. The
first thing I'll ask as a tooling developer is: please give me
interfaces so I can hook what I need in the implementations.
I'm happy to walk people through the interfaces or answer any questions
on the list,
>>>>
>>>> - Over usage of Java Generics breaks flexibility in some cases, for
>>>> example Component<I extends Implementation> will force you to
>>>> recreate an instance of Component to swap its implementation with
>>>> an implementation of a different type (and lose all the wires going
>>>> in/out of the component).
>>>
>>> There may be cases where generics may be overkill but I don't think
>>> that really requires us to throw out the model. There are other
>>> cases where the use of wildcards would be appropriate; for example,
>>> in the scenario you give here you could just create a
>>> Component<Implementation> to allow different types of implementation
>>> to be used.
>>>
>> Then instead of
>> Component<Implementation> {
>> Implementation getImplementation();
>> }
>> I think we can just do
>> Component {
>> Implementation getImplementation();
>> }
>> What we have now in core2 is overkill IMO.
>>
> then do we need to cast to the right impl type?
The core runtime should not have to cast, simply because it should not
depend on any component implementation type (not even the Java or System
implementation types).
>
>>>>
>>>> - Core2 defines ReferenceDefinitions (without bindings) and
>>>> BoundReferenceDefinitions (with bindings). IMO there are Reference
>>>> types and Reference instances and both can have bindings.
>>>> or Reference.
>>>
>>> I'm with you here - we need to refactor the way bindings are handled
>>> for both Service and Reference. One thing the sandbox model is
>>> missing is the ability to associate multiple bindings with a single
>>> Service/Reference.
>>
>> My main point is not about supporting multiple bindings on a Service
>> or Reference. I think this is secondary and the interfaces I put in
>> my sandbox to support a design discussion don't even have that
>> either. My point is that Services, References, and their
>> instantiation by Components are at the foundation of the SCA assembly
>> model... and therefore need to be modeled correctly. I'm proposing a
>> different design, illustrated by the interfaces I checked in.
>>
> Could you elaborate?
I think it should be very simple:
- Component types have service and reference types
- Components are instances of component types and have services and
references, which are instances of the service and reference types
- Service and reference types can have bindings
- Bindings can be overriden in service and reference instances
This is clear when you look at a Composite. A composite is a Component
Type, has service and reference types (aka composite services and
references) which can have bindings.
A component can be implemented by a Composite, has services and
references, which can use the (default) bindings from their respective
service and reference types, or specify (override) bindings.
>>>
>>>>
>>>> - I think that Remotable should be on Interface and not Service.
>>>
>>> I agree Service is wrong and that it should be on ServiceContract.
>>> Thanks for catching it.
>>>
>>>>
>>>> - Scope should be defined in the Java component implementation,
>>>> separate from the core model.
>>>
>>> Scope is not a Java specific concept.
>>> Interaction scope (stateless vs. stateful) can apply to any
>>> ServiceContract.
>>> Container scope is the contract between an implementation and a
>>> ScopeContainer and applies to any implementation type that can
>>> support stateful interactions. This would include JavaScript,
>>> Groovy, C++, ... I think that means that support for state
>>> management (which is what scope is configuring) belongs in the core
>>> with the configuration metadata supplied by the implementation type.
>>>
>>
>> I don't think it's quite right. First interaction scopes are defined
>> on interfaces and not service contracts. Also they control whether
>> an interface is conversational or not, independent from any state
>> management.
>> Anyway I was talking about a different scope, the implementation
>> scope defined in the Java C&I spec, which governs the lifecycle of
>> Java component implementation instances. I think the definition and
>> implementation of lifecycle management will vary greatly depending on
>> the component implementation type, for example Java component
>> implementations and BPEL component implementations typically deal
>> with this in a very different way.
> Well, I don't think that's the case at all and actually there is a
> concept of implementation scope in assembly - it just varies by
> implementation type, which is entirely consistent with our design.
> BPEL is the odd case, and this came up as we wrote the scope changes
> into the spec (Ken did a lot of the work here). Across many
> implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
> (maybe even C++) I see use for the same scopes as in Java. Do you
> disagree?
>
> Also, I'm curious why you think the scope containers complicate the
> core and need to be moved out? Or are you saying this based on your
> reading of the spec? They seem quite simple to me.
I'm saying that scope management is specific to the implementation type
and therefore needs to be made pluggable, i.e. moved out of core. The
Java scope management is just one example of scope management.
>
>> Therefore, in my view state/lifecycle management should be left to
>> the component implementation contributions and not belong to core.
>>
> I think this would lead to over-complication, particularly for the
> extension developer. Right now, scope containers can be reused. In
> particular, how would conversational services be handled? If I want to
> use module or session scope containers for my Groovy script, then I'd
> have to write those rather then just reuse what the core gives me?
> Also, be reusing, we also allow an additional extension type in terms
> of scope. For example, someone could add a distributed cache scope and
> have that shared by Groovy, Java, whatever.
>
> I'll also note two things. Getting scope containers to work properly
> with instance tracking is not trivial. I'd hate to push that on
> extension developers. Second, this basic design has been there since
> before M1. Why wasn't this brought up before since it is such a
> significant issue?
>>
>>>>
>>>> - Java and WSDL interfaces should be defined separate from the core
>>>> model, we need to support multiple interface definition languages
>>>> supported by plugins, not in the core.
>>>
>>> The model supports generic IDL through the use of ServiceContract.
>>> Java and WSDL are two forms of IDL that are mandated by the
>>> specification. This is really just a question of where those
>>> implementations are packaged and again I don't think this warrants a
>>> rewrite.
>>>
>>
>> Packaging issues are important and often hide bigger
>> dependency/coupling problems. I think we should package the support
>> for Java and WSDL interfaces separate from the core to prevent any
>> coupling between the two, and also give people who will have to
>> support new interface definition languages a better template to follow.
>>
>> Individual issues do not warrant a rewrite. What about the sum of
>> many issues?
>>
> None of the issues warrant a rewrite, not even the sum. Most of your
> criticisms seem centered around the model which is fairly decoupled
> from the bulk of the core2 runtime. Even if we adopted your changes
> wholesale, I'd doubt they would change the core2 runtime
> significantly. Even the scope containers could be moved out without
> breaking anything and very little code changes, although that would be
> a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
I am not proposing a rewrite of the whole runtime, see my original
email, it's not a whole rewrite. I'm proposing a staged / baby step
approach integrating the good work from M1 and the sandbox and new
discussions where I think what we have is not right or where new ideas
from the group come up.
I'm starting with the model SPI because I think that having the assembly
model right is critical for an assembly runtime. Most of the ideas here
have an impact on the architecture of the runtime, so I thought this was
a good starting point, and also a good base of discussion to help all in
our community discuss and understand better the new recursive
composition model.
>>>> - Implementation should extend ComponentType IMO instead of
>>>> pointing to it, and we may even be able to simplify and just remove
>>>> Implementation. Also I am not sure why we need to distinguish
>>>> between AtomicImplementation and CompositeImplementation.
>>>
>>> One of the problems the assembly spec has is that it is difficult to
>>> do top-down design because you cannot link a component to a
>>> componentType without having an implementation. I agree this is an
>>> area that we (and the spec) need to sort out.
>>>
>>> IMO a component is associated with one componentType but may have
>>> multiple implementations so I don't think they are quite the same
>>> thing or that either can be removed.
>>>
>>> AtomicImplementation is a marker for implementations that cannot
>>> have children.
>>
>> In my view a component has a type. The ComponentType is either
>> abstract (just defining the types of services offered, references
>> used, and properties that can be configured), or concrete. A POJO
>> component implementation is a concrete ComponentType.
>>
> Perhaps we could walk through your model?
Yes, the interfaces I put under m2-design are there to illustrate ideas
and support a design discussion. I'm working on some UML diagrams that I
think will help too.
>>>
>>>
>>>>
>>>> - Support for Composite Includes is missing, this is a significant
>>>> part of the recursive composition model (half of it, one of the two
>>>> ways to nest composites).
>>>
>>> It's not really half - it's really just a very small part of the
>>> model, comparable to the <import> element we used to support in M1.
>>> Again, I don't see why we need to rewrite the model to add this in.
>>> Quite the opposite: you've said you've been looking for way to
>>> engage and this could be it.
>>
>> I disagree. Includes are a very significant part of the assembly
>> model (the other part is the ability to use a composite as a
>> component implementation). Two examples:
>> - An included composite is the equivalent of a module fragment in the
>> 0.9 spec. This concept is key to allowing a team to work on various
>> pieces of an application, split in multiple composites, included in a
>> composite representing the application.
>> - When (formerly subsystems) composites get deployed to an SCA
>> system, they are actually included in that system, rather than being
>> used as component implementations.
>>
> It's not "half" of the recursive model. In fact, most of the time we
> spent in the spec group was grappling with other issues related to
> recursion.
I don't see an immediate relation between the time spent by the spec
group on a specific item and its importance for application developers.
I am looking at this from an application developer point of view and
saying that I'll use Includes as much as composition through (composite)
components. Includes will allow a team to distribute work on an SCA
application and also represent a key concept for system composition. I
am starting to look at scenarios and can actually see the usage of
Includes in almost all of them, but having trouble finding good use
cases for the other form of composition (nested component
implementations). So I stand by my statement that understanding how
includes work is key here.
>
>>>
>>>>
>>>> This list is not exhaustive... Another idea would be to externalize
>>>> support for Composites in a separate plugin not part of the core
>>>> service model (since there may be other ways to compose services in
>>>> addition to an SCA composite, with Spring or other similar
>>>> programming models), I'd like to know what people think about that.
>>>>
>>>
>>> Having the composite implementation type in the core does not
>>> preclude that - again, it's just packaging for ease-of-use.
>>
>> I think it's more significant than packaging. Are you saying that we
>> could move the code supporting composites out of core2 without
>> breaking the code in core2?
>>
> Why would we do this? We can already support multiple composite
> implementation types - have a look at the Spring extension. That just
> sounds like unnecessary complication.
Why? to avoid unecessary and dangerous coupling that will hurt us when
we try to evolve this runtime. How to illustrate that? how about trying
to move code supporting composites out of core2? I'm realizing I'm
asking the same question again... but I think it's an important
question, sill unanswered.
>
>>
>>>
>>> You seem to have the impression that the core is sealed and that we
>>> only support things that are included within it. That is not the
>>> case. The only place we need things bundled with the core is in the
>>> bootstrap phase - specifically, we need them bundled with the
>>> primordial deployer. The actual runtime is created from the SCDL
>>> passed to that primordial deployer, can contain any mix of
>>> components and need not contain any of the infrastructure used to
>>> boot it.
>>>
>>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>>> new interfaces. This is just an initial strawman to trigger a
>>>> constructive discussion and ideas on how to best represent the
>>>> recursive model. I also need help to define a scenario (not unit
>>>> test cases, but an end to end sample application) to help put the
>>>> recursive composition model in perspective and make sure we all
>>>> understand it the same way.
>>>>
>>>
>>> I am troubled that you have chosen to start on your own codebase at
>>> a time when most of us have been trying to have constructive
>>> discussion on this list. Based on the approach you proposed in your
>>> original email I would have hoped that we could have started with
>>> your end-user scenarios and had a chance to explore how they could
>>> be supported by M1, the sandbox, or some other code before starting
>>> another codebase. I'm disappointed that, having started this very
>>> thread nearly a week ago with the premise of community, your first
>>> response on it was to commit a large chunk of independent code
>>> rather than follow up with any of the other people who have already
>>> contributed to the discussion.
>>>
>>> I think discussion led to compromise and consensus on the
>>> scenario-driven approach that you proposed. As shown above and in
>>> other recent threads, there's plenty of room for improvements and/or
>>> new features in our current code and a willingness to discuss them,
>>> albeit in terms of technical merit rather than personal opinion. I
>>> hope you can find a way to join in rather than forge your own path.
>>>
>>> --Jeremy
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>> --Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
Comments inline
On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
> Jeremy,
>
> I won't comment on your attacks at the bottom of this email. I was
> hoping for a more constructive technical discussion. I added my
> answers and comments on the specific technical issues inline.
>
> Jeremy Boynes wrote:
>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>>>
>>> My proposal is not to merge M1 and the core2 sandbox. I am
>>> proposing to start a new fresh code stream and build the runtime
>>> through baby steps. We may be able to reuse some pieces of
>>> existing code, but more important is to engage our community in
>>> this exercise and integrate the new ideas that will emerge from
>>> this.
>>>
>>
>> I don't believe the two issues are necessarily coupled. Quite a
>> few members of the community are engaged on the sandbox code
>> already and we could work with you to improve that rather having
>> to throw everything out and start over with all new ideas.
>>
>>>
>>> Here's an example where I'm struggling with both M1 and the core2
>>> sandbox and thinking that we can do better if we start with a new
>>> fresh stream: our (recursive) assembly metadata model.
>>>
>>> - M1 does not implement the recursive composition model and would
>>> require significant changes to support it. Core2 is an attempt to
>>> implement it but I'm not sure it's quite right, and also think
>>> that it can be simplified.
>>
>> It would really help if you could come up with concrete areas
>> where it is not right or where it could be simplified - for
>> example, end user scenarios that are not supported.
>>
>>>
>>> - M1 used Lists to represent relationships, Core2 uses Maps, I
>>> think M1 was better since it allowed to keep the order in the
>>> relationships.
>>
>> There's nothing I remember in the assembly spec where order
>> matters. On the other hand there are many areas where things are
>> keyed by a name which has to be unique. This seems like a natural
>> mapping (sorry) to a Map. In M1 I started to move toward simple
>> map structures but you replaced it with what seemed like a fairly
>> complicated specialized List implementation that sent
>> notifications that updated a Map anyway. Given the desire for
>> simplification, are there any end-user scenarios that require
>> ordering to be preserved and that can't be supported with a basic
>> HashMap or LinkedHashMap?
>>
> As an administrator I'll want my administration tool to display
> components displayed in the order I declared them in SCDL.
SCDL isn't the only form assembly can be serialized to/from. Also, if
I were an admin, I'd probably want to sort the components according
to some useful criteria, not how they are listed in a SCDL as most
admins will never look at XML. One could always use LikedHashMap
though.
> I'll also want a configuration or admin tool loading/saving
> modified SCDL to write things in the order that they were
> initially, not in a random order. As an application developer I'd
> like to have an SCA debugging tool showing me my components in a
> list in the right order as well. Also if I want to implement the
> model defined by the XML schemas in the spec using any of the
> DataBinding technologies out there, I'll end up with Lists, not Maps.
>
We have been using StAX just fine for this and it accommodates a
number of databinding solutions for extensions. Are you proposing we
revisit this decision made back before the M1 release to go with STaX
loading? If so, for what reasons? BTW, not all databinding solutions
will have problems - XStream will work just fine with what we have.
Also, are you sure about XMLBeans and JAXB or are you just speaking
about a current implementation of SDO?
> Finally even if we decided to use Maps in some cases to provide
> keyed access to some elements of the model, we'd have to do it
> differently. For example a single Map containing all components,
> references and services in a composite (according to the spec they
> cannot have the same names) instead of three Maps like you have in
> Core2.
>
>>>
>>> - Core2 only defines implementation classes for the model, I
>>> think we should have interfaces + default implementation classes
>>> instead, like we had in M1, to allow for alternate
>>> implementations of the model.
>>
>> One of the most complex things with the M1 model was all the
>> interfaces involved, the need to pass factory implementations
>> around, the number of different factories involved (one per
>> extension implementation) and the potential issues with code
>> assuming its implementation of the factory was the one used.
>>
>> The core2 model uses concrete classes which are really just data
>> holders - there's no behaviour in them to be abstracted through
>> the interface. This gives a much simpler programming model for
>> extensions using the model.
>>
>> Do you have any scenarios that would require different
>> implementations of the model? Are they so different that they
>> might as well just use different classes?
>>
>
> I don't think that having just implementation classes is much
> simpler. If you interact with the model SPI, reading interfaces is
> simpler IMO and more suitable for inclusion in a specification
> document... allowing multiple implementations of these interfaces.
> Also we have to support the whole lifecycle of an SCA application
> (development, deploy/install, runtime, admin etc.) and I'd like to
> allow some flexibility for different tools, running at different
> times to use different implementations of the assembly model
> interfaces.
>
Oisin from the STP project said the POJO based approach would suit
them just fine. I don't see the complexity. On the contrary, all of
the AssemblyFactories we had in M1 lead IMO to a massive antipattern
where they were passed throughout the core. I'm happy to walk through
the relevant code if people are interested. All the factories did was
new up a POJO. Not worth the complexity in my opinion but I'm happy
to compare the work in the sandbox with your proposal if you'd like
to walk us through it.
>>>
>>> - Over usage of Java Generics breaks flexibility in some cases,
>>> for example Component<I extends Implementation> will force you to
>>> recreate an instance of Component to swap its implementation with
>>> an implementation of a different type (and lose all the wires
>>> going in/out of the component).
>>
>> There may be cases where generics may be overkill but I don't
>> think that really requires us to throw out the model. There are
>> other cases where the use of wildcards would be appropriate; for
>> example, in the scenario you give here you could just create a
>> Component<Implementation> to allow different types of
>> implementation to be used.
>>
> Then instead of
> Component<Implementation> {
> Implementation getImplementation();
> }
> I think we can just do
> Component {
> Implementation getImplementation();
> }
> What we have now in core2 is overkill IMO.
>
then do we need to cast to the right impl type?
>>>
>>> - Core2 defines ReferenceDefinitions (without bindings) and
>>> BoundReferenceDefinitions (with bindings). IMO there are
>>> Reference types and Reference instances and both can have bindings.
>>> or Reference.
>>
>> I'm with you here - we need to refactor the way bindings are
>> handled for both Service and Reference. One thing the sandbox
>> model is missing is the ability to associate multiple bindings
>> with a single Service/Reference.
>
> My main point is not about supporting multiple bindings on a
> Service or Reference. I think this is secondary and the interfaces
> I put in my sandbox to support a design discussion don't even have
> that either. My point is that Services, References, and their
> instantiation by Components are at the foundation of the SCA
> assembly model... and therefore need to be modeled correctly. I'm
> proposing a different design, illustrated by the interfaces I
> checked in.
>
Could you elaborate?
>>
>>>
>>> - I think that Remotable should be on Interface and not Service.
>>
>> I agree Service is wrong and that it should be on ServiceContract.
>> Thanks for catching it.
>>
>>>
>>> - Scope should be defined in the Java component implementation,
>>> separate from the core model.
>>
>> Scope is not a Java specific concept.
>> Interaction scope (stateless vs. stateful) can apply to any
>> ServiceContract.
>> Container scope is the contract between an implementation and a
>> ScopeContainer and applies to any implementation type that can
>> support stateful interactions. This would include JavaScript,
>> Groovy, C++, ... I think that means that support for state
>> management (which is what scope is configuring) belongs in the
>> core with the configuration metadata supplied by the
>> implementation type.
>>
>
> I don't think it's quite right. First interaction scopes are
> defined on interfaces and not service contracts. Also they control
> whether an interface is conversational or not, independent from any
> state management.
> Anyway I was talking about a different scope, the implementation
> scope defined in the Java C&I spec, which governs the lifecycle of
> Java component implementation instances. I think the definition and
> implementation of lifecycle management will vary greatly depending
> on the component implementation type, for example Java component
> implementations and BPEL component implementations typically deal
> with this in a very different way.
Well, I don't think that's the case at all and actually there is a
concept of implementation scope in assembly - it just varies by
implementation type, which is entirely consistent with our design.
BPEL is the odd case, and this came up as we wrote the scope changes
into the spec (Ken did a lot of the work here). Across many
implementation types, e.g. Groovy, JavaScript, Ruby, Jython, etc.
(maybe even C++) I see use for the same scopes as in Java. Do you
disagree?
Also, I'm curious why you think the scope containers complicate the
core and need to be moved out? Or are you saying this based on your
reading of the spec? They seem quite simple to me.
> Therefore, in my view state/lifecycle management should be left to
> the component implementation contributions and not belong to core.
>
I think this would lead to over-complication, particularly for the
extension developer. Right now, scope containers can be reused. In
particular, how would conversational services be handled? If I want
to use module or session scope containers for my Groovy script, then
I'd have to write those rather then just reuse what the core gives
me? Also, be reusing, we also allow an additional extension type in
terms of scope. For example, someone could add a distributed cache
scope and have that shared by Groovy, Java, whatever.
I'll also note two things. Getting scope containers to work properly
with instance tracking is not trivial. I'd hate to push that on
extension developers. Second, this basic design has been there since
before M1. Why wasn't this brought up before since it is such a
significant issue?
>
>>>
>>> - Java and WSDL interfaces should be defined separate from the
>>> core model, we need to support multiple interface definition
>>> languages supported by plugins, not in the core.
>>
>> The model supports generic IDL through the use of ServiceContract.
>> Java and WSDL are two forms of IDL that are mandated by the
>> specification. This is really just a question of where those
>> implementations are packaged and again I don't think this warrants
>> a rewrite.
>>
>
> Packaging issues are important and often hide bigger dependency/
> coupling problems. I think we should package the support for Java
> and WSDL interfaces separate from the core to prevent any coupling
> between the two, and also give people who will have to support new
> interface definition languages a better template to follow.
>
> Individual issues do not warrant a rewrite. What about the sum of
> many issues?
>
None of the issues warrant a rewrite, not even the sum. Most of your
criticisms seem centered around the model which is fairly decoupled
from the bulk of the core2 runtime. Even if we adopted your changes
wholesale, I'd doubt they would change the core2 runtime
significantly. Even the scope containers could be moved out without
breaking anything and very little code changes, although that would
be a mistake IMO. I'm sorry but I fail to see the need for a rewrite.
>>>
>>> - Implementation should extend ComponentType IMO instead of
>>> pointing to it, and we may even be able to simplify and just
>>> remove Implementation. Also I am not sure why we need to
>>> distinguish between AtomicImplementation and
>>> CompositeImplementation.
>>
>> One of the problems the assembly spec has is that it is difficult
>> to do top-down design because you cannot link a component to a
>> componentType without having an implementation. I agree this is an
>> area that we (and the spec) need to sort out.
>>
>> IMO a component is associated with one componentType but may have
>> multiple implementations so I don't think they are quite the same
>> thing or that either can be removed.
>>
>> AtomicImplementation is a marker for implementations that cannot
>> have children.
>
> In my view a component has a type. The ComponentType is either
> abstract (just defining the types of services offered, references
> used, and properties that can be configured), or concrete. A POJO
> component implementation is a concrete ComponentType.
>
Perhaps we could walk through your model?
>>
>>
>>>
>>> - Support for Composite Includes is missing, this is a
>>> significant part of the recursive composition model (half of it,
>>> one of the two ways to nest composites).
>>
>> It's not really half - it's really just a very small part of the
>> model, comparable to the <import> element we used to support in
>> M1. Again, I don't see why we need to rewrite the model to add
>> this in. Quite the opposite: you've said you've been looking for
>> way to engage and this could be it.
>
> I disagree. Includes are a very significant part of the assembly
> model (the other part is the ability to use a composite as a
> component implementation). Two examples:
> - An included composite is the equivalent of a module fragment in
> the 0.9 spec. This concept is key to allowing a team to work on
> various pieces of an application, split in multiple composites,
> included in a composite representing the application.
> - When (formerly subsystems) composites get deployed to an SCA
> system, they are actually included in that system, rather than
> being used as component implementations.
>
It's not "half" of the recursive model. In fact, most of the time we
spent in the spec group was grappling with other issues related to
recursion.
>>
>>>
>>> This list is not exhaustive... Another idea would be to
>>> externalize support for Composites in a separate plugin not part
>>> of the core service model (since there may be other ways to
>>> compose services in addition to an SCA composite, with Spring or
>>> other similar programming models), I'd like to know what people
>>> think about that.
>>>
>>
>> Having the composite implementation type in the core does not
>> preclude that - again, it's just packaging for ease-of-use.
>
> I think it's more significant than packaging. Are you saying that
> we could move the code supporting composites out of core2 without
> breaking the code in core2?
>
Why would we do this? We can already support multiple composite
implementation types - have a look at the Spring extension. That just
sounds like unnecessary complication.
>
>>
>> You seem to have the impression that the core is sealed and that
>> we only support things that are included within it. That is not
>> the case. The only place we need things bundled with the core is
>> in the bootstrap phase - specifically, we need them bundled with
>> the primordial deployer. The actual runtime is created from the
>> SCDL passed to that primordial deployer, can contain any mix of
>> components and need not contain any of the infrastructure used to
>> boot it.
>>
>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>> new interfaces. This is just an initial strawman to trigger a
>>> constructive discussion and ideas on how to best represent the
>>> recursive model. I also need help to define a scenario (not unit
>>> test cases, but an end to end sample application) to help put the
>>> recursive composition model in perspective and make sure we all
>>> understand it the same way.
>>>
>>
>> I am troubled that you have chosen to start on your own codebase
>> at a time when most of us have been trying to have constructive
>> discussion on this list. Based on the approach you proposed in
>> your original email I would have hoped that we could have started
>> with your end-user scenarios and had a chance to explore how they
>> could be supported by M1, the sandbox, or some other code before
>> starting another codebase. I'm disappointed that, having started
>> this very thread nearly a week ago with the premise of community,
>> your first response on it was to commit a large chunk of
>> independent code rather than follow up with any of the other
>> people who have already contributed to the discussion.
>>
>> I think discussion led to compromise and consensus on the scenario-
>> driven approach that you proposed. As shown above and in other
>> recent threads, there's plenty of room for improvements and/or new
>> features in our current code and a willingness to discuss them,
>> albeit in terms of technical merit rather than personal opinion. I
>> hope you can find a way to join in rather than forge your own path.
>>
>> --
>> Jeremy
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: Proposed approach for M2
Posted by Kenneth Tam <ke...@gmail.com>.
On 7/6/06, Jeremy Boynes <jb...@apache.org> wrote:
> On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:
>
> All ideas that Sebastien has proposed are being considered - we had a
> long discussion on these very things on IRC this morning. The main
> questions being asked about his proposal are "what is the benefit of
> starting over?" and "why can we not start with what we already have
> in the sandbox?" One of the problems here is that there are no clear
> answers to them.
>
> ...
>
> We made a start this morning with a fairly long discussion on IRC
> about which code to use. Several people said that they had found the
> sandbox code clearer than M1 and wanted to know from Sebastien why he
> thought we had to start over (I paraphrase). It's a reasonable
> question to ask; it's unreasonable for it to continue to go unanswered.
.. not having been on IRC, you can add me to the list of folks who
found the sandbox code more manageable and easier to get involved
with. I'm not fundamentally opposed to the idea that we might "start
over", but I certainly don't see a documented/well-discussed technical
case justifying that at this point.
k
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:
> Jeremy,
>
> Jeremy Boynes wrote:
>> On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
> <cut/>
>> The point here is not how large someone's code is but whether
>> they are working with others in the community. As you point out,
>> there has been quite a bit of discussion over the last few days
>> on how we should move forward, discussion in which many people
>> have engaged but in which Sebastien has remained silent. Rather
>> than work with others to improve the model we already have, he
>> chose to start over on his own with a completely new architecture
>> titled "m2-design." This isn't asking for constructive
>> discussion, it's throwing gasoline on the fire.
> I don't see Sebastien's actions as implying the motives that you
> suggest.
> Anyone can be offline for a couple of days, especially over a holiday
> time, without this meaning that they are not engaging with the
> community.
Of course. It's not the time factor that's the issue here but the way
in which Sebastien ignored all the discussion that other people had
been doing during that time. We all take time off, although perhaps
going dark just after launching what was bound to be a controversial
thread was not such a good idea. However, if you do take time away,
it is only common courtesy to catch up on discussions that have taken
place before jumping back in.
> And I can see no justification for your statement that putting
> forward a
> new idea in the form of some prototype interface code, with a covering
> note asking for community reaction and feedback, is in any sense
> failing
> to work with the community but an act of throwing gasoline on the
> fire.
That is unfortunate.
> As Jim says, we all need to work together constructively on this.
> I believe this means being open to new ideas, even if they involve
> some
> rework of code that already exists. To simply dismiss such ideas out
> of hand does not move us forward technically and does not help with
> community building either.
What you are not saying here is that both Jim and I posted
constructive, technical comments in our replies to Sebastien's email;
you actually cut mine out of your first response. That omission,
combined with phrases such as "dismiss such ideas out out hand" is
disingenuous, if not downright misleading.
All ideas that Sebastien has proposed are being considered - we had a
long discussion on these very things on IRC this morning. The main
questions being asked about his proposal are "what is the benefit of
starting over?" and "why can we not start with what we already have
in the sandbox?" One of the problems here is that there are no clear
answers to them.
>> In terms of open-mindedness, Jim and I have already engaged on
>> the technical issues Sebastien brought up in his mail, just like
>> we and other community members did on the scenario thread. As
>> these things usually go, on some issues there's agreement, on
>> some there are differences of opinion, and others need more
>> clarification. I look forward to others joining this kind of
>> constructive discussion so that we can come to consensus.
>> However, all the technical issues he raised can be addressed by
>> the incremental improvement approach and none seem to warrant
>> starting over; using something like using a List vs. Map to
>> justify a re-write is simply hyperbole.
> Your statement here that Sebastien is justifying a rewrite based on
> this
> one issue is a hyperbole that does not reflect the post that he sent.
> He listed a number of suggestions of which this was only one. If
> these
> are each taken separately, then each of them can be reduced to
> something
> that could potentially be added incrementally to core2. If they
> are all
> taken together, then it is valid to ask the question (as Sebastien has
> done) whether core2 is the best starting point or whether a different
> approach is preferable.
It is, of course, a valid question to ask. So, looking at the whole
set of questions and the responses so far, let me ask you - in your
technical opinion, is there enough of a problem here to warrant
throwing out what we have and starting over with a new architecture
vs. taking an approach of incremental improvement? Or if we are not
doing it for technical reasons, why are we doing it?
>
>> Far from being negative, I am glad that we finally have these
>> social issues out of smoke-filled rooms and onto the table. This
>> kind of thing is never a pleasant discussion but is one that must
>> be had if we are to function as a community.
> I am fine with technical debate and I think this is very healthy and
> should be happening in the open on this list. However, when people
> express technical opinions or put forward technical proposals, I don't
> think it is appropriate to respond with a personal attack implying
> that
> some anti-community motive lies behind a technical proposal or idea.
It wasn't meant as a personal attack and at no time did I intend to
suggest that there was some anti-community motive. Put it down to
frustration that all the community building effort that I and others
had been putting in seemed to be being ignored.
What I said was "I hope you can find a way to join in rather than
forge your own path." Ant asked me in Dublin what outcome I wanted to
see and I replied then as I reply now: that we can all find a way to
work together on this. Doing so will require compromise.
We made a start in that direction over the weekend with the scenarios
that are so important to Sebastien. Jim created a wiki site and
people have started to add in the scenarios that matter to them; sure
there's not much there yet but as people have loved to point out, it
was a holiday weekend.
We made a start this morning with a fairly long discussion on IRC
about which code to use. Several people said that they had found the
sandbox code clearer than M1 and wanted to know from Sebastien why he
thought we had to start over (I paraphrase). It's a reasonable
question to ask; it's unreasonable for it to continue to go unanswered.
> I hope we can agree to keep these discussions technical from now on.
IMO the biggest challenge facing us right now is figuring out how we
can work together as a community. Until we can do that, the main role
technical issues play is as a catalyst for discussion.
I hope we can get past this and get back to the coding that we all
enjoy.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 6, 2006, at 12:05 PM, Simon Nash wrote:
> Jeremy,
>
> Jeremy Boynes wrote:
>> On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
> <cut/>
>> The point here is not how large someone's code is but whether
>> they are working with others in the community. As you point out,
>> there has been quite a bit of discussion over the last few days
>> on how we should move forward, discussion in which many people
>> have engaged but in which Sebastien has remained silent. Rather
>> than work with others to improve the model we already have, he
>> chose to start over on his own with a completely new architecture
>> titled "m2-design." This isn't asking for constructive
>> discussion, it's throwing gasoline on the fire.
> I don't see Sebastien's actions as implying the motives that you
> suggest.
> Anyone can be offline for a couple of days, especially over a holiday
> time, without this meaning that they are not engaging with the
> community.
> And I can see no justification for your statement that putting
> forward a
> new idea in the form of some prototype interface code, with a covering
> note asking for community reaction and feedback, is in any sense
> failing
> to work with the community but an act of throwing gasoline on the
> fire.
>
> As Jim says, we all need to work together constructively on this.
> I believe this means being open to new ideas, even if they involve
> some
> rework of code that already exists. To simply dismiss such ideas out
> of hand does not move us forward technically and does not help with
> community building either.
Simon, I've have to say I am shocked or maybe just not understanding
what you mean...hopefully it is the latter. When has anyone dismissed
Sebastien's ideas "out of hand"? I'm completely frustrated that not a
single one of my questions have been answered, vacations not
withstanding (no excuse in my book as I'm on vacation too). Moreover,
this is a pattern that has repeated itself time and again. Both
Jeremy and I spent significant time preparing the core2
presentation...some people responded but, perhaps not surprisingly,
none of the vocal proponents of starting afresh. We've asked numerous
times in emails to the list, IRC, at ApacheCon, on the phone, etc.
for those people to offer concrete suggestions for improving core2.
No response. I replied to several emails on the list that spoke of
the "starting over" in very broad terms. No response. I started the
wiki page on scenarios. Again, no response from the proponents of
starting afresh.
What needs to be done to elicit a response? It was even suggested
that Sebastien present his ideas, as Jeremy and I did. I'm willing
to block out however much time it takes, I assume at least four hours
one day, perhaps up to eight. Again, no response. If you'd like to
see a microcosm of this, please read the IRC log for today.
This is hardly the type of positive community building I imagined
when starting this project. To me, it sounds like a group of
individuals talking in generalizations who have no interest in
community building and just want their way without doing any of the
leg work to earn it.
>
>> In terms of open-mindedness, Jim and I have already engaged on
>> the technical issues Sebastien brought up in his mail, just like
>> we and other community members did on the scenario thread. As
>> these things usually go, on some issues there's agreement, on
>> some there are differences of opinion, and others need more
>> clarification. I look forward to others joining this kind of
>> constructive discussion so that we can come to consensus.
>> However, all the technical issues he raised can be addressed by
>> the incremental improvement approach and none seem to warrant
>> starting over; using something like using a List vs. Map to
>> justify a re-write is simply hyperbole.
> Your statement here that Sebastien is justifying a rewrite based on
> this
> one issue is a hyperbole that does not reflect the post that he sent.
> He listed a number of suggestions of which this was only one. If
> these
> are each taken separately, then each of them can be reduced to
> something
> that could potentially be added incrementally to core2. If they
> are all
> taken together, then it is valid to ask the question (as Sebastien has
> done) whether core2 is the best starting point or whether a different
> approach is preferable.
All of them taken as a whole, even assuming they are correct (which I
do not believe they are) would hardly amount to a rewrite. In fact,
none of the criticisms would even affect the core2 runtime as the
model is decoupled from it (one of the things we fixed w.r.t. to M1).
Do you believe otherwise? If so, let's get down and talk specifics,
instead of dancing around this issues.
>
>> Far from being negative, I am glad that we finally have these
>> social issues out of smoke-filled rooms and onto the table. This
>> kind of thing is never a pleasant discussion but is one that must
>> be had if we are to function as a community.
> I am fine with technical debate and I think this is very healthy and
> should be happening in the open on this list. However, when people
> express technical opinions or put forward technical proposals, I don't
> think it is appropriate to respond with a personal attack implying
> that
> some anti-community motive lies behind a technical proposal or idea.
>
> I hope we can agree to keep these discussions technical from now on.
>
I didn't take Jeremy's attack to be personal, but rather a statement
about how something was done. Let's put that aside, though, since I
don't think it is constructive to argue the point. More importantly,
there's been little substantive technical engagement and the S/N
ratio is dreadfully low. What's the problem with talking about
specifics, namely show me why core2 cannot be used as a basis for
moving forward? Otherwise, let's get on with the work we have ahead
of us and put the incessant bickering aside.
Jim
> Simon
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> 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
Re: Proposed approach for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy,
Jeremy Boynes wrote:
> On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
>
<cut/>
> The point here is not how large someone's code is but whether they are
> working with others in the community. As you point out, there has been
> quite a bit of discussion over the last few days on how we should move
> forward, discussion in which many people have engaged but in which
> Sebastien has remained silent. Rather than work with others to improve
> the model we already have, he chose to start over on his own with a
> completely new architecture titled "m2-design." This isn't asking for
> constructive discussion, it's throwing gasoline on the fire.
>
I don't see Sebastien's actions as implying the motives that you suggest.
Anyone can be offline for a couple of days, especially over a holiday
time, without this meaning that they are not engaging with the community.
And I can see no justification for your statement that putting forward a
new idea in the form of some prototype interface code, with a covering
note asking for community reaction and feedback, is in any sense failing
to work with the community but an act of throwing gasoline on the fire.
As Jim says, we all need to work together constructively on this.
I believe this means being open to new ideas, even if they involve some
rework of code that already exists. To simply dismiss such ideas out
of hand does not move us forward technically and does not help with
community building either.
> In terms of open-mindedness, Jim and I have already engaged on the
> technical issues Sebastien brought up in his mail, just like we and
> other community members did on the scenario thread. As these things
> usually go, on some issues there's agreement, on some there are
> differences of opinion, and others need more clarification. I look
> forward to others joining this kind of constructive discussion so that
> we can come to consensus. However, all the technical issues he raised
> can be addressed by the incremental improvement approach and none seem
> to warrant starting over; using something like using a List vs. Map to
> justify a re-write is simply hyperbole.
>
Your statement here that Sebastien is justifying a rewrite based on this
one issue is a hyperbole that does not reflect the post that he sent.
He listed a number of suggestions of which this was only one. If these
are each taken separately, then each of them can be reduced to something
that could potentially be added incrementally to core2. If they are all
taken together, then it is valid to ask the question (as Sebastien has
done) whether core2 is the best starting point or whether a different
approach is preferable.
> Far from being negative, I am glad that we finally have these social
> issues out of smoke-filled rooms and onto the table. This kind of thing
> is never a pleasant discussion but is one that must be had if we are to
> function as a community.
>
I am fine with technical debate and I think this is very healthy and
should be happening in the open on this list. However, when people
express technical opinions or put forward technical proposals, I don't
think it is appropriate to respond with a personal attack implying that
some anti-community motive lies behind a technical proposal or idea.
I hope we can agree to keep these discussions technical from now on.
Simon
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by ant elder <an...@gmail.com>.
Jeremy, as you know, its been holidays in the US this week and that will be
why Sebastien was quiet over the weekend and Monday and Tuesday. I've found
all his past posts on this sandbox topic most constructive and helpful.
...ant
On 7/6/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
>
> > Jeremy,
> >
> > Jeremy Boynes wrote:
> >
> >> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> > <cut/>
> >>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
> >>> new interfaces. This is just an initial strawman to trigger a
> >>> constructive discussion and ideas on how to best represent the
> >>> recursive model. I also need help to define a scenario (not unit
> >>> test cases, but an end to end sample application) to help put
> >>> the recursive composition model in perspective and make sure we
> >>> all understand it the same way.
> >>>
> >> I am troubled that you have chosen to start on your own codebase
> >> at a time when most of us have been trying to have constructive
> >> discussion on this list. Based on the approach you proposed in
> >> your original email I would have hoped that we could have started
> >> with your end- user scenarios and had a chance to explore how they
> >> could be supported by M1, the sandbox, or some other code before
> >> starting another codebase. I'm disappointed that, having started
> >> this very thread nearly a week ago with the premise of community,
> >> your first response on it was to commit a large chunk of
> >> independent code rather than follow up with any of the other
> >> people who have already contributed to the discussion.
> >> I think discussion led to compromise and consensus on the
> >> scenario- driven approach that you proposed. As shown above and in
> >> other recent threads, there's plenty of room for improvements and/
> >> or new features in our current code and a willingness to discuss
> >> them, albeit in terms of technical merit rather than personal
> >> opinion. I hope you can find a way to join in rather than forge
> >> your own path.
> > This can by no stretch of the imagination be described as a "large
> > chunk
> > of independent code". It consists of around 20 interfaces with no
> > implementation. Quite a bit of the discussion on this topic over the
> > last few days has focused on what could be the advantages of starting
> > a new code stream rather than continuing with either M1 or core2. As
> > Sebastien said in his post, the purpose of this code (as well as other
> > suggestions he made in his latest post) is to trigger contructive
> > discussion on new ideas that are not incrementally derived from either
> > of the existing codebases. When presenting such ideas, it is often
> > helpful to see sample code rather that just a textual description.
> >
> > I am very disppointed at your negative reaction to this, which is
> > about
> > as far away as I can imagine from the constructive technical
> > discussion
> > that Sebastien asked for. We will only reach the right conclusion on
> > this important debate if we all engage constructively at a technical
> > level and evaluate new contributions and ideas in an open-minded way.
> > Your apparent characterization of Sebastien's constructive engagement
> > in this discussion as an attempt to "forge his own path" is unfair and
> > offensive, and not at all how I interpret Sebastien's recent posts.
> >
> > Simon
> >
> > --
> > Simon C Nash IBM Distinguished Engineer
> > Hursley Park, Winchester, UK nash@hursley.ibm.com
> > Tel. +44-1962-815156 Fax +44-1962-818999
>
> Simon,
>
> The point here is not how large someone's code is but whether they
> are working with others in the community. As you point out, there has
> been quite a bit of discussion over the last few days on how we
> should move forward, discussion in which many people have engaged but
> in which Sebastien has remained silent. Rather than work with others
> to improve the model we already have, he chose to start over on his
> own with a completely new architecture titled "m2-design." This isn't
> asking for constructive discussion, it's throwing gasoline on the fire.
>
> In terms of open-mindedness, Jim and I have already engaged on the
> technical issues Sebastien brought up in his mail, just like we and
> other community members did on the scenario thread. As these things
> usually go, on some issues there's agreement, on some there are
> differences of opinion, and others need more clarification. I look
> forward to others joining this kind of constructive discussion so
> that we can come to consensus. However, all the technical issues he
> raised can be addressed by the incremental improvement approach and
> none seem to warrant starting over; using something like using a List
> vs. Map to justify a re-write is simply hyperbole.
>
> Far from being negative, I am glad that we finally have these social
> issues out of smoke-filled rooms and onto the table. This kind of
> thing is never a pleasant discussion but is one that must be had if
> we are to function as a community.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proposed approach for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
> Jeremy,
>
> Jeremy Boynes wrote:
>
>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> <cut/>
>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>> new interfaces. This is just an initial strawman to trigger a
>>> constructive discussion and ideas on how to best represent the
>>> recursive model. I also need help to define a scenario (not unit
>>> test cases, but an end to end sample application) to help put
>>> the recursive composition model in perspective and make sure we
>>> all understand it the same way.
>>>
>> I am troubled that you have chosen to start on your own codebase
>> at a time when most of us have been trying to have constructive
>> discussion on this list. Based on the approach you proposed in
>> your original email I would have hoped that we could have started
>> with your end- user scenarios and had a chance to explore how they
>> could be supported by M1, the sandbox, or some other code before
>> starting another codebase. I'm disappointed that, having started
>> this very thread nearly a week ago with the premise of community,
>> your first response on it was to commit a large chunk of
>> independent code rather than follow up with any of the other
>> people who have already contributed to the discussion.
>> I think discussion led to compromise and consensus on the
>> scenario- driven approach that you proposed. As shown above and in
>> other recent threads, there's plenty of room for improvements and/
>> or new features in our current code and a willingness to discuss
>> them, albeit in terms of technical merit rather than personal
>> opinion. I hope you can find a way to join in rather than forge
>> your own path.
> This can by no stretch of the imagination be described as a "large
> chunk
> of independent code". It consists of around 20 interfaces with no
> implementation. Quite a bit of the discussion on this topic over the
> last few days has focused on what could be the advantages of starting
> a new code stream rather than continuing with either M1 or core2. As
> Sebastien said in his post, the purpose of this code (as well as other
> suggestions he made in his latest post) is to trigger contructive
> discussion on new ideas that are not incrementally derived from either
> of the existing codebases. When presenting such ideas, it is often
> helpful to see sample code rather that just a textual description.
>
> I am very disppointed at your negative reaction to this, which is
> about
> as far away as I can imagine from the constructive technical
> discussion
> that Sebastien asked for. We will only reach the right conclusion on
> this important debate if we all engage constructively at a technical
> level and evaluate new contributions and ideas in an open-minded way.
> Your apparent characterization of Sebastien's constructive engagement
> in this discussion as an attempt to "forge his own path" is unfair and
> offensive, and not at all how I interpret Sebastien's recent posts.
>
> Simon
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
Simon,
The point here is not how large someone's code is but whether they
are working with others in the community. As you point out, there has
been quite a bit of discussion over the last few days on how we
should move forward, discussion in which many people have engaged but
in which Sebastien has remained silent. Rather than work with others
to improve the model we already have, he chose to start over on his
own with a completely new architecture titled "m2-design." This isn't
asking for constructive discussion, it's throwing gasoline on the fire.
In terms of open-mindedness, Jim and I have already engaged on the
technical issues Sebastien brought up in his mail, just like we and
other community members did on the scenario thread. As these things
usually go, on some issues there's agreement, on some there are
differences of opinion, and others need more clarification. I look
forward to others joining this kind of constructive discussion so
that we can come to consensus. However, all the technical issues he
raised can be addressed by the incremental improvement approach and
none seem to warrant starting over; using something like using a List
vs. Map to justify a re-write is simply hyperbole.
Far from being negative, I am glad that we finally have these social
issues out of smoke-filled rooms and onto the table. This kind of
thing is never a pleasant discussion but is one that must be had if
we are to function as a community.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Jim Marino wrote:
>
<cut/>
>> We will only reach the right conclusion on
>> this important debate if we all engage constructively at a technical
>> level and evaluate new contributions and ideas in an open-minded way.
>> Your apparent characterization of Sebastien's constructive engagement
>> in this discussion as an attempt to "forge his own path" is unfair and
>> offensive, and not at all how I interpret Sebastien's recent posts.
>>
> Simon, I don't think that is fair and labeling it as offensive is
> unnecessarily caustic. Perhaps Jeremy could have worded some of his
> response better but I think *everyone* has been guilty of this over the
> past several weeks so I'd prefer to make a general statement that we
> all remain constructive since we are not doing a very good job of
> community building.
>
I have responded to Jeremy directly (on the list) so I won't repeat
my comments here. I certainly agree that we all need to remain
constructive and I believe the best way to do this is to focus on
technical matters and give all ideas, suggestions, and proposals
a fair hearing.
> My second point is that the desire for constructive discussion comes
> from *all* of us, not just Sebastien. For example, Jeremy spent a
> significant amount of time on the core2 architecture presentation a
> month back, numerous posts to the list, proposals (e.g. constructor
> injection), and scenarios, etc. - all of which were attempts to
> constructively engage the community.
>
Yes, I agree. I was reacting to this particular post, and I was
not intending to imply that Jeremy's overall contribution to Tuscany
has been anything other than constructive. I think it is a good
principle to assume that everyone's desire is to participate
constructively and to regard all technical proposals and contributions
as attempts to be constructive.
> As I mentioned in a previous post, moving the community forward starts
> with positive individual acts. Perhaps you could engage by positing
> scenarios to the wiki you are interested in, or respond to my response
> to Sebastien asking why any of the changes he mentioned could not be
> incrementally accommodated by core2? This approach sounds to me like a
> nice way to accommodate the interests of many and move things forward.
>
I'm on vacation this week and I have very limited time available for
work-related activity. I should be able to get more involved in the
constructive ways that you suggest when I return to work next week.
Simon
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
> Jeremy,
>
> Jeremy Boynes wrote:
>
>> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> <cut/>
>>> I just checked in sandbox/sebastien/m2-design/model.spi a set of
>>> new interfaces. This is just an initial strawman to trigger a
>>> constructive discussion and ideas on how to best represent the
>>> recursive model. I also need help to define a scenario (not unit
>>> test cases, but an end to end sample application) to help put
>>> the recursive composition model in perspective and make sure we
>>> all understand it the same way.
>>>
>> I am troubled that you have chosen to start on your own codebase
>> at a time when most of us have been trying to have constructive
>> discussion on this list. Based on the approach you proposed in
>> your original email I would have hoped that we could have started
>> with your end- user scenarios and had a chance to explore how they
>> could be supported by M1, the sandbox, or some other code before
>> starting another codebase. I'm disappointed that, having started
>> this very thread nearly a week ago with the premise of community,
>> your first response on it was to commit a large chunk of
>> independent code rather than follow up with any of the other
>> people who have already contributed to the discussion.
>> I think discussion led to compromise and consensus on the
>> scenario- driven approach that you proposed. As shown above and in
>> other recent threads, there's plenty of room for improvements and/
>> or new features in our current code and a willingness to discuss
>> them, albeit in terms of technical merit rather than personal
>> opinion. I hope you can find a way to join in rather than forge
>> your own path.
> This can by no stretch of the imagination be described as a "large
> chunk
> of independent code". It consists of around 20 interfaces with no
> implementation. Quite a bit of the discussion on this topic over the
> last few days has focused on what could be the advantages of starting
> a new code stream rather than continuing with either M1 or core2. As
> Sebastien said in his post, the purpose of this code (as well as other
> suggestions he made in his latest post) is to trigger contructive
> discussion on new ideas that are not incrementally derived from either
> of the existing codebases. When presenting such ideas, it is often
> helpful to see sample code rather that just a textual description.
>
> I am very disppointed at your negative reaction to this, which is
> about
> as far away as I can imagine from the constructive technical
> discussion
> that Sebastien asked for.
> We will only reach the right conclusion on
> this important debate if we all engage constructively at a technical
> level and evaluate new contributions and ideas in an open-minded way.
> Your apparent characterization of Sebastien's constructive engagement
> in this discussion as an attempt to "forge his own path" is unfair and
> offensive, and not at all how I interpret Sebastien's recent posts.
>
Simon, I don't think that is fair and labeling it as offensive is
unnecessarily caustic. Perhaps Jeremy could have worded some of his
response better but I think *everyone* has been guilty of this over
the past several weeks so I'd prefer to make a general statement that
we all remain constructive since we are not doing a very good job of
community building.
My second point is that the desire for constructive discussion comes
from *all* of us, not just Sebastien. For example, Jeremy spent a
significant amount of time on the core2 architecture presentation a
month back, numerous posts to the list, proposals (e.g. constructor
injection), and scenarios, etc. - all of which were attempts to
constructively engage the community.
As I mentioned in a previous post, moving the community forward
starts with positive individual acts. Perhaps you could engage by
positing scenarios to the wiki you are interested in, or respond to
my response to Sebastien asking why any of the changes he mentioned
could not be incrementally accommodated by core2? This approach
sounds to me like a nice way to accommodate the interests of many and
move things forward.
Jim
> Simon
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> 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
Re: Proposed approach for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy,
Jeremy Boynes wrote:
> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>
<cut/>
>> I just checked in sandbox/sebastien/m2-design/model.spi a set of new
>> interfaces. This is just an initial strawman to trigger a
>> constructive discussion and ideas on how to best represent the
>> recursive model. I also need help to define a scenario (not unit test
>> cases, but an end to end sample application) to help put the
>> recursive composition model in perspective and make sure we all
>> understand it the same way.
>>
>
> I am troubled that you have chosen to start on your own codebase at a
> time when most of us have been trying to have constructive discussion
> on this list. Based on the approach you proposed in your original email
> I would have hoped that we could have started with your end- user
> scenarios and had a chance to explore how they could be supported by
> M1, the sandbox, or some other code before starting another codebase.
> I'm disappointed that, having started this very thread nearly a week
> ago with the premise of community, your first response on it was to
> commit a large chunk of independent code rather than follow up with any
> of the other people who have already contributed to the discussion.
>
> I think discussion led to compromise and consensus on the scenario-
> driven approach that you proposed. As shown above and in other recent
> threads, there's plenty of room for improvements and/or new features in
> our current code and a willingness to discuss them, albeit in terms of
> technical merit rather than personal opinion. I hope you can find a way
> to join in rather than forge your own path.
>
This can by no stretch of the imagination be described as a "large chunk
of independent code". It consists of around 20 interfaces with no
implementation. Quite a bit of the discussion on this topic over the
last few days has focused on what could be the advantages of starting
a new code stream rather than continuing with either M1 or core2. As
Sebastien said in his post, the purpose of this code (as well as other
suggestions he made in his latest post) is to trigger contructive
discussion on new ideas that are not incrementally derived from either
of the existing codebases. When presenting such ideas, it is often
helpful to see sample code rather that just a textual description.
I am very disppointed at your negative reaction to this, which is about
as far away as I can imagine from the constructive technical discussion
that Sebastien asked for. We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this discussion as an attempt to "forge his own path" is unfair and
offensive, and not at all how I interpret Sebastien's recent posts.
Simon
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Kenneth Tam <ke...@gmail.com>.
On 7/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
> >
> > My proposal is not to merge M1 and the core2 sandbox. I am
> > proposing to start a new fresh code stream and build the runtime
> > through baby steps. We may be able to reuse some pieces of existing
> > code, but more important is to engage our community in this
> > exercise and integrate the new ideas that will emerge from this.
> >
>
> I don't believe the two issues are necessarily coupled. Quite a few
> members of the community are engaged on the sandbox code already and
> we could work with you to improve that rather having to throw
> everything out and start over with all new ideas.
+1 on improving the sandbox code -- it seems to me that there's a
certain mininum amount of code that needs to exist to really kickstart
a community-based solution to a problem of this scope, and I have a
hard time envisioning how starting a fresh code stream at this point
would result in anything noticeably smaller/simpler/more
comprehensible than what's already there in Core2.
> > Here's an example where I'm struggling with both M1 and the core2
> > sandbox and thinking that we can do better if we start with a new
> > fresh stream.
I don't know the Core2 code well enough to mount a cogent technical
reply to these concerns off the top of my head -- my perspective is
simply that the best way to address such issues is to raise them here
in the community and discuss/prototype possible approaches in the
context of the existing code streams.
My experience has been that such discussions work much better in the
context of something functioning -- so before deciding to start (yet)
again, I'm hoping we can work to evolve what's already in svn. I'm
able to regularly spend time on this project, but not near the
full-time level of some folks here. For me, the Core2 code base has
been much more accessible and maps more naturally to my understanding
of the spec so far.. on that basis, if there's a desire to do
something differently, I'd very much like to see it made obvious how
that couldn't be accomodated in the context of Core2 before we hit the
reset button.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy,
I won't comment on your attacks at the bottom of this email. I was
hoping for a more constructive technical discussion. I added my answers
and comments on the specific technical issues inline.
Jeremy Boynes wrote:
> On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>>
>> My proposal is not to merge M1 and the core2 sandbox. I am proposing
>> to start a new fresh code stream and build the runtime through baby
>> steps. We may be able to reuse some pieces of existing code, but more
>> important is to engage our community in this exercise and integrate
>> the new ideas that will emerge from this.
>>
>
> I don't believe the two issues are necessarily coupled. Quite a few
> members of the community are engaged on the sandbox code already and
> we could work with you to improve that rather having to throw
> everything out and start over with all new ideas.
>
>>
>> Here's an example where I'm struggling with both M1 and the core2
>> sandbox and thinking that we can do better if we start with a new
>> fresh stream: our (recursive) assembly metadata model.
>>
>> - M1 does not implement the recursive composition model and would
>> require significant changes to support it. Core2 is an attempt to
>> implement it but I'm not sure it's quite right, and also think that
>> it can be simplified.
>
> It would really help if you could come up with concrete areas where it
> is not right or where it could be simplified - for example, end user
> scenarios that are not supported.
>
>>
>> - M1 used Lists to represent relationships, Core2 uses Maps, I think
>> M1 was better since it allowed to keep the order in the relationships.
>
> There's nothing I remember in the assembly spec where order matters.
> On the other hand there are many areas where things are keyed by a
> name which has to be unique. This seems like a natural mapping (sorry)
> to a Map. In M1 I started to move toward simple map structures but you
> replaced it with what seemed like a fairly complicated specialized
> List implementation that sent notifications that updated a Map anyway.
> Given the desire for simplification, are there any end-user scenarios
> that require ordering to be preserved and that can't be supported with
> a basic HashMap or LinkedHashMap?
>
As an administrator I'll want my administration tool to display
components displayed in the order I declared them in SCDL. I'll also
want a configuration or admin tool loading/saving modified SCDL to write
things in the order that they were initially, not in a random order. As
an application developer I'd like to have an SCA debugging tool showing
me my components in a list in the right order as well. Also if I want to
implement the model defined by the XML schemas in the spec using any of
the DataBinding technologies out there, I'll end up with Lists, not Maps.
Finally even if we decided to use Maps in some cases to provide keyed
access to some elements of the model, we'd have to do it differently.
For example a single Map containing all components, references and
services in a composite (according to the spec they cannot have the same
names) instead of three Maps like you have in Core2.
>>
>> - Core2 only defines implementation classes for the model, I think we
>> should have interfaces + default implementation classes instead, like
>> we had in M1, to allow for alternate implementations of the model.
>
> One of the most complex things with the M1 model was all the
> interfaces involved, the need to pass factory implementations around,
> the number of different factories involved (one per extension
> implementation) and the potential issues with code assuming its
> implementation of the factory was the one used.
>
> The core2 model uses concrete classes which are really just data
> holders - there's no behaviour in them to be abstracted through the
> interface. This gives a much simpler programming model for extensions
> using the model.
>
> Do you have any scenarios that would require different implementations
> of the model? Are they so different that they might as well just use
> different classes?
>
I don't think that having just implementation classes is much simpler.
If you interact with the model SPI, reading interfaces is simpler IMO
and more suitable for inclusion in a specification document... allowing
multiple implementations of these interfaces. Also we have to support
the whole lifecycle of an SCA application (development, deploy/install,
runtime, admin etc.) and I'd like to allow some flexibility for
different tools, running at different times to use different
implementations of the assembly model interfaces.
>>
>> - Over usage of Java Generics breaks flexibility in some cases, for
>> example Component<I extends Implementation> will force you to
>> recreate an instance of Component to swap its implementation with an
>> implementation of a different type (and lose all the wires going
>> in/out of the component).
>
> There may be cases where generics may be overkill but I don't think
> that really requires us to throw out the model. There are other cases
> where the use of wildcards would be appropriate; for example, in the
> scenario you give here you could just create a
> Component<Implementation> to allow different types of implementation
> to be used.
>
Then instead of
Component<Implementation> {
Implementation getImplementation();
}
I think we can just do
Component {
Implementation getImplementation();
}
What we have now in core2 is overkill IMO.
>>
>> - Core2 defines ReferenceDefinitions (without bindings) and
>> BoundReferenceDefinitions (with bindings). IMO there are Reference
>> types and Reference instances and both can have bindings.
>> or Reference.
>
> I'm with you here - we need to refactor the way bindings are handled
> for both Service and Reference. One thing the sandbox model is missing
> is the ability to associate multiple bindings with a single
> Service/Reference.
My main point is not about supporting multiple bindings on a Service or
Reference. I think this is secondary and the interfaces I put in my
sandbox to support a design discussion don't even have that either. My
point is that Services, References, and their instantiation by
Components are at the foundation of the SCA assembly model... and
therefore need to be modeled correctly. I'm proposing a different
design, illustrated by the interfaces I checked in.
>
>>
>> - I think that Remotable should be on Interface and not Service.
>
> I agree Service is wrong and that it should be on ServiceContract.
> Thanks for catching it.
>
>>
>> - Scope should be defined in the Java component implementation,
>> separate from the core model.
>
> Scope is not a Java specific concept.
> Interaction scope (stateless vs. stateful) can apply to any
> ServiceContract.
> Container scope is the contract between an implementation and a
> ScopeContainer and applies to any implementation type that can support
> stateful interactions. This would include JavaScript, Groovy, C++, ...
> I think that means that support for state management (which is what
> scope is configuring) belongs in the core with the configuration
> metadata supplied by the implementation type.
>
I don't think it's quite right. First interaction scopes are defined on
interfaces and not service contracts. Also they control whether an
interface is conversational or not, independent from any state management.
Anyway I was talking about a different scope, the implementation scope
defined in the Java C&I spec, which governs the lifecycle of Java
component implementation instances. I think the definition and
implementation of lifecycle management will vary greatly depending on
the component implementation type, for example Java component
implementations and BPEL component implementations typically deal with
this in a very different way. Therefore, in my view state/lifecycle
management should be left to the component implementation contributions
and not belong to core.
>>
>> - Java and WSDL interfaces should be defined separate from the core
>> model, we need to support multiple interface definition languages
>> supported by plugins, not in the core.
>
> The model supports generic IDL through the use of ServiceContract.
> Java and WSDL are two forms of IDL that are mandated by the
> specification. This is really just a question of where those
> implementations are packaged and again I don't think this warrants a
> rewrite.
>
Packaging issues are important and often hide bigger dependency/coupling
problems. I think we should package the support for Java and WSDL
interfaces separate from the core to prevent any coupling between the
two, and also give people who will have to support new interface
definition languages a better template to follow.
Individual issues do not warrant a rewrite. What about the sum of many
issues?
>>
>> - Implementation should extend ComponentType IMO instead of pointing
>> to it, and we may even be able to simplify and just remove
>> Implementation. Also I am not sure why we need to distinguish between
>> AtomicImplementation and CompositeImplementation.
>
> One of the problems the assembly spec has is that it is difficult to
> do top-down design because you cannot link a component to a
> componentType without having an implementation. I agree this is an
> area that we (and the spec) need to sort out.
>
> IMO a component is associated with one componentType but may have
> multiple implementations so I don't think they are quite the same
> thing or that either can be removed.
>
> AtomicImplementation is a marker for implementations that cannot have
> children.
In my view a component has a type. The ComponentType is either abstract
(just defining the types of services offered, references used, and
properties that can be configured), or concrete. A POJO component
implementation is a concrete ComponentType.
>
>
>>
>> - Support for Composite Includes is missing, this is a significant
>> part of the recursive composition model (half of it, one of the two
>> ways to nest composites).
>
> It's not really half - it's really just a very small part of the
> model, comparable to the <import> element we used to support in M1.
> Again, I don't see why we need to rewrite the model to add this in.
> Quite the opposite: you've said you've been looking for way to engage
> and this could be it.
I disagree. Includes are a very significant part of the assembly model
(the other part is the ability to use a composite as a component
implementation). Two examples:
- An included composite is the equivalent of a module fragment in the
0.9 spec. This concept is key to allowing a team to work on various
pieces of an application, split in multiple composites, included in a
composite representing the application.
- When (formerly subsystems) composites get deployed to an SCA system,
they are actually included in that system, rather than being used as
component implementations.
>
>>
>> This list is not exhaustive... Another idea would be to externalize
>> support for Composites in a separate plugin not part of the core
>> service model (since there may be other ways to compose services in
>> addition to an SCA composite, with Spring or other similar
>> programming models), I'd like to know what people think about that.
>>
>
> Having the composite implementation type in the core does not preclude
> that - again, it's just packaging for ease-of-use.
I think it's more significant than packaging. Are you saying that we
could move the code supporting composites out of core2 without breaking
the code in core2?
>
> You seem to have the impression that the core is sealed and that we
> only support things that are included within it. That is not the case.
> The only place we need things bundled with the core is in the
> bootstrap phase - specifically, we need them bundled with the
> primordial deployer. The actual runtime is created from the SCDL
> passed to that primordial deployer, can contain any mix of components
> and need not contain any of the infrastructure used to boot it.
>
>> I just checked in sandbox/sebastien/m2-design/model.spi a set of new
>> interfaces. This is just an initial strawman to trigger a
>> constructive discussion and ideas on how to best represent the
>> recursive model. I also need help to define a scenario (not unit test
>> cases, but an end to end sample application) to help put the
>> recursive composition model in perspective and make sure we all
>> understand it the same way.
>>
>
> I am troubled that you have chosen to start on your own codebase at a
> time when most of us have been trying to have constructive discussion
> on this list. Based on the approach you proposed in your original
> email I would have hoped that we could have started with your end-user
> scenarios and had a chance to explore how they could be supported by
> M1, the sandbox, or some other code before starting another codebase.
> I'm disappointed that, having started this very thread nearly a week
> ago with the premise of community, your first response on it was to
> commit a large chunk of independent code rather than follow up with
> any of the other people who have already contributed to the discussion.
>
> I think discussion led to compromise and consensus on the
> scenario-driven approach that you proposed. As shown above and in
> other recent threads, there's plenty of room for improvements and/or
> new features in our current code and a willingness to discuss them,
> albeit in terms of technical merit rather than personal opinion. I
> hope you can find a way to join in rather than forge your own path.
>
> --
> Jeremy
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
>
> My proposal is not to merge M1 and the core2 sandbox. I am
> proposing to start a new fresh code stream and build the runtime
> through baby steps. We may be able to reuse some pieces of existing
> code, but more important is to engage our community in this
> exercise and integrate the new ideas that will emerge from this.
>
I don't believe the two issues are necessarily coupled. Quite a few
members of the community are engaged on the sandbox code already and
we could work with you to improve that rather having to throw
everything out and start over with all new ideas.
>
> Here's an example where I'm struggling with both M1 and the core2
> sandbox and thinking that we can do better if we start with a new
> fresh stream: our (recursive) assembly metadata model.
>
> - M1 does not implement the recursive composition model and would
> require significant changes to support it. Core2 is an attempt to
> implement it but I'm not sure it's quite right, and also think that
> it can be simplified.
It would really help if you could come up with concrete areas where
it is not right or where it could be simplified - for example, end
user scenarios that are not supported.
>
> - M1 used Lists to represent relationships, Core2 uses Maps, I
> think M1 was better since it allowed to keep the order in the
> relationships.
There's nothing I remember in the assembly spec where order matters.
On the other hand there are many areas where things are keyed by a
name which has to be unique. This seems like a natural mapping
(sorry) to a Map. In M1 I started to move toward simple map
structures but you replaced it with what seemed like a fairly
complicated specialized List implementation that sent notifications
that updated a Map anyway. Given the desire for simplification, are
there any end-user scenarios that require ordering to be preserved
and that can't be supported with a basic HashMap or LinkedHashMap?
>
> - Core2 only defines implementation classes for the model, I think
> we should have interfaces + default implementation classes instead,
> like we had in M1, to allow for alternate implementations of the
> model.
One of the most complex things with the M1 model was all the
interfaces involved, the need to pass factory implementations around,
the number of different factories involved (one per extension
implementation) and the potential issues with code assuming its
implementation of the factory was the one used.
The core2 model uses concrete classes which are really just data
holders - there's no behaviour in them to be abstracted through the
interface. This gives a much simpler programming model for extensions
using the model.
Do you have any scenarios that would require different
implementations of the model? Are they so different that they might
as well just use different classes?
>
> - Over usage of Java Generics breaks flexibility in some cases, for
> example Component<I extends Implementation> will force you to
> recreate an instance of Component to swap its implementation with
> an implementation of a different type (and lose all the wires going
> in/out of the component).
There may be cases where generics may be overkill but I don't think
that really requires us to throw out the model. There are other cases
where the use of wildcards would be appropriate; for example, in the
scenario you give here you could just create a
Component<Implementation> to allow different types of implementation
to be used.
>
> - Core2 defines ReferenceDefinitions (without bindings) and
> BoundReferenceDefinitions (with bindings). IMO there are Reference
> types and Reference instances and both can have bindings.
> or Reference.
I'm with you here - we need to refactor the way bindings are handled
for both Service and Reference. One thing the sandbox model is
missing is the ability to associate multiple bindings with a single
Service/Reference.
>
> - I think that Remotable should be on Interface and not Service.
I agree Service is wrong and that it should be on ServiceContract.
Thanks for catching it.
>
> - Scope should be defined in the Java component implementation,
> separate from the core model.
Scope is not a Java specific concept.
Interaction scope (stateless vs. stateful) can apply to any
ServiceContract.
Container scope is the contract between an implementation and a
ScopeContainer and applies to any implementation type that can
support stateful interactions. This would include JavaScript, Groovy,
C++, ... I think that means that support for state management (which
is what scope is configuring) belongs in the core with the
configuration metadata supplied by the implementation type.
>
> - Java and WSDL interfaces should be defined separate from the core
> model, we need to support multiple interface definition languages
> supported by plugins, not in the core.
The model supports generic IDL through the use of ServiceContract.
Java and WSDL are two forms of IDL that are mandated by the
specification. This is really just a question of where those
implementations are packaged and again I don't think this warrants a
rewrite.
>
> - Implementation should extend ComponentType IMO instead of
> pointing to it, and we may even be able to simplify and just remove
> Implementation. Also I am not sure why we need to distinguish
> between AtomicImplementation and CompositeImplementation.
One of the problems the assembly spec has is that it is difficult to
do top-down design because you cannot link a component to a
componentType without having an implementation. I agree this is an
area that we (and the spec) need to sort out.
IMO a component is associated with one componentType but may have
multiple implementations so I don't think they are quite the same
thing or that either can be removed.
AtomicImplementation is a marker for implementations that cannot have
children.
>
> - Support for Composite Includes is missing, this is a significant
> part of the recursive composition model (half of it, one of the two
> ways to nest composites).
It's not really half - it's really just a very small part of the
model, comparable to the <import> element we used to support in M1.
Again, I don't see why we need to rewrite the model to add this in.
Quite the opposite: you've said you've been looking for way to engage
and this could be it.
>
> This list is not exhaustive... Another idea would be to externalize
> support for Composites in a separate plugin not part of the core
> service model (since there may be other ways to compose services in
> addition to an SCA composite, with Spring or other similar
> programming models), I'd like to know what people think about that.
>
Having the composite implementation type in the core does not
preclude that - again, it's just packaging for ease-of-use.
You seem to have the impression that the core is sealed and that we
only support things that are included within it. That is not the
case. The only place we need things bundled with the core is in the
bootstrap phase - specifically, we need them bundled with the
primordial deployer. The actual runtime is created from the SCDL
passed to that primordial deployer, can contain any mix of components
and need not contain any of the infrastructure used to boot it.
> I just checked in sandbox/sebastien/m2-design/model.spi a set of
> new interfaces. This is just an initial strawman to trigger a
> constructive discussion and ideas on how to best represent the
> recursive model. I also need help to define a scenario (not unit
> test cases, but an end to end sample application) to help put the
> recursive composition model in perspective and make sure we all
> understand it the same way.
>
I am troubled that you have chosen to start on your own codebase at a
time when most of us have been trying to have constructive discussion
on this list. Based on the approach you proposed in your original
email I would have hoped that we could have started with your end-
user scenarios and had a chance to explore how they could be
supported by M1, the sandbox, or some other code before starting
another codebase. I'm disappointed that, having started this very
thread nearly a week ago with the premise of community, your first
response on it was to commit a large chunk of independent code rather
than follow up with any of the other people who have already
contributed to the discussion.
I think discussion led to compromise and consensus on the scenario-
driven approach that you proposed. As shown above and in other recent
threads, there's plenty of room for improvements and/or new features
in our current code and a willingness to discuss them, albeit in
terms of technical merit rather than personal opinion. I hope you can
find a way to join in rather than forge your own path.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>
> On Jul 3, 2006, at 5:34 AM, ant elder wrote:
>
>> One of the big reasons for me is summed up well in Sebastien's proposal:
>>
>> "This will get our community members involved in building the runtime
>> together and will lead to a wider knowledge base that makes it
>> possible to
>> quickly implement new functionality in the future. It will also build a
>> community knowledge base that is ready to help new community members
>> come on
>> board quickly."
>>
>> I struggle with understanding the what and why of parts of the
>> sandbox code
>> and hope bringing small bits over one step at a time will help with
>> this.
>>
> Could you outline specifically what you don't understand. Perhaps we
> could do another code walkthrough like we did about a month ago?
>
>> Why don't you like this approach? Sure it may take a bit more time
>> but if in
>> the long run we end up with more people understanding the runtime
>> that seems
>> like time well spent even if we end up with most of the trunk being just
>> whats in the sandbox today.
>>
> The key point is I like Jeremy's approach better. The thought of
> merging M1 with the sandbox code (Sebastien's proposal) doesn't seem
> to fit based on my technical knowledge of both code bases. More
> importantly, Jeremy's approach strike me as better. Since I have
> outlined my reasoning in previous posts (not just technical) why I
> think it is better,I won't repeat them here, as it will just confuse
> the ongoing threads.
>
My proposal is not to merge M1 and the core2 sandbox. I am proposing to
start a new fresh code stream and build the runtime through baby steps.
We may be able to reuse some pieces of existing code, but more important
is to engage our community in this exercise and integrate the new ideas
that will emerge from this.
Here's an example where I'm struggling with both M1 and the core2
sandbox and thinking that we can do better if we start with a new fresh
stream: our (recursive) assembly metadata model.
- M1 does not implement the recursive composition model and would
require significant changes to support it. Core2 is an attempt to
implement it but I'm not sure it's quite right, and also think that it
can be simplified.
- M1 used Lists to represent relationships, Core2 uses Maps, I think M1
was better since it allowed to keep the order in the relationships.
- Core2 only defines implementation classes for the model, I think we
should have interfaces + default implementation classes instead, like we
had in M1, to allow for alternate implementations of the model.
- Over usage of Java Generics breaks flexibility in some cases, for
example Component<I extends Implementation> will force you to recreate
an instance of Component to swap its implementation with an
implementation of a different type (and lose all the wires going in/out
of the component).
- Core2 defines ReferenceDefinitions (without bindings) and
BoundReferenceDefinitions (with bindings). IMO there are Reference types
and Reference instances and both can have bindings.
or Reference.
- I think that Remotable should be on Interface and not Service.
- Scope should be defined in the Java component implementation, separate
from the core model.
- Java and WSDL interfaces should be defined separate from the core
model, we need to support multiple interface definition languages
supported by plugins, not in the core.
- Implementation should extend ComponentType IMO instead of pointing to
it, and we may even be able to simplify and just remove Implementation.
Also I am not sure why we need to distinguish between
AtomicImplementation and CompositeImplementation.
- Support for Composite Includes is missing, this is a significant part
of the recursive composition model (half of it, one of the two ways to
nest composites).
This list is not exhaustive... Another idea would be to externalize
support for Composites in a separate plugin not part of the core service
model (since there may be other ways to compose services in addition to
an SCA composite, with Spring or other similar programming models), I'd
like to know what people think about that.
I just checked in sandbox/sebastien/m2-design/model.spi a set of new
interfaces. This is just an initial strawman to trigger a constructive
discussion and ideas on how to best represent the recursive model. I
also need help to define a scenario (not unit test cases, but an end to
end sample application) to help put the recursive composition model in
perspective and make sure we all understand it the same way.
Comments, feedback and help are welcome...
> So, to turn it around a bit, as I've already outlined some of my
> reasons for liking Jeremy's approach more, do you have additional
> reasons other than you are having difficulty understanding the sandbox
> code and your feeling it will be a worthwhile exercise in knowledge
> sharing? Regarding the later, I think it's better (and more inclusive)
> to make a concerted effort to modularize and bring people into the
> sandbox code as that will allow all of the ongoing initiatives
> (particularly the ones showing Tuscany value add) to continue
> alongside the knowledge transfer.
>
> Regarding the former, could you outline specifically what you are
> having difficulty following in the sandbox code so I can try and
> address it either through explanation or simplification of the code?
>
>> ...ant
>>
>> On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>>>
>>> Why would we try this approach as opposed to the one Jeremy proposed,
>>> i.e. moving what is already in sandbox to a branch or even trunk?
>>> Since there are a number of initiatives people are already working on
>>> in the sandbox codebase (e.g. Spring support, deployment,
>>> conversations, data binding, OSGi support, support for new Java C&I
>>> annotations, support for pluggable annotations) it is seems that
>>> making improvements to that according to scenarios people are
>>> interested in will be a nice way to move things forward involving as
>>> many as possible.
>>>
>>> Jim
>>>
>>> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>>>
>>> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> > <snip/>
>>> >
>>> > 2. Stage the assembly of our M2 runtime.
>>> >> I propose that we start a fresh stream for M2 and build the runtime
>>> >> through
>>> >> baby steps, in parallel with the scenario work. This will get our
>>> >> community
>>> >> members involved in building the runtime together and will lead to
>>> >> a wider
>>> >> knowledge base that makes it possible to quickly implement new
>>> >> functionality
>>> >> in the future. It will also build a community knowledge base that is
>>> >> ready to
>>> >> help new community members come on board quickly.
>>> >
>>> >
>>> > This approach appeals to me. Could we just give it a try for a
>>> > little while
>>> > when everyone is back on Wednesday? If it doesn't work out then all
>>> > the
>>> > other code will still be available in SVN to try another approach.
>>> >
>>> > ...ant
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 3, 2006, at 5:34 AM, ant elder wrote:
> One of the big reasons for me is summed up well in Sebastien's
> proposal:
>
> "This will get our community members involved in building the runtime
> together and will lead to a wider knowledge base that makes it
> possible to
> quickly implement new functionality in the future. It will also
> build a
> community knowledge base that is ready to help new community
> members come on
> board quickly."
>
> I struggle with understanding the what and why of parts of the
> sandbox code
> and hope bringing small bits over one step at a time will help with
> this.
>
Could you outline specifically what you don't understand. Perhaps we
could do another code walkthrough like we did about a month ago?
> Why don't you like this approach? Sure it may take a bit more time
> but if in
> the long run we end up with more people understanding the runtime
> that seems
> like time well spent even if we end up with most of the trunk being
> just
> whats in the sandbox today.
>
The key point is I like Jeremy's approach better. The thought of
merging M1 with the sandbox code (Sebastien's proposal) doesn't seem
to fit based on my technical knowledge of both code bases. More
importantly, Jeremy's approach strike me as better. Since I have
outlined my reasoning in previous posts (not just technical) why I
think it is better,I won't repeat them here, as it will just confuse
the ongoing threads.
So, to turn it around a bit, as I've already outlined some of my
reasons for liking Jeremy's approach more, do you have additional
reasons other than you are having difficulty understanding the
sandbox code and your feeling it will be a worthwhile exercise in
knowledge sharing? Regarding the later, I think it's better (and more
inclusive) to make a concerted effort to modularize and bring people
into the sandbox code as that will allow all of the ongoing
initiatives (particularly the ones showing Tuscany value add) to
continue alongside the knowledge transfer.
Regarding the former, could you outline specifically what you are
having difficulty following in the sandbox code so I can try and
address it either through explanation or simplification of the code?
> ...ant
>
> On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> Why would we try this approach as opposed to the one Jeremy proposed,
>> i.e. moving what is already in sandbox to a branch or even trunk?
>> Since there are a number of initiatives people are already working on
>> in the sandbox codebase (e.g. Spring support, deployment,
>> conversations, data binding, OSGi support, support for new Java C&I
>> annotations, support for pluggable annotations) it is seems that
>> making improvements to that according to scenarios people are
>> interested in will be a nice way to move things forward involving as
>> many as possible.
>>
>> Jim
>>
>> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>>
>> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> > <snip/>
>> >
>> > 2. Stage the assembly of our M2 runtime.
>> >> I propose that we start a fresh stream for M2 and build the
>> runtime
>> >> through
>> >> baby steps, in parallel with the scenario work. This will get our
>> >> community
>> >> members involved in building the runtime together and will lead to
>> >> a wider
>> >> knowledge base that makes it possible to quickly implement new
>> >> functionality
>> >> in the future. It will also build a community knowledge base
>> that is
>> >> ready to
>> >> help new community members come on board quickly.
>> >
>> >
>> > This approach appeals to me. Could we just give it a try for a
>> > little while
>> > when everyone is back on Wednesday? If it doesn't work out then all
>> > the
>> > other code will still be available in SVN to try another approach.
>> >
>> > ...ant
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Proposed approach for M2
Posted by ant elder <an...@gmail.com>.
One of the big reasons for me is summed up well in Sebastien's proposal:
"This will get our community members involved in building the runtime
together and will lead to a wider knowledge base that makes it possible to
quickly implement new functionality in the future. It will also build a
community knowledge base that is ready to help new community members come on
board quickly."
I struggle with understanding the what and why of parts of the sandbox code
and hope bringing small bits over one step at a time will help with this.
Why don't you like this approach? Sure it may take a bit more time but if in
the long run we end up with more people understanding the runtime that seems
like time well spent even if we end up with most of the trunk being just
whats in the sandbox today.
...ant
On 7/3/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Why would we try this approach as opposed to the one Jeremy proposed,
> i.e. moving what is already in sandbox to a branch or even trunk?
> Since there are a number of initiatives people are already working on
> in the sandbox codebase (e.g. Spring support, deployment,
> conversations, data binding, OSGi support, support for new Java C&I
> annotations, support for pluggable annotations) it is seems that
> making improvements to that according to scenarios people are
> interested in will be a nice way to move things forward involving as
> many as possible.
>
> Jim
>
> On Jul 3, 2006, at 4:45 AM, ant elder wrote:
>
> > On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > <snip/>
> >
> > 2. Stage the assembly of our M2 runtime.
> >> I propose that we start a fresh stream for M2 and build the runtime
> >> through
> >> baby steps, in parallel with the scenario work. This will get our
> >> community
> >> members involved in building the runtime together and will lead to
> >> a wider
> >> knowledge base that makes it possible to quickly implement new
> >> functionality
> >> in the future. It will also build a community knowledge base that is
> >> ready to
> >> help new community members come on board quickly.
> >
> >
> > This approach appeals to me. Could we just give it a try for a
> > little while
> > when everyone is back on Wednesday? If it doesn't work out then all
> > the
> > other code will still be available in SVN to try another approach.
> >
> > ...ant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proposed approach for M2
Posted by Jim Marino <jm...@myromatours.com>.
Why would we try this approach as opposed to the one Jeremy proposed,
i.e. moving what is already in sandbox to a branch or even trunk?
Since there are a number of initiatives people are already working on
in the sandbox codebase (e.g. Spring support, deployment,
conversations, data binding, OSGi support, support for new Java C&I
annotations, support for pluggable annotations) it is seems that
making improvements to that according to scenarios people are
interested in will be a nice way to move things forward involving as
many as possible.
Jim
On Jul 3, 2006, at 4:45 AM, ant elder wrote:
> On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> <snip/>
>
> 2. Stage the assembly of our M2 runtime.
>> I propose that we start a fresh stream for M2 and build the runtime
>> through
>> baby steps, in parallel with the scenario work. This will get our
>> community
>> members involved in building the runtime together and will lead to
>> a wider
>> knowledge base that makes it possible to quickly implement new
>> functionality
>> in the future. It will also build a community knowledge base that is
>> ready to
>> help new community members come on board quickly.
>
>
> This approach appeals to me. Could we just give it a try for a
> little while
> when everyone is back on Wednesday? If it doesn't work out then all
> the
> other code will still be available in SVN to try another approach.
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org