Separating out the Java container from the core

[ant elder <an...@gmail.com>]

As part of the modularization work its been suggested separating the Java
component container out from the core to be an extension just like the other
extensions. For example, see [1] and diagram [2]. Lets have a discussion on
this specific proposal trying to get some consensus and then vote on it to
get closure.

One of the reasons I like this proposal is it will help solidify the
extension SPI. With the Java container included as part of the core it
doesn't have to use the SPI so can get away with doing things that other
extensions can not. This means the SPI falls behind kernel changes and its
sometimes not possible to implement another container without just copying
bits of the core code.

Something that hasn't been proposed yet is exactly how the core would be put
together if it wasn't using SCA assembly.  The diagram [2] suggests "Either
hand-wire the built-in system services or use an IoC container".  Could
there be a specific proposal on how this would be done?

The main reason suggested against doing this so far is: "users (would) need
to be familiar with two assembly mechanisms and that seems like confusing
and unnecessary complexity." [3]. I don't understand why users need to
understand or even be aware of how the Tuscany runtime is implemented?

   ...ant

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16034.html
[2]
http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions
[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16072.html

Re: Separating out the Java container from the core

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> As part of the modularization work its been suggested separating the Java
> component container out from the core to be an extension just like the 
> other
> extensions. For example, see [1] and diagram [2]. Lets have a 
> discussion on
> this specific proposal trying to get some consensus and then vote on 
> it to
> get closure.
>
> One of the reasons I like this proposal is it will help solidify the
> extension SPI. With the Java container included as part of the core it
> doesn't have to use the SPI so can get away with doing things that other
> extensions can not. This means the SPI falls behind kernel changes and 
> its
> sometimes not possible to implement another container without just 
> copying
> bits of the core code.
>
> Something that hasn't been proposed yet is exactly how the core would 
> be put
> together if it wasn't using SCA assembly.  The diagram [2] suggests 
> "Either
> hand-wire the built-in system services or use an IoC container".  Could
> there be a specific proposal on how this would be done?
>

I think it's pretty simple. One of the benefits of IoC is that your 
objects do not depend on the framework or container used to assemble 
them. Our kernel is basically an assembly of POJOs (this is good) wired 
together by... our kernel (and this part is causing chicken and egg 
issues). The good news is that, thanks to IoC, we should be able to use 
different techniques to assemble these POJOs. There are many ways to do 
it. An obvious way is to write a page of code or two to do the wiring 
"by hand".

Basically assuming 2 Tuscany "system components" PojoA and SysPojoB:
public class PojoA implements A {
  private B b;

  @Reference
  public void setB(B b) {
    this.b = b;
  }

  public PojoA() {}
}

public class PojoB implements B {
  public PojoB() {}
}

Instead of using an SCA assembly description supporting special "system" 
components like this:
<composite name="..." autowire="true">
  <component name="ComponentA">
    <implementation.system class="PojoA"/>
  </component>
  <component name="ComponentB">
    <implementation.system class="PojoB"/>
  </component>
</composite>

do something like that:
public class SimpleWiredByHandRuntime {
    public A setupTheRuntime() {
      A a = new A();
      B b = new B();
      a.setB(b);
      return a;
    }
}

This may be a good way to assemble our runtime, or maybe not. It seems 
straightforward - to me at least :) - and won't cause any chicken and 
egg problems. We will probably not know which is the best way until we 
actually try, so I'd like to try this in one of our runtime assemblies 
to make it concrete and help understand the benefits and issues (if any) 
of such an approach. I think that we could live with different assembly 
techniques in our various runtimes for a while and over time see which 
one people prefer to use.

> The main reason suggested against doing this so far is: "users (would) 
> need
> to be familiar with two assembly mechanisms and that seems like confusing
> and unnecessary complexity." [3]. I don't understand why users need to
> understand or even be aware of how the Tuscany runtime is implemented?
>

I don't either.

>   ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16034.html
> [2]
> http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions 
>
> [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16072.html
>

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org