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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
