Interesting. Taking a step back I think we should agree what we are trying
to represent in a model of the topology before we decide where the
information comes from and the exact syntax of the configuration files. So
from the previous two suggestions...
When a runtime is started up we need the runtime info i.e.
runtimeA:
hostname
ip
binding.ws:
scheme http://localhost:8080/acbd
scheme https://localhost:442/abcd
binding.sca:
scheme http://localhost:1234
binding.jsonrpc:
scheme http://localhost:8085/jsonxyz
I kept hostname/ip of the runtime in here as an indication that we need to
be able to define one, e.g. when we are on a machine with two NICs. Where
the binding requires URL info the host part is likely to be the same as that
assigned to the runtime.
When the domain is configured to include a runtime we need
domainA:
runtimeA:
components:
CalculatorServiceComponent,
AddServiceComponent
As a step in between these two we need to configure the runtime for various
other aspects of its role in the (distributed) domain.
topology and resolution (tell me what to run , find me a remote
artifact in the domain etc)
binding.file topology.xml
binding.ws http://my.registry.com
binding.jxta
management (start, stop, reconfigure etc.)
binding.jmx
We also need extra configuration for scabinding, i.e. a protocol selection
and, for some protocols, further information to drive the automatic endpoint
generation.
scabinding configuration
binding.jsonrpc
binding.jms
binding.ws
etc..
What else is there?
In the first instance we will want to be able to load all of this
information in one go via a file system based resolver for convenience so
back to the previous notes in the thread:
I'm not convinced about the use of standard SCDL elements at the top level.
If you are saying the model will easily be implemented using the existing
assembly model then there is a good case for it. We would have to add in the
other implementation types, e.g. implementation.resolution,
implementation.management or whatever. Wiring could be a convenient
mechanism for attaching bindings to these functions.
If this is not the implication behind you suggestions and you have just
chosen to use the sample element names I would go for some more explicit
halfway house where I can clearly see how it relates to the domain
topology.
<domain name="domainA">
<runtime name="runtimeA" host="hostname or ip-address">
<binding name="binding.ws">
<scheme name="http" baseURI="http://$host:8080/acbd";>
<scheme name="https" baseURI="https://$host:8090/acbd";>
</binding>
<binding name="binding.jsonrpc">
<scheme name="http" baseURI="http://$host:8085/jsonxyz";>
</binding>
<binding name="binding.sca">
<scheme name="http" baseURI=http://$host:1234/>
<other configuration?/>
</binding>
<component name="CalculatorServiceComponent"/>
<component name="AddServiceComponent"/>
</runtime>
</domain>
Regards
Simon
