Hey Gary,

This should be relatively easy.  SwitchYard uses ServiceLoader to load its components, which includes the component providing support for SOAP bindings.  This could be as simple as swapping out the supplied SOAP component with your own.  For a reference, check out org.switchyard.component.soap.deploy.SOAPActivator (in the SwitchYard SOAP project), which is loaded and referenced from org.switchyard.deploy.internal.Deployment.createActivators() (in the SwitchYard deploy project).

Hope that helps a bit,

Rob

In Savara I would like to be able to generate a switchyard app, representing the expected behaviour of a service, and then once the implementation details have been filled in by a user, simulate the app against a scenario (equivalent to a sequence diagram with example messages).

We definitely want to support this use case. There are a couple of different layers here.  First, you should be able to use SwitchYard core to handle the basic wiring for the app, including registering services which will sub in for those offered via bindings.   After that, you have a need to process part of the SwitchYard application config in the runtime (e.g. to load implementation services) but you don't want bindings to initialize, as you will have substitute/mock handlers for those bindings.

I have currently experimented with Tuscany for a pure SCA approach, where I provide an alternative implementation of the SOAP binding component as a means of supplying inbound messages, and intercepting outbound messages - so no external communications are actually involved.

 

However the downside of this approach is that (in Eclipse) I need to selectively include particular required Tuscany jars.

 

I would like to provide the same functionality for switchyard, but am hoping there is a better way to fool switchyard into interacting with the embedding environment (i.e. the simulator) rather than actually making web service calls.

This should definitely be possible.  I'm guessing there may need to be a tweak or two here and there, particularly in the deployer code to allow for selective initialization.  Best way to move forward is to provide a sample application, a description of what you expect to happen, and then we can hack something together.

One approach would be to do something similar to the tuscany experiment, providing my own 'soap' binding component and replace the current jar. Another approach would be to modify the soap binding code to have an internal interaction mode.

 

However I was wondering whether it would be possible to have a more general configurable mechanism that could overwrite the implementation of components referenced within a switchyard.xml - so when starting switchyard in an embedded environment, the overridden components would not be initialized, and when messages were routed to such a component, they would be handed off to an alternative implementation instead? So only the implementation is affected, all of the definitions (schema/model) would be reused.

I think we can come up with an approach here that doesn't require changes to the component.  As Rob mentioned, ServiceLoader could be used to pick up an alternate implementation.  Another way I'm thinking about going is adding an option to pass in a specific set of activators.  We could still use ServiceLoader to discover activators, but that code would live outside the domain implementation and would supply a list of activators to the domain at construct/init time.  This should make it reasonably straightforward to use existing activators for implementations (stuff you want to test) and replace activators for any bindings (stuff you don't want to test).

So let's start with an example app and hammer this out!  :-)