4:14 a.m.
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