Hi, Simon.
Good progress!
I'm trying to run the two nodes itest using the distributed endpoint
registry. When the endpoint is looked up, I check if the primary member for
the entry to see if it is the same as the local member to set the "remote"
flag. Then I ran into the following issues:
1) The service with binding.sca and a remotable interface is not published
to WS (as the URI is not absolute and the alwaysRemote == true).
* How do we decide if a binding.sca should be published to WS? (Maybe a
domain top-level component service with remotable interface?)
2) The derived binding URI doesn't consider the structural URI of the
component/service. Ideally, it should be <uri of the component with the
domain>/serviceName/bindingName.
We probably need to fix
org.apache.tuscany.sca.assembly.builder.impl.CompositeBindingURIBuilderImpl.constructBindingURI(URI,
URI, URI, boolean, URI).
3) We need to map it to an absolute WS URI when it publishes to the endpoint
registry (Simon already mentioned that we need to have base URIs for a given
node. For the moment, we can just use http://localhost:8080/ as the default)
so that the client side sees the physical URI of the remote endpoint.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Friday, June 19, 2009 8:59 AM
To: "tuscany-dev" <[email protected]>
Subject: [2.x] remote binding.sca
I was going to send this on Wednesday evening but got bogged down in
some OSGi problems that Raymond helped me out with. See his separate
post on Axis manifests. So a quick thank you to Raymond.
I've just checked in changes to bring up the remote version of
binding.sca. This highlights three basic scenarios for using
binding.sca
1/ wired components in same node -
EndpointReference.isRemote() = false
Endpoint.isRemote() = false
binding.sca local is used
2/ wired components in same VM but different nodes
EndpointReference.isRemote() = true
Endpoint.isRemote() = false
binding.sca remote is used (currently, but opportunity for in-VM
optimization)
3/ wired components in different VMs
EndpointReference.isRemote() = true
Endpoint.isRemote() = true (not implemented yet)
binding.sca remote is used
It may be better to do as Raymond suggested and just store the owning
node on EPR and EP and derive isRemote() from these values but that
can be a future enhancement if required. Also, I still haven't got
round to putting meaningful flags on EPR and EP to explain what state
they are in.
Here's what I did...
TUSCANY-3092 covers the various aspects of bringing up binding.sca
Due to the OSGi approach I've recoded binding.sca to load the
underlying Axis2 binding rather than referring to it explicitly
This change means that the binding that the Axis2 binding uses to
find the correct wire is the wrong one. I've side stepped this
particular issue while we decide what to do with this API.
To get the builder status right I've changed NodeImpl to build the
whole top level composite rather than the contained composites.
I've refactored the way that composite include processing works to
make it comply with OASIS re. autowire processing.
TUSCANY-3101 to make 3092 work I had to do the binding provider
refactoring work
The two nodes itest now talks across the remote binding.sca which is
slightly different form how it was working before these changes. We
need to look and decide if this is right. It may have implications for
what Ant is doing in Tomcat.
There are outstanding tasks
- As I got behind this is not, by any stretch of the imagination, neat
code yet. Needs tidying.
- Calculating the SCA binding URL and hence the full details of an
endpoint inside a Node will rely on node configuration that we don't
yet have. This is the information that is held in the cloud config
files in the Domain Mananger in 1.x
- It threw up problems with having same runtime for different nodes.
When ports are shared for host.jetty shutting down one node removes
all the servlets and the next node to shutdown causes and error and it
can't find the servlets it needs to remove. I've raised TUSCANY-3107
- Look to see what the impact on the Tomcat based domain is
- I also came across this problem that we had in 1.x where the class
visitors are added twice. I added the same work around. TUSCANY-3070
- More work required on composite include processing to take account
of other fields. I've raised TUSCANY-3106
Regards
Simon
