4 Replies Latest reply on Mar 21, 2013 4:32 PM by kcbabo

    Support for (REST) Subresource Locators / Dynamic Dispating in Switchyard?

    marco.rietveld

      Hi,

       

      I'm wondering if switchyard supports subresource locators? And if so, how would I configure that? (Some RestEasy documentation about them: link)

       

      In general, advice on how to do the following would be great!

       

       

      In my case, I have a rest service that would work like this:

      http://server.address/{domain}/{operation}/startTask/{id}

       

      With regards to my code, I'd have a DomainResource class that would return an OperationResource that then has a startTask method for that URL segment.

       

      Thanks,

      Marco

        • 1. Re: Support for (REST) Subresource Locators / Dynamic Dispating in Switchyard?
          kcbabo

          Hey Marco,

           

          I understand what you are trying to do from a plumbing perspective, but can you give us an idea of the higher level use case here?  What kind of service is this that you are trying to expose and what do you expect it's contract to be?  Reason I ask is that signaling a BPM process is already functionality that's built into the BPM container in SY.  You can expose service operations which map to start, signal, abort inside a jBPM process instance.  It's just a matter of configuring your BPM implementation properties, so you don't have to push these details out to the REST layer.


          You can find some info on the BPM component in SY here:

          https://docs.jboss.org/author/display/SWITCHYARD/BPM

           

          In essence, it's a wrapper around jBPM which allows you to map service invocation data and context into the jBPM runtime.

           

          cheers,

          keith

          1 of 1 people found this helpful
          • 2. Re: Support for (REST) Subresource Locators / Dynamic Dispating in Switchyard?
            marco.rietveld

            Keith, thanks for you quick response.

             

            To be honest, this is/feels like a pretty specific use case.

             

            I'm working on the new console component for jBPM, and since SwitchYard takes care of lots of stuff, we're trying to use it as much as possible.

            In this case, I'm creating the REST component/api for the console. This component would be a "plug & play" deployable war that users can simply deploy and use -- these are users who aren't interested in doing any coding with jBPM -- they simply want to use the console as a standalone component for BPM.

             

            What we then want to offer, in terms of a REST api, is something like this:

            http://server.address/
              {id: \\w+}                        // domain (think "repository folder")
                session                       
                  {id: [a-zA-Z0-9_-]+}          // long: ksession id, string: correlation
                                                * retrieves list of process instances for that ksession
                    startProcess                * start process (return inst num, self)
                    signalEvent                 * signal event
                    procInst  
                      {id: \\d+}                // process instance id
                        abort                   * abort process instance
                        signalEvent             * signal event
                        completeWorkItem        * complete work item 
                        abortWorkItem           * complete work item 
                        registerWorkItemHandler * register wih (class must 0 arg construct)
                task                          // task
            
            etc...

             

            You'll notice there are a bunch of regex's there -- and with regards to REST + java code, that translates to subresources/dynamic dispatching.

             

            Doing this purely with RestEasy is slightly more straighforward, to some degree. What's nice about the switchyard approach is that the framework kind of ensures that the code will remain orderly.

            Also, this API is going to be implemented both in REST and using JMS. So far, it seems like being able to use switchyard would enable us to have less duplicate code because of certain classes that we could use in both implementations (SwitchYard would hide the REST/JMS details.)

             

            Thanks,

            Marco

            • 3. Re: Support for (REST) Subresource Locators / Dynamic Dispating in Switchyard?
              marco.rietveld

              Hmm.. to some degree, I'm realizing that dynamic dispatching isn't  necessary here -- I could put all of the logic in one big resource. In that case, it's simple to use Switchyard, of course.

               

              I'm still in the middle of creating the component so I haven't gotten to the refactor/design check stage yet. I have the feeling that doing that (one big resource) is probably not the most maintainable/clean code though.

              • 4. Re: Support for (REST) Subresource Locators / Dynamic Dispating in Switchyard?
                kcbabo

                This sounds like an interesting use case and I'm curious to see how the interface evolves as you go through it.  One thing that jumps out at me is whether Operation is a resource or if it's simply an action on a resource.