Skip navigation
1 2 3 4 Previous Next


54 posts

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.



   <transform.smooks type="JAVA2XML"






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.


We have added a new quickstart, transform-smooks, to our quickstarts repository if you want to see this in action. 

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:


Take a gander and let us know what you think.

I've been working on making improvements to the unit testing of SwitchYard Services.  See Dev Forum post.


Imagine I have a CDI bean service as follows...


public class BasicOrderManagementService {

    public OrderResponse createOrder(OrderRequest request) { 
        return new OrderResponse(request.orderId);


Up to this point, invoking/testing the createOrder operation on that service in a test would have involved code like the following...


ServiceDomain domain = ServiceDomains.getDomain();

// Consume the OM model...
MockHandler responseConsumer = new MockHandler();
org.switchyard.Service service = domain.getService(new QName("BasicOrderManagementService"));
Exchange exchange = domain.createExchange(service, new BaseExchangeContract(new InOutOperation("createOrder")), responseConsumer);

Message inMessage = exchange.createMessage();
inMessage.setContent(new OrderRequest("D123", "ABCD")); 


// wait, since this is async

OrderResponse response = (OrderResponse) responseConsumer.getMessages().poll().getMessage().getContent();
Assert.assertEquals("D123", response.orderId);


By extending the new SwitchYardCDITestCase class, we can now express the same test as...


Message responseMsg = newInvoker("BasicOrderManagementService.createOrder").
                            sendInOut(new OrderRequest("D123", "ABCD"));

OrderResponse response = (OrderResponse) responseMsg.getContent(); 
Assert.assertEquals("D123", response.orderId);

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:


Also see docs on creating CDI based bean services:

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:


Milestone 1 Approacheth

Posted by kcbabo Jan 17, 2011

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.


Up Next : SwitchYard

Posted by kcbabo Jan 12, 2011

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.

Filter Blog

By date:
By tag: