One of our community members, Daniel Bevenius, has been doing some great work integrating Apache Camel as a component in SwitchYard. If you've never heard of Apache Camel, you betta ask somebody. In brief, Camel is an integration framework that provides a routing engine, suite of components/adapters, a straightforward and rich routing expression language, and fantastic built-in support for Enterprise Integration Patterns. Camel is also quite flexibile in terms of how it can be deployed and used within other containers (hence the Chameleon reference).
So how will Camel be put to use in SwitchYard? The two primary use cases are:
Using camel adapter components as gateway bindings
Using the camel routing engine as a pipeline orchestrator (similar to action processing pipeline in JBoss ESB)
Daniel has already implemented the first part and is actively working on the second. More info can be found in this article. From here, you can expect some quickstarts to help you get up and running quickly with features based on Camel. We will also be looking at some innovative ways to integrate CDI and the Java DSL in Camel. Stay tuned!
If you checked out Milestone 1, you might have noticed that the data type transformations were simply Java classes which implemented our Transformer<F,T> contract. This route works great for quick conversions, silly examples (natch), or sophisticated mappings which require tight control over the transformation behavior. Most transformation use cases will likely benefit from purpose-built transformers which handle generalized mapping tasks and can be configured for specific transformations. The first example of this in SwitchYard is the Smooks Transformer.
Smooks transforms can be added to a SwitchYard application by adding a <transform.smooks> declaration in switchyard.xml.
The above should look very familiar if you checked out the configuration generated from m1app. Just like a Java-based transformation, you specify the from and to types for the transform instance. The config parameter points to a Smooks transformation definition, which gives you the full power of Smooks to transform Java, XML, EDI, CSV, and loads more.
The SwitchYard team is happy to announce the arrival of our first milestone release! You can read all about it in the Milestone 1 Overview, which provides a summary of what's in Milestone1 along with links to detailed information on the features in the release. From the overview:
There a number of options for checking out what SwitchYard M1 has to offer. Listed in order of increasing time investment:
Magesh recently wrote some SwitchYard components to enable SOAP bindings on a SwitchYard Service, while at the same time, I did some work to allow SwitchYard expose POJOs as Services. Keith mentioned this in his last blog post.
As part of my work, I looked at approaches to making these components work more smoothly together. I recorded a VERY rough screencast of some of this work. It was recorded in one pass, so I talked too much about some things and forgot to menton others, but still... it gives an idea of what we've been doing. Take a look: http://www.screencast.com/t/85kxYxF6Cs6e
Tom has been working on some cool stuff with Weld and CDI in the context of SwitchYard. In a nutshell, we are looking at using Weld as the POJO container for SwitchYard. If you want to provide a service on the ESB or consume a service on the ESB using a Java object, just code whip up a bean (recipe: 1 Java class. 1 META-INF/beans.xml) and slap an @Service or @Reference annotation on it to connect it to the service bus. An introduction to the Bean Component can be found here:
The first milestone release of SwitchYard is scheduled for the middle of next month and we're pretty excited about what's in store. The scope is fairly modest : get a release out the door that allows users to create and run a service-oriented application using SwitchYard. Of course, it's not quite as bland as that sounds. We're looking at some exciting ways to leverage Weld and CDI to provide and consume services. We are creating a flexible approach to transformation that treats data formats and representations as an intrinsic mechanism of the service mediation runtime. We are developing an application metadata model that stresses ease of use, plays nicely with existing standards, and provides the information you need to create interoperable and governable services.
Our hope is that a quick release that demonstrates an end-to-end solution will provide a great way for users to provide feedback. I have published some initial thoughts on an example application we can use with Milestone 1 here. If you want more detail on what's going in, check out JIRA for M1. We would love to hear feedback, so drop by the community pages and share your thoughts.
Welcome to the SwitchYard project blog. What's SwitchYard you ask? Well, it's a new project we launched late last year to kick start our next generation SOA runtime. If you have been following the JBoss ESB project, you might have caught a talk that Kevin and I gave last year at JBoss World called "Next Generation ESB" (preso here). SwitchYard is the place where we will be turning the ideas from that presentation into reality.
If you are interested in learning more about SwitchYard, the project site and FAQ are good places to start. We are actively working toward our first milestone (more on that soon), so most of the activity in the project right now is in the developer forum and our Git repository. We would love to get feedback early on in the process, so please share your thoughts on what you find.
Stay tuned for updates from the team on our progress, random opinions on SOA topics, and an occasional post with TMI to keep things spicy.