Simon Laws wrote:
On 8/10/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, August 09, 2007 3:46 PM
Subject: Re: Accessing global domain information
On 8/9/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED] > wrote:
Simon Laws wrote:
I need some advice on the way the code is structures. In various
places in
the code I need to get at some information that logically belongs
to
the sca
domain. For example,
CompositeWireBuilderImpl.connectComponentReferences()
Tries to resolve services. In the distributed case this resolution
may
validly fail and I need to ask the domain whether the service is
available
elsewhere. So I need access to some domain management services.
Ideally I
would like to have access to a domain interface but am unsure how
to
plumb
it in as this kind of thing isn't generally available now. Anyone
care
to
offer some advice how I get at such an interface without breaking
the
SPIs?
Thanks
Simon
WireCompositeBuilderImpl is not an SPI, so you can pass whatever you
want to its constructor without breaking any SPI.
But I have a preliminary question: Why do you need to ask the domain
(management service) about remote services at that specific point in
WireCompositeBuilderImpl?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
I was thinking about this on the drive home. Just looking back at the
code
I had missed the important point that a reference target remains
unresolved
if the target component cannot be found. I could use this instead of
the
actual service lookup at this point. The issue I have though is that
the
CompositeWireBuilder dumps the bindings from the reference if it can't
find
a matching service/binding. This will be the case if the model for the
references service/binding is not read into the model for the current
node,
i.e. if the target component is not included in the current nodes
contributions.
Is it valid to only replace the current bindings with
"selectedBindings"
if some selected bindings have actually be found?
Simon
Have been looking into this a little more and it seems that the list of
matched bindings takes into account the reference multiplicities and
then
is
used during activation to create the runtime wires so we do have to be a
little cleverer in terms of creating a dummy resolved target to keep the
bindings in play.
Let's assume the reference is wired to a remote SCA service for this
discussion. For non-SCA services, it's simpler as we just have to pick a
binding locally for the reference and the binding URI will be good enough
for the routing.
There are two factors here:
1) What information is required from the service side for the reference
side
to choose the right binding?
service: {service uri in the domain, a list of bindings} (I intentionally
skip the intent/policy stuff here). The key is that should be able to
build
a call routing to this service endpoint.
2) When should we try to do the matching between the reference and the
service?
In some cases, the remote service information is not available when the
runtime wires are constructed. It means we have to defer the process when
the reference is used.
Anyone out there intimately familiar with the resolution process? What I
want to be able to do is have an sca binding (or any other binding for
that
matter) remain in place even in the case where the referenced target is
not
available in the local domain composite. Come runtime wire generation
time
the binding itself can take responsibility for creating the correct
providers and invokers so that, assuming the referenced service is
remoteable, the request can be routed to the correct node.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks Raymond, I'm with you there. I'm not sure whether you are agreeing
or disagreeing that maintaining the list of unresolved targets will be
problematic. I'm going ahead on the basis that we need to maintain the list,
i.e. I'll change
if (!targets.isEmpty() &&) {
// Add all the effective bindings
to
if (!targets.isEmpty() &&
!selectedBindings.isEmpty()) {
// Add all the effective bindings
at the bottom of
CompositeWireBuilderImpl.connectComponentReferences()
and see how I get on. In this way the candidate bindings hang around until
later on in the case that the targets are unresolved.
Simon
+1 yes the candidate bindings need to hang around until later when the
targets get eventually resolved.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
