[switchyard-issues] [JBoss JIRA] (SWITCHYARD-629) Switchyard Application simulation support

[Gary Brown (JIRA)]

Gary Brown created SWITCHYARD-629:
-------------------------------------

             Summary: Switchyard Application simulation support
                 Key: SWITCHYARD-629
                 URL: https://issues.jboss.org/browse/SWITCHYARD-629
             Project: SwitchYard
          Issue Type: Feature Request
            Reporter: Gary Brown


Would like to simulate switchyard applications from within Savara, using a scenario (i.e. sequence diagram) with example messages. The tooling will primarily be used from within Eclipse, although can also be used outside this environment.

To support enhancements and additions to switchyard, would prefer to point the Eclipse environment at an external installation of switchyard - i.e. so the user is not dependent upon a single version of switchyard bundled with the Eclipse plugins. Reason for mentioning this, is that selective classpath (to not include bindings) is not going to be easy with this approach, as it would require the user to configure their environment with knowledge of which jars to select.

The aim would be to have a component that I could initialise with a switchyard.xml, with any relevant classes/resources being in the classpath. Reason for specifying the location of the switchyard.xml, rather than just picking up from classpath, is that the simulator may be simulating more than one switchyard application at the same time (i.e. different apps playing different participants within a choreography - simulating the end to end business transaction).

The only difference from normal initialisation is that the bindings should not be initialised, and instead would interact with this simulation component, so inbound messages would be provided by the simulation container, and messages sent by the switchyard application would be received/handled by the simulation container. Each component instance should be a separate switchyard environment, to avoid conflicts with other components running different switchyard apps, and should support a 'close' method to tidyup its environment - i.e. its possible a session may be terminated mid way, if the scenario represents just a partial transaction. It would also be useful to be able to determine that a session was still active, to know further messages are expected.

For simplicity the component could provide a synchronous invoke method, that takes the message and an optional name that can be used to specify the source binding (where multiple have been defined), but if not specified and only a single source binding, then the message should be routed as if it came from that source binding. If no name is defined, and multiple possible bindings exist, then an exception should be thrown.

A callback interface should be provided that will be invoked to handle external service invocations (i.e. that would normally be routed via a reference binding). This interface should offer one-way and request/response variations, and supply the outbound message and the target binding name.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira