Queries on certain M2 concepts

[rakesh dash <da...@gmail.com>]

Hello,

         I am starting to understand the basics of certain M2 related
concepts and am trying to navigate the src tree of the run time.
It would be great if someone may clarify few of my basic queries on it. My
apologies in advance, if I have misinterpreted any concept wrongly. Please
rectify it and clarify. Thanks in advance.

1. Due to various reasons the existing core architecture was considered to
have substantial refactoring.It would be great if an one to one mapping
could be established between these reasons and how the new update in the
core/runime may solve it.This may help us to get a good understanding.

2. How the new model reduces the number of SCA concepts?
For example-composite seems to be more bulkier than the previous 'module' in
M1. In the 'composite' model most of the concepts are similar to the module.
An added properties field is present. While composite adds more
functionality, it seems to be making the simplest SCA component more
complicated.
As a different instance, the wiring concept has inbound and outbound
concepts which has interceptors and other features. Again making things
complicated.Please clarify.

3. While I am not sure of how the target Invoker dispatches a request to the
target implementation, I think the TargetInvoker will have address or
reference for the Target instance using which it may locate the target
implementation.
Now is it possible to represent this address or reference in such a format
which can be stored and saved in file? This may give another option using
which the wire invocation handler(at the source)may locate the target
address. This may avoid storing always storing the TargetInvoker to the
source wire invocation handler everytime before an invocation is initiated.
It might add to the interoperability.
Please let me know your opinion.

Re: Queries on certain M2 concepts

[Jim Marino <jm...@myromatours.com>]

On Jul 19, 2006, at 10:48 PM, rakesh dash wrote:

> Jim,
>
> Thanks a lot for your response.
>
> 1. In the slide 4, it states to reduce the number of concepts of  
> SCA. How
> does composite attains it?
>
>      For example- services are equivalent to entry point,  
> references are
> similar to external service.
> The added thing is properties.
> It keeps similar concepts of modules and adds properties also. How  
> do we
> think that it redu ces SCA concept when it is adding more  
> functionality to
> it?
> Here I would recommend to use the existing module/M1 concept and  
> add things
> to it instead of doing things from scratch. Let us reuse the  
> functionality
> which is already in M1. Please clarify.
The *specification* has changed and we (Tuscany) are following the  
specification. I think if you compare UML representations of the .9  
spec and recursive model it is dramatically simpler, two of the most  
apparent examples being:

- Components have services and references; there is no need for  
additional concepts of entry points or external services

-  We removed the concept of module component. Since module  
components could also be configured, the notion of composite  
properties is not really new, although with the addition of XPath and  
includes, it is significantly more powerful.

Also, I'm not sure I follow you but I think having fewer concepts can  
result in something that is much more powerful. For example,  
recursion reduces the number of specialized concepts yet is offers  
many more possibilities than the 2-level model we had before.

>
> 2. In slide 11 there is a list of reasons provided which tries  
> giving us
> explanation of why the current M1 architecture requires refactoring?
> I would request to provide a one to one mapping of this list to the  
> new
> concepts of M2 which resolves the issues of M1 architecture.
I'm sure this would be helpful and if someone is brave enough to  
attempt this, I am willing to answer questions. However, since that  
is a very wide open request (and difficult to tackle in its  
entirety), my suggestion would instead be to proceed by asking  
specific questions.
>
> Apart from this, I do agree with you that the wiring concept in M2  
> may be
> simplified with all the present functionalities. We should  
> certainly make it
> more simplified keeping the existing functionality.
>
> It would be great if you could give me a clear picture on how  
> targetInvoker
> works. I understand that the targetInvoker resolves the target  
> instance by
> resolving scopeContainer.
It actually invokes on Component, which uses a scope container to  
resolve an implementation instance.
> I think the whole process should have the address
> of target instance using which the target invoker may locate the  
> target
> instance.
Outside of a callback and reference that invokes over a binding, why  
does a target invoker need the address of the component? In SCA,  
components cannot be directly exposed or directly invoke outside the  
boundaries of their parent composite; all cross-composite invocations  
must flow across services and references. This means we can  
statically analyze and wire all component-to-component invocations,  
alleviating the need to use addresses for intra-composite invocations.

> I am not sure where this address is provided to the targetInvoker?
> Do the ScopeContainer provides the target address/reference to the
> targetInvoker?
The scope container is responsible for tracking implementation  
instances using whatever mechanisms are appropriate (e.g. session/ 
conversation id, etc.). That should be opaque to clients of the scope  
container, such as Components.

> Can you please clarify? Can you please let me know the packages/ 
> classes
> which I can go through to get a good idea about it.
>
In core there is an implementation package. There are also samples.  
My recommendation would be to start perhaps with the eager init or  
calculator samples and then work your way into running the test  
cases. If you have any questions, I'll try to help as best I can.

Jim

> cheers,
> Rakesh.


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

Re: Queries on certain M2 concepts

[rakesh dash <da...@gmail.com>]

Jim,

Thanks a lot for your response.

1. In the slide 4, it states to reduce the number of concepts of SCA. How
does composite attains it?

      For example- services are equivalent to entry point, references are
similar to external service.
The added thing is properties.
 It keeps similar concepts of modules and adds properties also. How do we
