Configuration Thoughts
kcbabo Dec 3, 2010 12:46 PMWanted to share some initial thoughts around configuration and get some feedback. There are actual two different flavors of configuration:
1) System configuration - similar to jbossesb-properties.xml and the like in JBoss ESB. This is configuration of the runtime and doesn't change for any given service deployment.
2) Application configuration - this is more like jboss-esb.xml in JBoss ESB. The application configuration consists of service definitions, binding details, service artifacts, etc. Basically this is the information required to get your deployed services up and running. This information does change between deployments and as such the application configuration is supplied with each deployment.
I'm going to focus on application configuration in this post. There are three primary consumers of the application configuration:
- Individual components get information on what they are supposed to do (provide a service, consume a service) and how (configuration details). For example, a SOAP gateway would be told that it will be exposing a WS endpoint for a SwitchYard service along with a pointer to the WSDL to use.
- The core runtime will read policy, transformation requirements, wiring, and other service metadata and register appropriate handlers.
- Clients wishing to browse/discover service metadata based on the application configuration. Note that this will most likely be stored outside of the core runtime in a repository and is not something that is generated as part of the deploy/lifecycle workflow of the core runtime.
With all that out of the way, let's get into details via examples. I'm going to use a YAML-style format here because it's concise and makes me feel cool.
We want to define a "HelloWorld" service. Our service is implemented as a CDI bean and conforms to the "Greeting" service interface.
service : name : HelloWorld interface : org.switchyard.examples.Greeting implementation : bean
The implementation value is simply the container that holds the service implementation logic. I could define another service implemented in Spring.
service : name : RandomNumberGenerator interface : org.switchyard.examples.LuckyLottoNumbers implementation : spring
Now let's say I want to include lucky lottery numbers with my greeting. I can do that by adding a reference to RandomNumberGenerator from HelloWorld.
service : name : HelloWorld interface : org.switchyard.examples.Greeting implementation : bean reference : lottoNumbers target : RandomNumberGenerator
I can expose my HelloWorld service by adding a reference binding.
service : name : HelloWorld interface : org.switchyard.examples.Greeting implementation : bean reference : lottoNumbers target : RandomNumberGenerator
Or I can associate a reference binding without changing the original service definition.
reference :
target : HelloWorld
binding : soap
address : http://localhost:8080/HowdyYall
The above examples are pretty basic, but cover some of the basic use cases of the ESB. For the first iteration, we need the ability to support the following:
- Provide a service locally by specifiying a service + implementation
- Expose a local service to external consumers using a reference binding
- Expose a remote service locally by specifying a service + binding
- Consume a service locally by specifying a reference + target
If you have a passing familiarity with SCA, you will notice that this looks similar to a number of concepts in the SCA assembly model specification. This is deliberate and I think there are a number of ways we can integrate nicely with SCA without providing full SCA runtime implementation. One way is to serialize our configuration model as SCDL (SCA configuration language). Anyway, we can talk more about that later. For now, I just wanted to get a conversation started on the important pieces w/r/t configuration. I plan to take Tom's CDI work and code up some examples and the associated config for those examples.