Release Overview - 0.1

 

Welcome

Thanks for stopping by to check out SwitchYard.  This article provides a brief summary of what's inside SwitchYard 0.1.  If you are completely new to SwitchYard and wondering what it is, this blog post provides some good background and pointers to additional information.

 

 

Getting Started

There a number of options for checking out what SwitchYard 0.1 has to offer.  Listed in order of increasing time investment:

 

 

Feature Highlights

SwitchYard 0.1 has lots of cool features in it.  This section highlights the main ones.

Bean Services

Implementing services in SwitchYard is dead simple using the Bean component.  The Bean component wires into Weld, our excellent JSR-299 implementation, as a CDI extension and allows services to be implemented using a basic POJO and automatically activated in the SwitchYard runtime.  Defining a service using the Bean component is simply a matter of defining a service interface and annotating the service implementation:

 

@Service(ExampleService.class)
public class ExampleServiceBean implements ExampleService

 

Consuming SwitchYard services from within a bean is just as simple via reference injection:

@Reference
private ExampleService exampleService;

 

See this feature in action in the demo/orders quickstart.

 

Camel Services

For more complex composition and routing use cases, we have added support for using Apache Camel as a routing engine within SwitchYard.  This adds the powerful EIP support of Camel to SwitchYard and allows you to create routes using the Java DSL or XML routing languages.

 

Java DSL Route

@Route(HelloService.class)
public class HelloBuilder extends RouteBuilder {
        public void configure() {
        from("switchyard://HelloService")
            .log("Message received in HelloService Route")
            .log("${body}")
            .split(body(String.class).tokenize("\n"))
            .filter(body(String.class).startsWith("sally:"))
            .to("switchyard://AnotherService?operationName=acceptMessage");
    }
}

 

XML Route

<implementation.camel>
    <route xmlns="http://camel.apache.org/schema/spring" id="Camel Test Route">
        <log message="ItemId [${body}]"/>
        <to uri="switchyard://WarehouseService?operationName=hasItem"/>
        <log message="Title Name [${body}]"/>
    </route>
 </implementation.camel>

 

See this feature in action in the camel-service quickstart.


Transformation

Transformation between data formats and representations is a ubiquitous challenge in application integration and SOA.  To address this challenge, SwitchYard incorporates transformation as a core feature of the runtime.  Service providers and consumers define the data contract used for message exchange and SwitchYard injects Transformer instances to resolve discrepancies as needed.  The process of defining and resolving transformers is straightforward, easy to test, and a delight to use.

 

The following Transform types are available in 0.1:

  • Java
  • Smooks
  • JSON

 

See this feature in action in the transform-smooks, transform-json, and demo/orders quickstarts.

 

 

Gateway Bindings

Gateways in SwitchYard provide a bi-directional binding of services.  If you need to expose a SwitchYard service to the outside world, this can be accomplished by deploying a service binding to a gateway.  If you need to invoke an external service from within a SwitchYard service, the external service can be resolved by deploying a reference binding to the gateway.

 

There are two gateways available in 0.1:

  • SOAP - binds services and references to HTTP/SOAP
  • Camel - provides the ability to use Camel config URIs to configure Camel components as gateway providers

 

See this feature in action in the camel-binding and demo/orders quickstarts.

 

Tooling

SwitchYard integrates with Forge to support rapid development of service-oriented applications.  The SwitchYard distribution contains a set of Forge plugins which can be installed into an existing Forge install.

 

This page includes examples of how to get started with SwitchYard projects in Forge.


Testing

Proper test support is critical when developing service-oriented applications in a modular fashion.  Traditionally, SOA applications are tested at the integration test level - the application is built with all service and relevant configuration, then tested from the outside using a trigger like a SOAP or JMS message.  One thing we would like to do in SwitchYard is allow for iterative development of services, with unit testing support available to validate each service component as it's built.  To that end, we have a few nice features in M1:

  • A base unit test class which bootstraps an embedded SwitchYard runtime and deploys your application
  • A variety of Test MixIns which allow you to add specific testing support based on the requirements of your application
  • A simplified Invoker interface which provides a fluent test client contract for invoking services in SwitchYard

 

See this feature in action in the transform-smooks and demo/orders quickstarts.

 

Configuration

We have invested quite a bit of effort into developing a flexible application configuration model for SwitchYard.  The core design tenets of this model are:

  • All services have a contract/interface
  • Services clearly identify dependencies on other services
  • Service configuration can be derived from project artifacts (e.g. @Service annotations on a Bean)
  • Protocol bindings (i.e. gateway config) are distinct from service definitions
  • Runtime configuration is distinct from service definitions
  • The configuration model is extensible and type-safe

 

If you check out the actual serialized form of the configuration, you'll notice that we are leveraging SCDL (the SCA definition language) to define services and references.

 

Runtimes

We have integrated SwitchYard with JBoss AS 6.0 and AS 7.0 Beta 3 for the 0.1 release.  The release distributions contain a complete AS with SwitchYard pre-installed.