The basic gist of what's happening here is simple enough. When SwitchYard sees a CDI @Service with operations implemented using JAXB annotated types, it automatically installs JAXB transformers to transform between these JAXB types and their corresponding XML namespace. If then (for example), you use the same wsdl (as used to generate the JAXB Java types) to expose a Webservice via the SwitchYard SOAP Gateway, all the transformation logic is automatically set up for the service, so no need to implement and configure any transformers.
Even though SwitchYard is a new project, we have already enjoyed fantastic support from our community. Prior blog posts have highlighted the initial support for Camel and the addition of a JSON transformer. For this community spotlight post, I want to point out some work that Mario Antollini has done w/r/t Camel configuration.
Camel supports a wide array of components which accept configuration as a URI. For example, the following URI configures the Camel File component to consume files from the "/tmp/input" directory:
You can't get much more convenient than that. This is one of the features that makes Camel such a joy to use. There are a couple of things to watch out for with URIs though. First, some components in the Camel community support a ton of config options. Let's take another look at a file config URI that uses a few more options:
The above config is a bit chattier and presents two potential challenges:
1) It's getting tough to parse with the naked eye, which makes reading or updating the config string a bit more error prone.
2) Validation in tooling is a challenge because we don't have a definition of which settings are allowed and what values those settings can take.
One way to address this is to define a schema for the component configuration and use that to structure the config parameters and validate them. Here's the same config URI represented as a gateway binding config:
Mario has added configuration model support to parse, create, and validate a number of Camel component configs and more are being added. If you prefer the straight URI route, then that option is still available as well through the base camel binding configuration:
The SwitchYard team is happy to announce the arrival of our first release - 0.1! You can read all about it in the Release Overview, which provides a summary of what's in 0.1 along with links to detailed information on the features in the release. Take SwitchYard for a spin and let us know what you think.
After building you'll find there are a number of quickstarts jar files that can be deployed to your SwitchYard enabled AS Server. We'll be adding proper readmes/docs to the quickstarts before the release but here's a quick rundown:
demos/orders: This Quickstart demos the SwitchYard SOAP component combind with the CDI based Bean Services. Deploy it to your App Server and then use a SOAP Client (e.g. soapUI) to invoke the SOAP endpoint binding (see the AS console for the Service URL and then add "?wsdl" to get the wsdl). This invokes CDI Bean implemented SwitchYard Service through the SwitchYard Exchange mechansim.
camel-binding: This Quickstart demos SwitchYard's Apache Camel integration. A CDI Bean Service is exposed via a Camel File Endpoint. To exercise the quickstart you need to drop a "test.txt" file (containing some text) into the "target/input" folder off your App Server's bin directory (e.g. "switchyard-as6-0.1/bin/target/input").
camel-service: This quickstart is currently broken and we are working on fixing it.
Please give it a try and let us hear about any issues you encounter !!