SwitchYard Milestone 1

Welcome

Thanks for stopping by to check out SwitchYard Milestone 1 (M1).  This article provides a brief summary of what's in SwitchYard as of M1.  There is a plethora of links scattered throughout this page which will bring you to detailed information.  You can also check out the project site and community pages for more information.

Milestone 1 Goals

The SwitchYard team is currently working on our first release (version 0.1), which is due in early May.  We thought it would be useful to create an intermediate milestone along the way that provided an example service-oriented application.  The objective of this milestone is to assert that our original ideas would work with a basic end-to-end example and to gather feedback from the community on our direction.  This is a milestone, so there are plenty of JIRAs remaining for the 0.1 release that cover bugs and features that are not present in M1.  If you find something broken or lacking that isn't already covered by a JIRA, please file a new one or let us know in the community forum.

Getting Started

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

• Read the rest of this article.  It provides an overview of the features in M1.
• Watch a screencast which walks through the M1 application quickstart.
• Read the quickstart guide, which provides step-by-step details on what we are demonstrating in the quickstart.
• Grab the quickstart and run it yourself.  Change some stuff and see what blows up.
• Build an application from scratch using the SwitchYard application archetype.
• Build SwitchYard from source and contribute!

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;

You can find more information in the following articles:

Defining Services in SwitchYard M1

Creating Services with the Bean Component

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.   Check out these articles for more detail:

Message Payload Transformation

Transformation in SwitchYard

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.  The following articles provide more detail on our approach to configuration and some super cool features of the configuration implementation (introspection of config using scanners, configuration merging, etc.):

Application Configuration

Configuration Model APIs

SOAP Binding

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.

The SOAP Gateway is our first gateway in SwitchYard M1.  More details can be found in here.

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:

• Unit testing for Bean-based services in a CDI runtime
• Unit testing of Transform implementations
• A simplified Invoker interface which provides a fluent test client contract for invoking services in SwitchYard

More information is available in Testing SwitchYard Services.

We have also posted some initial work we have done with Arquillian integration.  We feel that this will be a killer feature in 0.1, but some issues with our AS6 deployer implementation have prevented us from completing this for M1.

Environment

Project

The SwitchYard project environment is built around Maven.  All dependencies of a SwitchYard application are resolvable via Maven dependencies and available through the public JBoss snapshot and release repositories.  An archetype is available for creating new SwitchYard applications from scratch.  More details can be found here [link].

Runtime

The 0.1 release of SwitchYard will be capable of running in stand-alone (Java SE), embedded (unit test, webapp, etc.), or as part of a managed runtime framework (e.g. JBoss AS, OSGi).  For M1, the primary focus was on a basic embedded runtime which can be bootstrapped by our unit testing support [link].  We have also created an initial AS6 deployer [link] and plan to integrate with AS7 as well.