1 2 3 4 Previous Next


49 posts

It's the day before Thanksgiving here in the U.S. and the SwitchYard team is talking turkey with a 1.1.0.Final release.  This release focused on incorporating features and enhancements that didn't make 1.0.0.Final as well as dialing in our wizbang Eclipse tooling (which accounted for ~ 35% of issues resolved in the release).  Next step for the community is the big jump to 2.0, where we already have big work brewing.  More details to follow after we binge on bird meat and emerge from our tryptophan-induced food coma.


What is SwitchYard?

SwitchYard is a structured framework for developing integration applications using the design principles and best practices of Service Oriented Architecture.  It integrates really well with Apache Camel and JBoss Application Server, providing a runtime based on the best open source integration and application server options out there.  A slightly longer description can be found here.


What's in 1.1?

The team was busy this release, with 167 total issues resolved for 1.1.  A complete list of issues resolved in 1.1 can be found in JIRA.  Here are some of the bigger fish in the pond:

[SWITCHYARD-1729] Security context is not propagated between service calls

[SWITCHYARD-1607] Decision table support missing from Rules component

[SWITCHYARD-1465] Make Context and Message available to bean services on all paths

[SWITCHYARD-1600] Add non-model URI configuration parameters to all integrated SY gateways

[SWITCHYARD-1729] Security context is not propagated between service calls

[SWITCHYARD-1450] Provide confidentiality after successful WS decryption

[SWITCHYARD-1576] Allow registration of Channels for stateless sessions

[SWITCHYARD-1607] Decision table support missing from Rules component

[SWITCHYARD-1728] Bump schema versions for model changes made since 1.0

[SWITCHYARD-1759] Exchange cannot be injected into bean services

[SWITCHYARD-1601] Make RESTeasy gateway aware of runtime and application faults

[SWITCHYARD-1600] Add non-model URI configuration parameters to all integrated SY gateways

[SWITCHYARD-1604] Support imported WSDL definitions

[SWITCHYARD-1738] Add support for configuring SwitchYard version using runtime components

[SWITCHYARD-1797] connector lines drag and drop interaction


Where Do I Get This Goodness?

The SwitchYard Downloads page has all the SwitchYard bits and pieces.  I highly recommend following the Installation Guide to install the runtime and tooling.  The guides are short, moderately useful, and 67% free of spelling and grammatical errors.

How Do I Learn More?

SwitchYard and OpenShift come together like peanut butter and jelly in our latest episode in the SwitchYard Video Series ...


The SwitchYard team helped put together a set of labs for Red Hat Summit this year focused on getting started with SwitchYard.  The objective of these labs was to take attendees with no experience with SwitchYard and help them become productive users of the project.  The labs set the stage by walking through an example application and explaining what you need to know followed by hands on development and configuration of common integration application scenarios.  We received some great feedback from attendees and the lab was one of the top-ranked sessions at Summit this year.  Here's what one attendee had to say*:


"I loved it. It was much better than CATS. I'm going to do these labs again and again."


With that kind of praise, you owe it to yourself to try these labs out!  The labs and lab guides are hosted in the learning repository for SwitchYard on GitHub:







* OK, I was the one that said that.

Getting sick of all these 0.x minor releases of SwitchYard?  Well good news ... we're getting all major up in here with a 1.0.0.Final release!  Truth be told, the bits have been available for weeks now, but we spent some quality time with the tooling and documentation after the runtime was done to make sure 1.0 was done right.


What is SwitchYard?

SwitchYard is a structured framework for developing integration applications using the design principles and best practices of Service Oriented Architecture.  It integrates really well with Apache Camel and JBoss Application Server, providing a runtime based on the best open source integration and application server options out there.  A slightly longer description can be found here.


What's in 1.0?

