7 Replies Latest reply on Nov 21, 2008 6:38 AM by marklittle

    jBPM console project information

    heiko.braun

      I've put together an overview including source repositories, building and testing as well as a high level design overview:

      https://www.jboss.org/community/docs/DOC-12879

        • 1. Re: jBPM console project information
          michaelneale

          Interesting - I like that use of REST. If it works out for you, I would consider ditching GWT RPC as like you say, it encourages re-use.

          The GWT RPC style interface is pretty close to rest in semantics already - so its probably not terribly hard to switch over.

          I think there is a performance cost - however its probably not an issue other then for complex data structures or circular references. But in any case REST can encapsulate DTO serialization using some other mechanism. Not a huge deal.

          • 2. Re: jBPM console project information
            marklittle

             

            "heiko.braun@jboss.com" wrote:
            I've put together an overview including source repositories, building and testing as well as a high level design overview:

            https://www.jboss.org/community/docs/DOC-12879


            I like it. REST is definitely the way to go for this sort of thing.

            • 3. Re: jBPM console project information
              heiko.braun

               


              The GWT RPC style interface is pretty close to rest in semantics already - so its probably not terribly hard to switch over.


              No, not at all. I am leveraging the RESTeasy project. It comes with XML and JSON marshallers out of the box and makes it quiet easy to setup resources. GWT ships the HTTP client abstraction. The only downside is that you need to unmarshall your model by yourself on the client side. But in my case that's trivial.

              I was considering GWT RPC as well, but then chose the REST/Json approach due to several reasons:

              - server side is decoupled from and thus easy to integrate with for non GWT clients
              - REST has good support for multiple content types (images, json, xml) which something I needed for the BPM console
              - ajax and REST play well together (Http status codes, caching, etc)



              • 4. Re: jBPM console project information
                michaelneale

                Yes I like rest - I guess it depends on the complexity of the object graphs if that is what you are sending to the client. In our case we have several non trivial object structures which JSON would not be very good at (and not type safe), so the GWT thing worked out nice. I guess with REST - would use the same thing, but use some kind of JSON or XML serialization to get the object graphs across the network?

                • 5. Re: jBPM console project information
                  heiko.braun

                  Yes, if the graphs get too complex then it not a smart choice todo manual unmarshalling. I heard that GWT RPC uses Json as the wire format as well. So I guess it's just a question of JSon marshaller/unmarshaller capabilities.

                  • 6. Re: jBPM console project information
                    heiko.braun

                    Yes, if the graphs get too complex then it not a smart choice todo manual unmarshalling. I heard that GWT RPC uses Json as the wire format as well. So I guess it's just a question of JSon marshaller/unmarshaller capabilities.

                    • 7. Re: jBPM console project information
                      marklittle

                      REST gets my vote too.