think that it redu ces SCA concept when it is adding more functionality to
it?
Here I would recommend to use the existing module/M1 concept and add things
to it instead of doing things from scratch. Let us reuse the functionality
which is already in M1. Please clarify.

2. In slide 11 there is a list of reasons provided which tries giving us
explanation of why the current M1 architecture requires refactoring?
I would request to provide a one to one mapping of this list to the new
concepts of M2 which resolves the issues of M1 architecture.

Apart from this, I do agree with you that the wiring concept in M2 may be
simplified with all the present functionalities. We should certainly make it
more simplified keeping the existing functionality.

It would be great if you could give me a clear picture on how targetInvoker
works. I understand that the targetInvoker resolves the target instance by
resolving scopeContainer. I think the whole process should have the address
of target instance using which the target invoker may locate the target
instance. I am not sure where this address is provided to the targetInvoker?
Do the ScopeContainer provides the target address/reference to the
targetInvoker?
Can you please clarify? Can you please let me know the packages/classes
which I can go through to get a good idea about it.

cheers,
Rakesh.

Re: Queries on certain M2 concepts

[Jim Marino <jm...@myromatours.com>]

Hi comments inline
On Jul 16, 2006, at 10:17 PM, rakesh dash wrote:

> Hello,
>
>         I am starting to understand the basics of certain M2 related
> concepts and am trying to navigate the src tree of the run time.
> It would be great if someone may clarify few of my basic queries on  
> it. My
> apologies in advance, if I have misinterpreted any concept wrongly.  
> Please
> rectify it and clarify. Thanks in advance.
>
> 1. Due to various reasons the existing core architecture was  
> considered to
> have substantial refactoring.It would be great if an one to one  
> mapping
> could be established between these reasons and how the new update  
> in the
> core/runime may solve it.This may help us to get a good understanding.
>
We did a long presentation on this a while back. Unfortunately, it  
was not recorded (a good reason why mailing list discussion is better  
than presentations). There are slides from this under sandbox/chianti/ 
doc that lay out the reasoning behind the refactors and basic chianti  
architecture. I would have a look there and post questions to the  
list as they arise.

> 2. How the new model reduces the number of SCA concepts?
> For example-composite seems to be more bulkier than the previous  
> 'module' in
> M1. In the 'composite' model most of the concepts are similar to  
> the module.
> An added properties field is present. While composite adds more
> functionality, it seems to be making the simplest SCA component more
> complicated.
I think it actually reduces the number of concepts since we no longer  
have the module component specialization. The design is also more  
symmetrical.

Just a side note, a module and a composite are different concepts,  
the former being more about a unit of deployment, which is something  
we haven't addressed very well in the spec as of yet.

> As a different instance, the wiring concept has inbound and outbound
> concepts which has interceptors and other features. Again making  
> things
> complicated.Please clarify.
We have these two concepts for several reasons:
- In SCA, policies can be applied to the source (outbound) or target  
(inbound) side of a wire
- We need to have the ability to re-wire at runtime, e.g. change a  
target and reconstitute the wire. IMO having two sides like this  
actually reduces the complexity in performing this operation

That said, I do agree the runtime invocation model is complex. The  
important question is whether it is more complex than it needs to be.  
That said, we always need to look at simplifying the design without  
loosing capabilities. I do think, however, there is always going to  
be a base level of complexity to meet the use cases we have in mind  
(see below). It would be good to have more eyes on simplifying the  
design so any help would be greatly appreciated.

>
> 3. While I am not sure of how the target Invoker dispatches a  
> request to the
> target implementation, I think the TargetInvoker will have address or
> reference for the Target instance using which it may locate the target
> implementation.
In the slides mentioned above, there is a section which explains  
this. One of the key things about the runtime (and SCA in general) is  
that it attempts to perform static analysis on wires since it most  
often knows the source and target, optimizing where appropriate. This  
is one of the key differences with other approaches such as JBI.   
Hence, most of the time a TargetInvoker (which is per operation, not  
per service) is set to the target *component* and no dynamic routing  
is necessary. The one detail here is that it is not necessarily set  
to the target component *instance*; during an invocation it is the  
job of the component to delegate to its scope container to return the  
correct instance.

There are two caveats to the above. First, one optimization is that  
certain target invokers may cache the target instance (e.g. when  
invoking from a "lesser" scope to a "larger" scope, session--- 
 >module). The other caveat is that for callbacks we will need a way  
to dereference the correct callback instance. I'm not sure this is  
the job of the target invoker, though.

> Now is it possible to represent this address or reference in such a  
> format
> which can be stored and saved in file?
I would say it has to be "serializable" in some form supported by the  
transport binding (in the case of in-VM, Java serializable, other  
protocol bindings may have different requirements).
> This may give another option using
> which the wire invocation handler(at the source)may locate the target
> address. This may avoid storing always storing the TargetInvoker to  
> the
> source wire invocation handler everytime before an invocation is  
> initiated.
Again, I think the important thing here is static optimization. For  
*all* component-to-component invocations in SCA, the source and  
targets are known since all remote wiring must be done through  
composite references and services. Hence, there is no reason to  
perform an address lookup at this level. For outbound remote  
invocations across a composite reference, the binding will probably  
handle the addressing semantics.

> It might add to the interoperability.
Could you explain?

Thanks for the feedback. Questions/help/comments relating to  
improvements would be appreciated.

Jim

> Please let me know your opinion.


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