This was a monster release for the team, with 184 total issues resolved for 1.0.  Here are the most important updates for 1.0:

  • The project has changed from LGPL to the Apache License v2.0.
  • Camel components not distributed directly with the project can now be added as extension modules to the SwitchYard subsystem, allowing any Camel component, data format, etc. to be added to SwitchYard easily.
  • Camel routing services can now configure multiple routes per service.  This allows complex routing logic to be broken up into separate routes and also makes our XML routes play nicely with the Fuse Camel editor.
  • HTTP-based gateways (REST, SOAP, HTTP) added support for proxy configuration, basic authentication, and NTLM.
  • All gateways have been updated to include support for starting and stopping individual bindings.  This allows you to stop/restart processing on a given endpoint from our admin clients.
  • The SOAP Gateway now supports MTOM, SOAP w/ Attachments, and WS-Addressing.
  • Generating Java interfaces from WSDL is now supported in the visual editor for all the folks that like to design top-down.
  • The JCA gateway has been tested and documented for use with ActiveMQ for message inflow and outbound.
  • The SwitchYard admin API has been updated to include JMX support.
  • Multi-step transformation is now supported, so if you don't have a transformer to go from A -> C, but you have A -> B and B -> C, then we can get the job done.
  • BPM services now support customizable correlation keys so you don't have to pass the process instance id back into the process with each subsequent request.
  • Service throttling is now supported to govern throughput for any service.
  • We went through the public API with a fine-tooth comb to make it nice and clean.  There will be no backward incompatible changes made to APIs or configuration for 1.x.
  • Our tooling gets more beautiful with each release, and this one is no exception. 
  • An EAR deployment example has been added to our quickstarts and is now tested as part of our release test suite.
  • If you don't want to put clear text passwords in your switchyard.xml, you can use our properties support in combination with the AS 7 password vault to protect that sensitive info.
  • Security can now be configured on a global or per-service basis with the addition of named security configs to switchyard.xml.


A list of all the issues that went into 1.0 can be found in JIRA.


Where Do I Get This Goodness?

The SwitchYard Downloads page has all the SwitchYard bits and pieces.  I highly recommend following the Installation Guide to install the runtime and tooling.  The guides are short, moderately useful, and 67% free of spelling and grammatical errors.


How Do I Learn More?

Keith Babo

SwitchYard 0.8 Released

Posted by Keith Babo Mar 26, 2013

SwitchYard 0.8.0.Final has been deployed to Nexus and is available via the project downloads page.  There's some great stuff in this release with a total of 98 issues resolved.  The bedrock of all SwitchYard releases, the Release Overview, is available with the usual background and details on what's new in SwitchYard 0.8.


The next release for the SwitchYard project is gonna be a biggie.  We are very close to fulfilling the goals we set for a 1.0 release of the project.  Close enough that a 0.9 release will not be necessary and 1.0 will be the next community release.  In fact, our nightly builds are already sporting a 1.0.0-SNAPSHOT version.  It's the perfect time to give 0.8 a try and contribute feedback for 1.0.



The SwitchYard Team

We're trying something new in the SwitchYard project with our most recent release.  The team has created a new video series which is focused on helping new users get started with the project and for existing users to gain a deeper understanding of SwitchYard features and capabilities.  There are three guiding principles for the series:


  • Live Action : each video provides a live demonstration of a SwitchYard concept or feature.  The idea is to complement the documentation through live action and provide additional context where it's needed.  (N.B. : we violate this rule in the very first episode which is more of a trail map than a demonstration).
  • Informal : to a certain extent, quantity is better than quality here.  We're gonna make them useful, but we won't spend much time doing 1000 takes or polishing the videos in post-production.  That said, I have submitted an expense request for celebrity cameos in the videos.
  • Community-Focused : we belted out six videos right away based on what we thought might be useful.  Where we go from here is something we would like our community to decide.  If you have burning questions or areas where you feel a demonstration would really add to the documentation, please let us know in the forums or file a JIRA.  Here's an example request.


All of the videos can be found on the SwitchYard Video Series page.  Here's one of the videos in the series to see what they are all about:


I'm a bit late with this blog entry as I wanted to put the finishing touches on our new video series before announcing the 0.7 release.  More on the video series in the next blog post. :-)  As for 0.7, we are aiming at quicker release cycles heading toward our 1.0 release, so expect a new one every 6-8 weeks.  We lost a bit of time due to the Red Hat holiday break, but still managed to resolve 85 issues over eight weeks.  As always, the SwitchYard Release Overview is available for 0.7 with all the juicy details.



The SwitchYard Team

