0 Replies Latest reply on Apr 12, 2011 10:32 AM by Keith Babo

    Domain configuration

    Keith Babo Master

      So I've been playing around with runtime configuration as part of SWITCHYARD-189.  It quickly became clear that the real need at this point is for domain configuration as the properties we want to specify (bus provider, transforms, etc.) need to be scoped at the domain level.   This can be handled by allowing domains to be defined and configured via switchyard.xml.  Domains can be "deployed" stand-alone without an application or with an application (in the case where a domain should be scoped to a single application).  In my view, there are three use cases:


      1) There is a default domain for every SwitchYard runtime.  Today, we create this based off of some system properties and hard-coded bits.  We should move to a model where the default domain is defined in a switchyard.xml that is packaged with the deployer.  This will give the user some visibility into the domain configuration and also allow default configuration details to be changed.


      2) A domain can be deployed as an independent entity and referenced from applications.  So let's say you have a set of applications for the Finance team.  You can deploy a "finance" service domain with appropriate configuration independently and then when you deploy finance apps, you can specify that the apps should be deployed within this domain.


      3) A domain can be defined along with a composite in a single SwitchYard application.  This provides an application-scoped domain, which is the model we currently have with the AS deployer.  If a domain is not defined or referenced by the application, the application is deployed within the default service domain.


      I have implemented configuration support for the above here:



      I will update the deployer to look for domain definitions and act appropriately.  Please let me know if you see significant issues with this approach.