5 Replies Latest reply on Apr 22, 2013 5:45 PM by Rob Cernich

    SwitchYard Applications


      We are building an application that will leverage SwitchYard.  We've started off by splitting our project up as follows:















      Currently the two SwitchYard projects have the model project as a dependency.  We're accomplishing this by building the model classes into the switchyard project's JAR files and then deploying those JARs.  Is there a more appropriate way to bundle a utility JAR for a switchyard project? 


      We are also interested in composing services across multiple switchyard projects, e.g. myproject-switchyardproject2 may use Service1b from Service2.  I've attempted to do this by adding myproject-switchyardproject1 as a provided dependency for myproject-switchyardproject2 and modifying the switchyard.xml in myproject-switchyardproject2 to reference the classes defined in myproject-switchyardproject1, but am not having much luck.


      What approach have people been taking to assemble multiple module applications?  Are you bundling it into a EAR/WAR?  If so, can each module be built into a JAR and then somehow load multiple switchyard.xml files from those JARs included in the EAR/WAR bundle?  Or would the EAR/WAR have one giant switchyard.xml file that composes the services?


      I've looked at the multiApp and orders quickstarts, but they seem to be referencing external module dependencies through guvnor.  Is this required?


      Please forgive me if these are bad questions, still getting my bearings with this model.

        • 1. Re: SwitchYard Applications
          Rob Cernich Master

          Hey Anders,


          I haven't tried bundling a SwitchYard application within an EAR, but I can help with the multiApp example.  The critical piece of information that is used to resolve dependencies at runtime can be found in the manfiests of the jars.  Here's a link to one example:  https://github.com/jboss-switchyard/quickstarts/blob/master/demos/multiApp/order-consumer/pom.xml#L109


          The example uses Guvnor, but you could use whatever mechanism you like to resolve dependencies during your build (e.g. Maven).  To make sure they are resolved in the engine, you will need to add the appropriate entries to your jar manifests (as in the example above).


          You can find a more detailed explanation about dependency resolution in AS7 here: https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7


          Hope that helps,


          • 2. Re: SwitchYard Applications

            Thanks Rob!


            We are using maven and am able to get the build time dependencies setup just fine.  It's running in the container that seems to be giving me a bit of trouble.  I attempted to setup the manifest to access Service1b which lives in  myproject-switchyardproject1 from within Service2 which lives within myproject-switchyardproject2, but don't seem to be having any luck.  I think I may be configuring the switchyard.xml incorrectly.  In the example you reference it's adding an artifact reference using a Guvnor URL.


            I had found that AS7 documentation, but it only seems to reference classpath resolution of deployed modules.  How are folks adding utility JAR dependicies for SwitchYard applications?  Are you just rolling dependent classes within the deployable JAR as we're doing currently?  Or are you making utility JARs SwitchYard components with no services so they can be deployed? 


            This is what made me wonder if it would be better to package the overall application into a single deployable component such as an EAR.  Then the EAR\lib folder could contain the utility JAR's shared across the SwitchYard applications.  However, it's not clear to me if a SwitchYard application can be an EAR module like a WAR, or EJB is?  Or maybe I'm better off not using SwitchYard applications directly and building a WAR with the org.switchyard.deployment.WebApplicationDeployer as specified on https://docs.jboss.org/author/display/SWITCHYARD/Deployment .  However, then I think I'm back to a single switchyard.xml file for all the components of our application. 


            Can a switchyard.xml file include other switchyard.xml files so that they can be broken up?


            Maybe what I'm trying to do can't be accomplished in this version of SwitchYard?  https://community.jboss.org/message/802588

            • 3. Re: SwitchYard Applications
              Keith Babo Master

              One thing to keep in mind here is that the artifact reference in switchyard.xml is purely for documentation purposes and has no impact on runtime resolution of dependencies.  We use that artifact info in the admin code (e.g. admin console) to display information on dependencies as a guide for the user.


              What you need to do for runtime resolution of dependencies is to add a manifest entry in your application deployment which defines a dependency on another deployment in AS 7.  The line that Rob referenced above in the application pom.xml adds such a manifest entry to the application's jar.  This is a distinct concept from maven dependency resolution at build time.  A <dependency> in the pom.xml will take care of dependency resolution during build time.  A manifest entry as described by Rob above will take care of dependency resolution at runtime in AS 7.  All deployments in AS 7 are modules, so one deployment can depend on another.


              Based on what you're asking for, I think you want three deployments:


              model.jar -> this contains all your shared classes

              switchyardproject1.jar -> contains some services and declares a manifest dependency on deployment.model.jar

              switchyardproject2.jar -> contains some services and declares a manifest dependency on deployment.model.jar

              • 4. Re: SwitchYard Applications

                Thanks a ton for the feedback.  Based on your input I've made significant progress.  Here is what I've learned:


                1. As noted, by specifying the deployment.model.jar I'm able to get the two switchyard components to depened on the model dependency.
                2. To communicate across the two switchyard projects, e.g. switchyardproject1 use a service from switchyardproject2, the project should be added as a dependency, but also needs to live in the same targetNamespace.  Since the targetNamespace is not supported on the sca:reference (https://community.jboss.org/thread/215559), I simply specified the same namespace at the switchyard/composite level.


                A couple open questions:


                1. If I try to set the contextPath the same on switchyardproject1 and switchyardproject2 I seem to run into a race condition and hit a NullPointerException in org.switchyard.component.resteasy.InboundHandler#start.  I say race condition, b/c if I put a breakpoint at the begining of this method and start in debug mode everything starts fine.  However, if I start normally it appears it attempts to initialize both components at the same time and fails.  Our hope would be that all the SwitchYard REST endpoints live on the same contextPath.
                2. Ultimately we would like to bundle all the components into a single application for deployment.  From what I've gathered on other threads, e.g. https://community.jboss.org/thread/177232 and https://community.jboss.org/thread/222416 we need to stick with deploying each JAR independently still.  I attempted to add my modules that were working indpendently into an EAR and updated the Dependencies to include the EAR path, e.g. from deployment.model.jar to deployment.myear.ear.model.jar but it didn't seem to work.
                • 5. Re: SwitchYard Applications
                  Rob Cernich Master

                  Hey Anders,


                  For your ear deployment, did you try specifying the relative path the jars, e.g. model.jar?  Also, based on the AS7 docs, by default, everything in the lib/ folder of the ear should be accessible to all the modules in the ear, so you might try dumping model.jar into lib/.


                  Not sure if that helps or not.