SwitchYard 0.6 has gone final and is stuffed like a Thanksgiving turkey.  The issue bucket for 0.6 was a veritable horn o' plenty, with 157 issues resolved over the course of the release.  Here's a sampling of the features:


  • Security policy now supports pluggable authentication providers with PicketLink and PicketBox integration out of the box.
  • Transaction policy definitions for starting a global or local transaction around a service.
  • Transaction policy on service references allow you to declare whether a transaction should be propagated or suspended on invocations from your services.
  • Clustering of SY instances.
  • A remote service invoker.
  • A ton of work around improving the visual editor and adding support for new features in 0.6.
  • Added a RESTEasy gateway.
  • Added a vanilla HTTP gateway.
  • Added dynamic operation selectors which allows the service operation to be derived from message content/context.
  • Operation-level drill down for service monitoring.
  • Enhancements to the rules and bpm components around fact insertion and event notification.
  • Easy peasy deployment and testing of quickstarts.
  • Improved Camel integration in core and test framework.


If you'd like to learn more, check out the latest edition of our critically acclaimed Release Overview series for details, examples, and links to additional information.



The SwitchYard Team

We are now feature complete and (hopefully) bug fix complete for the SwitchYard 0.6 release.  The big difference between Beta1 and Beta2 is the introduction of clustering.  Transaction policy also got even more powerful as you can now specify transaction policy for service references (e.g. suspend a transaction when a service is invoked from your transactional service).  There were 50 issues resolved between Beta1 and Beta2, so plenty of bug fixing and minor enhancements in there as well.  Check out the Release Overview page for more detail.


No further work is planned for 0.6 pending feedback and issue reporting from the community.  If no issues surface, 0.6.0.Final will be out in 7-10 days.

Looks like the SwitchYard presentations from JUDCon Boston are now available.   I posted the slides to the blog some time back, but the video helps fill in the blanks and also includes live demo action.  If you want to see the absolute latest and greatest, check out the SwitchYard session during JBoss Integration Week tomorrow at 1:00pm ET.


Future of the Enterprise Service Bus at JBoss



Enterprise Services Made Easy with SwitchYard


The team has been banging away on 0.6 and the end is nigh.  Here's a quick look at the features available in 0.6 Beta1:


  • Security policy now supports pluggable authentication providers with PicketLink and PicketBox integration out of the box.
  • Transaction policy definitions for starting a global or local transaction around a service.
  • A ton of work around improving the visual editor and adding support for new features in 0.6.
  • Added RESTEasy gateway
  • Added a vanilla HTTP gateway
  • Dynamic operation selectors
  • Operation-level drill down for service monitoring
  • Enhancements to the rules and bpm components around fact insertion and event notification
  • Easy peasy deployment and testing of quickstarts
  • Improved Camel integration in core and test framework
  • More bug fixes than you can shake a stick at


We started the typical Release Overview page for 0.6, but it's still a work in progress.  Definitely check it out for more info and updates as we move closer to 0.6 Final over the next couple weeks.

SwitchYard had a good showing at both JUDCon and JBoss World this year.  Our presentations were well received, feedback was tremendous, and all of our live demos worked. :-)  If you weren't able to make it this year or you want a refresher, here's the collection of SY presos:


The Future of the Enterprise Service Bus at JBoss

Tom and I gave a talk on what we're up to with JBoss ESB and SwitchYard, where things are headed in the future, and tips on how to make the transition.


Enterprise Services Made Easy with SwitchYard

An introduction to SwitchYard with a healthy amount of show-and-tell.


SOA at Scale with SwitchYard

