On Thu, Feb 28, 2008 at 5:50 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On Tue, Feb 26, 2008 at 5:49 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > > > On Tue, Feb 5, 2008 at 8:34 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > > > Venkata Krishnan wrote: > > > > It would also be good to have some sort of 'ping' function that > > > could be > > > > used to check if a service is receptive to requests. Infact I > > > wonder if the > > > > Workspace Admin should also be able to test this sort of a ping per > > > > binding. Is this something that can go into the section (B) .. or > > > is this > > > > out of place ? > > > > > > > > > > Good idea, I'd put it section (D). A node runtime needs to provide a > > > way > > > to monitor its status. > > > > > > -- > > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Hi Sebastien > > > > I see you have started to check in code related to steps A and B. I have > > time this week to start helping on this and thought I would start looking at > > the back end of B and moving into C but don't want to tread on you toes. > > > > I made some code to experiment with before I went on holiday so it's not > > integrated with your code (it just uses the Workspace interface). What I was > > starting to look at was resolving a domain level composite which includes > > unresolved composites. I.e. I built a composite which includes the > > deployable composites for a series of contributions and am learning about > > resolution and re-resolution. > > > > I'm not doing anything about composite selection for deployment just > > yet. That will come from the node model/gui/command line. I just want to > > work out how we get the domain resolution going in this context. > > > > If you are not already doing this I'll carry on experimenting in my > > sandbox for a little while longer and spawn of a separate thread to discuss. > > > > Simon > > > > > > And here's the separate thread following on from [1]... I'm looking at > what we can do with any endpoint information we have prior to the point at > which a composite is deployed to a node. This is an alternative to > (replacement for?) having the Tuscany runtime go and query for endpoint > information after it has been started. I have been summarizing info here > [2][3]. Looking at this I need to do something like... > > - associate composites with nodes/apply physical binding > defaults/propagate physical addresses based on domain level wiring > > 1. Read in node model - which provides > 1. Mapping of composite to node > 2. Default configuration of bindings at that node, e.g. the > root URL required for binding.ws > 2. For each composite in the domain (I'm assuming I have access to > the domain level composite model) > 1. Find, from the node model, the node which will host the > composite > 2. for each service in the composite > 1. If there are no bindings for the service > 1. Create a default binding configured with the > default URI from the node model > 2. We maybe should only configure the URI if we > know there is a remote reference. > 2. else > 1. find each binding in the service > 1. Take the default binding configuration > and apply it to the binding > 2. What to do about URLs as they may be > either > 1. Unset > 1. Apply algorithm from Assembly > Spec 1.7.2 > 2. Set relatively > 1. Apply algorithm from Assembly > Spec 1.7.2 > 3. Set absolutely > 1. Assume it is set correctly? > 4. Set implicitly (from WSDL > information) > 1. Assume it is set correctly? > 3. The above is similar to what goes > during compositeConfiguration in the build phase > 3. For each reference in the composite > 1. Look for any targets that cannot be satisfied within > the current node (need an interface to call through which scans the > domain) > 2. Find the service model for this target > 3. Do policy and binding matching > 4. For matching bindings ensure that the binding URL is > unset and set with information from the target service > 5. The above is also similar to what happens during the > build phase > 4. Domain Level Autowiring also needs to be taken into > account > 5. Wire by impl that uses domain wide references also need to > be considered > > Referring to the builder code now is feels like 2.2 above is a new "model > enhancement" step that could reuse (some of) the function in > CompositeConfigurationBuilderImpl.configureComponents but with extra > binding specific feature to ensure that URLs are set correctly. > > 2.3 looks very like CompositeWireBuilder. > > My quandry at the moment is that the process has a dependency on the node > description so it doesn't fit in the builders where they are at the moment. > It feels like we need a separate module. So comments about whether any of > this makes sense and, if so, where I should put it are welcome. > > Simon > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28299.html > [2] > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing > [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases > I have some code [1] for steps 1, 2.1 and 2.2 above and I want to move it out of my sandbox to see how it fits. Two questions A) I have a relatively stand alone algorithm [2] that populates service binding URIs (similar to the CompositeConfigurationBuilder and I would like to combine the two in the future) and am assuming for now that it will slot into o.a.t.s.workspace.configuration.imp. Anyone not happy with that please speak up. B) The algorithm (A) that calculates service endpoints based on node default binding configurations depends on knowing the protocol that a particular binding is configured to use. As this is a result of a binding configuration, based on binding, interfaces descritions, policy I have taken the approach of creating a new extension point, BindingURICalculator [3], which will hold this and probably other binding specific function related to URI calculation. I want to check that there isn't somewhere else that people think this function should live. Am writing tests at the moment so you have time to comment before I do move out of my sandbox. Thanks Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/ [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/workspace/configuration/impl/NodeAssigner.java [3] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/binding/BindingURICalculator.java
