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.

<transforms>
   <transform.smooks type="JAVA2XML" 
      from="java:org.switchyard.quickstarts.transform.smooks.OrderAck" 
      to="{urn:switchyard-quickstarts:transform-smooks:1.0}submitOrderResponse" 
      config="/smooks/OrderAck_XML.xml"/>
</transforms>

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. 

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...

@Service
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")); 

exchange.send(inMessage); 

// wait, since this is async
responseConsumer.waitForOKMessage();

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: http://www.screencast.com/t/85kxYxF6Cs6e

Also see docs on creating CDI based bean services: http://community.jboss.org/wiki/CreatingServiceswithBeanComponent

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.