An examination of the different elements of scaling an enterprise application (it's about more than runtime performance) and how SwitchYard can help.


The first two sessions were recorded via video camera and the last was recorded via screen capture.  I haven't seen the videos posted yet by the production team, but hopefully that will go up soon.  All three sessions had demos and cheesy jokes and it's just not the same if you can't watch/listen to those while looking at the slides. 

The wheels managed to stay on the cart after a couple weeks in Beta so it's time to cut 0.5.0 Final.  Key features for this release include a mammoth tooling upgrade with a visual application editor, support for declarative security policy, and a bunch of new gateway bindings.  All told, there were 139 JIRAs resolved as part of this release, which I think makes it our biggest in the history of the project.  Maven artifacts have been deployed, bits are up on the downloads page, and the documentation has been updated.


All the juicy details can be found in the SwitchYard 0.5 Release Overview, which contains a list of all the new features with pointers to examples, documentation, and such.  Take a look and see what it's like to live large with SwitchYard.



The SwitchYard Team

Keith Babo

0.5 Beta 1 is out!

Posted by Keith Babo Jun 27, 2012

0.5 Beta 1 bits have been posted to our Downloads page.  There are 113 issues resolved in 0.5 (so far).  I'm working on a revamped Getting Started guide and Release Overview for 0.5 Final, which should drop in a couple weeks.  In the meantime, this is a great time to kick the tires and help us improve things for Final.  Here are some useful links:



Lots and lots of stuff in this release, but I would have to say that our new visual application editor makes the biggest impact. 






We've received some great feedback at JUDCon this week and we're looking forward to people trying the Beta build and giving feedback that we can fold into 0.5 Final and 0.6.  So please get your hands dirty and let us know what you think!

This post provides a brief introduction to Switchyard, what it is, and how to use it to build a service-oriented application.


This post also provides a hands-on introduction to the new SwitchYard graphical editor. We’ll build an application from scratch, but our focus will be on the tools that SwitchYard provides you, and not on the business logic of our application.


(Please note, that this post was written with the "nightly" build of Switchyard 0.5 in June 2012. The eclipse based tooling introduced in this post will be released in version 0.5 of SwitchYard.)



The post is divided into 10 sections. Let’s get started in the first section with a question, actually a few questions.



Section 1: Starting with a few Questions



Just what is Switchyard? Is it another Enterprise Service Bus (ESB)? How can I use it? Better yet, why do I want to use it? And, did I mention that I’m in a hurry? Don’t waste my time - I’ll give you 15 minutes to get me the answers.



The top level page at http://www.jboss.org/SwitchYard defines SwitchYard as:


‘...a lightweight service delivery framework providing full life-cycle support for developing, deploying, and managing service-oriented applications...’



Hang on for a minute! That’s a pretty heavyweight sentence for a lightweight framework.  Let’s dissect that sentence into smaller bites to see if we can better understand SwitchYard:


  • Service-oriented applications - OK, we’re talking about Service Oriented Architecture or “SOA.” In this type of architecture, we want to design our applications around performing discrete services. Each service performs one or more functions. The services, which can be local or remote,  communicate by delivering messages between each other and to and from external applications. But, SOA has been around for a while and it is supported by several large frameworks and products. What makes SwitchYard so different? 


  • Lightweight service delivery framework - How lightweight is it?  For other frameworks, your main task can be redesigning (shoehorning?) your application to fit the form that the framework needs. In other words, the most important element is where your service runs. SwitchYard is different and lightweight in that it enables you to better focus on the task that you want your service to performed. SwitchYard achieves this through its modular design   - instead of “plugging” your service into a standardized “plug” in the whole framework, SwitchYard enables you to embed only those pieces (services) of the Swithyard framework that your service needs. It’s like a cafeteria, you pick only what you want.


  • Providing full life-cycle support - Let’s take each of these next three subjects separately:


  • Developing - What kind of support do you need when you are developing an application? Well, you will want to work in an IDE such as eclipse, so some wizards to create new projects and services would be nice, but what else? How about tooling to help you to create new projects and automatically set up all the framework services (for example, CDI/Bean Services, BPM Services, Rules Services, or Camel Services) that your application needs? SwitchYard uses JBoss Forge (https://docs.jboss.org/author/display/FORGE/Home) to do this. We’ll walk through an example later in this post.


    • Deploying - Applications really don’t do very much until you get them onto a server where they be run. SwitchYard applications can be hot-deployed and the SwitchYard eclipse tooling supports deploying your applications to your servers, and starting, stopping and managing those servers. And, SwitchYard full supports the new JBoss AS7 server.


    • Managing - Once you have your application deployed, you have to be able to keep an eye on and keep it out of trouble. SwitchYard includes a new web-based management console for you to manage applications, services, and the server itself.



Section 2: What About JBoss ESB?



So far so good, but if we’re talking about a JBoss framework for SOA, aren’t we talking about JBossESB? Does SwitchYard mean that JBossESB is dead?



No, JBossESB is not dead. JBossESB is alive and well. A new update (version 4.11) scheduled for this week. The community is growing and as vibrant as ever. There’s even a beautifully written new Beginner’s Guide  (http://www.packtpub.com/jboss-esb-beginners-guide/book). (Full disclosure, I’m one of the books authors.)



Well, if JBossESB is not going away, If I want to build a new SOA application starting today, should I use ESB or SwitchYard?



The answer to this question is, “it depends.”



At this point in time, SwitchYard is very much a work in progress. It’s design and implementation are evolving and will evolve significantly in the future months as it grows toward its 1.0 release. JBoss ESB is more mature, and is undergoing primarily incremental changes and improvements.



So, if you are building an SOA application that you want to go into production in the near future, you should look at JBoss ESB. Actually, if you need enterprise level support, you should really buy a subscription for the JBoss SOA Platform (http://www.redhat.com/products/jbossenterprisemiddleware/soa), which has at its core JBoss ESB.



For the longer term future, you should look at some of the ways in which SwitchYard will make some aspects of SOA application development easier.



Section 3: Making Your SOA Life Easier with SwitchYard



The primary ways in which SwitchYard differs from a traditional ESB highlight some of the ways in which SwitchYard can make SOA application services development easier:


  • Install only the Services that you Need - One drawback of a traditional ESB is that while you may only want to use some services provided by the ESB (for example, data transformation), you have to deploy the ESB’s entire framework, including services that you don’t need. The result is a larger installation footprint (both memory and disk usage) that would be necessary if you could use only the ESB services that you require. In contrast, SwitchYard enables you to configure and then utilitze only those services that you want.


  • Run your Services Anywhere you Want - Another aspect of a traditional ESB is just where it enables you to run your services. With an ESB, you deploy your services into the ESB. Part of the logical visualization of an ESB mirrors that of a hardware bus in that you “plug” your services into the bus. Your services communicate via messages sent over the bus. The messages sent over the bus are said to be “ESB-aware” in that they conform to the message format required by the ESB. Messages are “on-boarded” from external sources to the ESB through adapters that translate the message formats into ESB-aware messages. In contrast, SwitchYard lets you run your services in your own application, inside unit tests, or deployed to your own application server.


  • Focus on Writing your Services’ Code, Not the Code to get your Services to Run - One of the most helpful features of JBossESB is the extensive library of predefined actions that it provides. These “out of the box” (OOTB) (see: http://soa.dzone.com/articles/works-great-right-out-box)  actions perform tasks such as message routing, business process management integrations, integrations with scripting languages, and others. One advantage that using these OOTB actions should appeal to your interests in building reliable services. If you had to construct your services only using new new code that you create, you would have to debug and test that code thoroughly. The OOTB actions have already been thoroughly tested and documented by the JBossESB community, so you can use them with confidence. Another advantage should appeal to your lazy programmer interests. By using the OOTB actions, you can build reliable services without having to write that much new code. This model, however, reaches its limits with some operations such as message transformation. With JBoss ESB, the transformation of data fro one form to another is a procedural operation. SwitchYard, however, supports declarative transformation, where all you have to do is to define the transformation and the types to which you want it performed, and Swithyard does the rest.


  • Compose your Services with CDI - With traditional ESBs, you have to adapt your service design to fit the form that the ESB wants. In contrast, SwitchYard uses Context Dependency Injection (CDI) provided by the JBoss Weld (http://seamframework.org/Weld) project to enable you to easily create services from Java beans through annotations. You can convert a bean to a service just by adding the @Service annotation. When it sees this annotation, SwitchYard registers them as services at runtime. Within a service, references to other services can be injected as other CDI beans with the @Inject annotation.


  • Take Advantage of Integrations - One of the great strengths of JBossESB is its rich set of integrations with other technologies such as jBPM (http://www.jboss.org/jbpm) for business process orchestration. SwitchYard carries on that tradition and expands JBossESB’s integration with Apache Camel (http://camel.apache.org). With Camel, SwitchYard enables you to use Camel components (http://camel.apache.org/components.html) as gateways to integrate applications and services with your services.


  • Forge Ahead, with Forge - Sometimes the hardest thing to do is to start a new project. Copying an existing example is a common route, but you end up having to edit files to match your new application and services. SwitchYard ships with built-in Forge (https://docs.jboss.org/author/display/FORGE/Home) plugins to help you to build Maven (http://maven.apache.org/) based applications easily.


  • Testing, and Not as an Afterthought - As a QE engineer, it can sometimes seem like testing is never a primary concern when a new technology is introduced. (Or maybe it’s just that when you spend your days finding bugs, you develop a certain form of paranoia.  ;-) SwitchYard includes unit test support out of the box, so you can build tests for your services while you build the services.



Section 4: Visualizing SwitchYard?



It’s easy to visualize an ESB. You just think of a bus with services “plugged” into it. But what about SwitchYard. What does SwitchYard “look like?”




An ESB, and in this context, SwitchYard is an ESB, is really a means to an end. It’s a tool for creating service-oriented applications. To create a service-oriented application you look inward at your application architecture, not outward at the runtime architecture of the bus. Your concern and your focus in on the application that you’re building and not on the runtime and tooling. SwitchYard is the tooling and runtime for your service-oriented applications.



It’s a little more difficult to draw a picture of SwitchYard, as one of its main goals is to enable you to focus on what your application looks like!



The contents of a SwitchYard project however do have a different configuration than JBoss ESB project. We’ll take a look at these differences next.



Section 5: Anatomy of a SwitchYard Project Configuration



Unlike traditional ESBs, the configuration requirements imposed by SwitchYard are minimal. Let’s use JBossESB as reference point. A service-based application deployed to JBossESB requires configuration files to define the JMS topics and queues on which it depends. It also requires a “jboss-esb.xml” file to define the resource providers (such as JMS) on which the services depend, the services themselves, the gateways through which messages are “on-boarded” to the ESB and the notifiers through which messages are sent off of the ESB, and the “pipeline” of actions that perform the tasks that comprise the services. Creating and maintaining a jboss-esb.xml file for a services-based application can be a difficult and time-consuming task.



A SwitchYard application has two primary configuration files:


  • beans.xml - This file simply indicates that an application is making use of Context Dependency Injection (CDI).
  • switchyard.xml - This file defines the service implementations, gateways, transformations, validations, and deployment dependencies.



At first glace, this may seem like a trivial change from jboss-esb.xml to switchyard.xml. What’s the big deal, only the file name changed, right?



The major difference is that the elements defined in switchyard.xml conform to the OASIS Service Component Architecture Assembly Model Specification (http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-spec-v1.1.html). The Service Component Architecture (SCA) model provides standards for building SOA applications.



Why was this standard selected as the lingua franca of SwitchYard configuration? What advantages does using this standard give us? There are multiple levels of advantages:

  • SwitchYard wanted to get away from the model followed by jboss-esb.xml where the service implementation details are closely tied up with the gateway definition details. We're trying for a more modular approach that makes it easier to define and maintain a service's configuration. A switchyard.xml can contain binding info in the same file as the service implementation, but SCA also supports recursive composition, so that one service with just implementation details, can be included inside another. This level of modularization is not possible in JBoss-ESB.xml. We’ll take a look at the SCA files and pictures that Swithyard tooling makes easy to create and maintain.
  • SwitchYard also wanted to make service interface (or the service "contract")  information more explicit, and therefore easier to find.  JBossESB  does this  to some extent with EBWS  (ESB enhanced Web Services).
  • Finally, the SwitchYard team had a choice.  They could create  a new  configuration syntax, or they could try to use something that already existed, was an accepted open standard, and was supported by a vibrant community.  Not A tough choice.  ;-) Also, SCA is a well-known model for service-oriented applications. But, it's important to not get too hung-up over the underlying configuration model. The capabilities that the model makes possible, such as modularity, are more important. And, another reason to not worry too much about the configuration model is that SwitchYard provides you with tools such as Forge scripting (and someday soon a SCA editor) to make it easier to create and maintain services' configurations.



It’s also important (as we’re all lazy programmers who want to avoid error-prone manual tasks, after all) that SwitchYard provides tools to automatically populate the contents of switchyard.xml. We’ll see these tools in action in a bit.



Section 6: Services



When we talk about SwitchYard services, we're concerned with how we can create a service, and then how that service can be used (or "consumed") by other services.



How exactly do you create a SwitchYard service? Watch closely because SwitchYard makes this simple:


  • You start with a Java POJO (plain old Java object) and add a “@Service” annotation.
  • The you create a Java interface representing the “contract” (in other words, the signatures of the methods used to interact with the with that object)
  • Then you create a Java class implementing the interface

And that’s all folks. You’ve got a service. Yeah, SwitchYard tries to keep this simple.


Here’s an example (thanks to Keith Babo - as I’m borrowing this code from his demo):


1) Start with a POJO:


public interface OrderService {

    OrderAck submitOrder(Order order); 



2) Create an interface:


public class OrderServiceBean implements OrderService {    

    public OrderAck submitOrder(Order order) {





3) Annotate the POJO - and it’s a service!



public class OrderServiceBean implements OrderService {


    public OrderAck submitOrder(Order order) {





Once you have a service, how do you access/consume it? Through Context Dependency Injection (CDI) in three more steps:


(1) Add an @Reference and @Inject annotation

(2) Add a field representing the consumed service

(3) Invoke methods on the injected reference



public class OrderServiceBean implements OrderService {


@Inject @Reference   (1)

private InventoryService inventory;  (2)


    public OrderAck submitOrder(Order order) {

        Item orderItem = inventory.lookupItem(order.getItemId());   (3)




What types of services does Switchard support?

  • Bean Services - Such as the example we just mentioned.
  • BPM Services - Where bean services can be invoked from a BPMN2 process.
  • BPEL Services - Where you can access WS-BPEL business processa exposed as services through their WSDL inteface.


  • Camel Services - Camel enables you to integrate systems together, even if they each a speak a different API. Camel provides a flexible message routing and mediation engine (in this context, “mediation” refers to the processing of messages, for example examining or modify message contents on the fly). Camel supports a large set of “components” (http://camel.apache.org/components.html) that enable you to tie together technologies such as EJBs, with transports such as http or ftp, messaging, and many others. SwitchYard uses Camel as a Swiss Army knife sort of framework to perform many tasks by re-using Camel components, instead of having to write the integration code yourself.



At this point, let’s switch into to a hands on mode and perform some tasks with SwitchYard.



Section 8: Getting SwitchYard



When I first started working with JBoss software, I asked a co-worker, how do I perform an installation? His response was a blank stare for a few seconds, after which he said, “You download the .zip and unzip it.”



It might sound trivial, or obvious, but the ease, and low entry cost (you can’t get cheaper than free!) with which you can get started using JBoss projects is a great feature. You can download whatever projects you want and try them out at no cost.



To get a copy of SwitchYard, the steps you have to do are:



Go to this page: http://www.jboss.org/SwitchYard/downloads - you’ll see a display similar to this:




Your download choices are:


  • SwitchYard Tools - These are Eclipse plugins that support operations for working with SwitchYard projects. We’ll talk about how to install and use these plugins in a later section of this post.


  • SwitchYard Source Distribution - Like the name says, download gets you all source code for SwitchYard.


  • SwitchYard Installer - This distribution contains all the bits you need to deploy SwitchYard to a JBoss AS7 server. But, since we’re in a hurry, we’ll use the next one.


  • SwitchYard AS7 Distribution - This distribution is the easiest to use as it includes SwitchYard deployed to a full JBoss AS7 server distribution. All we have to do to use this distribution is to download it and unzip it.



For the purposes of this impatient discussion, we’ll use the SwitchYard AS7 Distribution.



Section 9: Running SwitchYard and the JBoss AS7 Server



The JBoss AS7 (http://www.jboss.org/as7) server is JBoss’ newest application server release. AS7 is compliant with the Java Enterprise Edition 6 specification, and is the preferred deployment platform for SwitchYard.



(Note that by the time you read this, SwitchYard 0.5 will probably be available as a download.)



To install the SwitchYard AS7 Distribution, simply select a directory where you want to run the server, and unzip the http://downloads.jboss.org/switchyard/releases/v0.4.Final/switchyard-as7-0.4.0.Final.zip file into that directory.


In this post, we’ll use the /opt/SwitchYard directory:


mkdir /opt/SwitchYard

cd /opt/SwitchYard

unzip switchyard-as7-0.4.0.Final.zip



Let’s jump right in and start up the server:



cd  switchyard-as7-0.4.0.Final/bin

sh ./standalone.sh



After a very short time (Did I mention how fast JBoss AS7 is? It starts up and runs very quickly!), you’ll see logging messages that look like this that indicate the server is up and running:



23:05:13,608 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http--

23:05:13,718 INFO  [org.jboss.as.connector] (MSC service thread 1-5) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)

23:05:13,775 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) Bound data source [java:jboss/datasources/ExampleDS]

23:05:14,173 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /opt/local/SwitchYard/SwitchYard-as7-0.3/standalone/deployments

23:05:14,192 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.2.Final "Arc" started in 2137ms - Started 97 of 152 services (55 services are passive or on-demand)



Section 10: Creating a New SwitchYard Project From Scratch



Now that we have SwitchYard running, let’s create a new project. We’ll do this the easy way and take advantage of some new JBoss eclipse-based tooling, the SwitchYard Graphical Editor. Note that as of this writing, the editor has not been released. It will be released in SwitchYard 0.5



First, we need to install a few things:



  • JBoss Tools - JBoss Tools (http://download.jboss.org/jbosstools/updates/development/indigo/) is a great collection of development tools, all packaged and tested together. We’ll want to install JBoss Tools to get JBoss AS support tools such as a server runtime detector. The tools that we want to install are packaged as “JBoss Tools Abridged.”






Once all the tools are in place, we can create a new SwitchYard project. Before we do that, however, let’s think about the application that we want to build, and the steps that we have to perform.


The application exposes a simple web service implemented in a Java bean. The service accepts a string, and prefixes the world “hello” to it. That’s right, if we pass the word “world” to the service, it returns “hello world.” We’ll access the service by sending it a SOAP message. For our “client,” we’ll use soapUI (http://www.soapui.org/).



The function performed by the application is not the important thing. What’s important is how you can build it with the SwitchYard tooling, especially the new SwitchYard graphical editor.



The major steps that we’ll perform are:


  • Create a new SwitchYard project, configure the project with the bean and SOAP facets. We’ll need these facets to support the bean where we implement the web service and for the SOAP access to the service.
  • Create a composite service
  • Then create the component service, including the service interface and implementation bean.
  • Connect the composite service to its component service.
  • Create the SOAP binding for the service.
  • Add a transformer to convert the messages from between SOAP XML to a String that the service can manipulate.



OK, let’s begin!


Note: This article was originally written in July 2012. The following sections are an update to the article using the latest release (0.7) of SwitchYard as of March 2013. The UI has changed and improved a great deal since July 2012. The screenshots that are used in the following sections reflect the current (0.7) UI.


The steps that we'll follow are:

  • Create a new SwitchYard project
  • Create a bean component, and in the course of doing so, create its contract (interface)
  • Fill in the business logic of the bean and the details of the contract (interface)
  • Promote the service so that it is visible as a web service, and in the course of doing so generate the service's WSDL, and create the necessary transformations
  • Create a SOAP binding
  • Deploy the service
  • Invoke the service


Let's take these steps one-by-one:


Create a new SwitchYard project


To create a new SwitchYard project, select File->New->Project->SwitchYard->SwitchYard Project



We can accept most of the default settings for this project, the  exception being that we have to set the bean and SOAP facets:



When the new project wizard completes, we access the new SwitchYard graphical editor by double-clicking on the SwitchYard icon in the project explorer:


And the editor is opened.



The editor consists of:


  • The canvas (displayed in blue on the left of the screen) - The canvas is workspace where you create and manipulate project elements.
  • The palette (displayed on the right margin) - The palette contains the elements that you can add to your project.


Create a bean component, and in the course of doing so, create its contract (interface)


To create a new bean component, select the Bean implementation icon from the palette and drag it onto the canvas. The Bean definition dialog opens:



To create the corresponding contract (interface) click on the blue "Interface:" text and this dialog opens:




After we select "Finish" to save the definition, we see the bean component on the canvas:




Fill in the business logic of the bean and the details of the contract (interface)


At this point, we need to fill in the code for the bean and its interface:






Promote the service so that it is visible as a web service, and in the course of doing so generate the service's WSDL, and create the necessary transformations


Next, we promote the service to make it visible (right-click on the service's green icon):




We want to make the service visible as a web service, so we'll select WSDL as the interface type - and the UI will generate a WSDL for us, based on the contract (interface) that we defined earlier:





Note that we selected to not use wrapped messages, so that our transformations can access only what is inside the elements they receive.


Our service has to transform data between objects and strings, so we next have to generate transformations:



Our (Java) transformers are quite simple:



We're almost done!


Create a SOAP binding


Now, we create a SOAP binding:



Note that you can always view/edit the binding after it's created by accessing its properties:





OK. It’s time for action. Let’s deploy our application:



And fire up soapUI, we can easily create a request by accessing the deployed service’s WSDL:





And there it is, the output from our very small SwitchYard service.


Section 11: What’s Next?



Well, that’s a brief (impatient) introduction to Switchyard, where to get it, how to install it, and how to build a service from the bottom up. What’s next? In a followup post, we’ll take an in-depth look at the services Switchyard provides by examining some of the SwitchYard quickstarts in detail.


There are a number of great demos of SwitchYard available at the SwitchYard video channel - check it out!   https://community.jboss.org/wiki/SwitchYardVideoSeries






I’d like to thank Keith Babo, Tom Cunningham, Rob Cernich, and Brian Fitzpatrick for their (never impatient) review comments and suggestions on writing this post!


Filter Blog

By date:
By tag: