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