9 Replies Latest reply on Feb 5, 2009 11:53 AM by maeste

    Planning next releases

    maeste

      Hi folks,
      now that Wise 1.0 is released we have to start to plan our next release. I'd like to open here the discussion about to decide on what next release have to be mainly focused.
      We have a lot of ways we can evaluate. In my mind all these things have to be implemented at some stage, but of course we have to decide priorities for them and schedule some of these for next release. I try to put here the main ideas in a descending priority order. Please give me your opinions and feel free to add your thoughts

      1. Start developement of webgui. IMHO Its description and plans merit a dedicated 3ad. I'll try to open it tonight too.
      2. Add other WS-* implementation to support all WS-* supported by jbossws or related JBoss projects (ie WS-RM, WS-Transaction...please don't consider WS-Eventing I had too much pain with it ;))
      3. Finish JAX-RS implementation (some issues opened by Jervis) and complete JAX-RS sample
      4. Project cleanup (some issues opened related to maven and docbook). In particular I think it need to be mavenized since it have too much dependencies and their maintenance could easy become full of pain.
      5. More samples. It would demonstarte advanced using with complex wsdls and complex smooks transformation. It would be good to have also some samples demonstrating possible other integration, ie with seam or Jython. A bit more unit tests too.
      6. Starting server side development (or better investigation of its feasibility) . In a nutshell I have in mind a similar approach we are using to develop WS client also to deploy WS service modifying classes and introducing annotation. This idea could be interesting if we can provide an easy way to deploy service based on classes existing only runtime (aka smooks generated) or classes wrapping scripting language. Have I gotten you the idea? Please ask and/or discuss this point.
      7. Issue LMS related on Jira opened by Alessio
      8. Invocation starting from other sources than Java classes (i.e csv or EDI file) using Smooks features. It isn't just a sample, because, even if Smooks support these transformation out of the box, we need some support to support iterative invocation of Wise client. This point could be a subtask of point 9
      9. Wise as Smooks Visitor.

      That's all for the moment.
      Any thoughts are more than welcome

        • 1. Re: Planning next releases
          jim.ma

           

          "maeste" wrote:

          6. Starting server side development (or better investigation of its feasibility) . In a nutshell I have in mind a similar approach we are using to develop WS client also to deploy WS service modifying classes and introducing annotation. This idea could be interesting if we can provide an easy way to deploy service based on classes existing only runtime (aka smooks generated) or classes wrapping scripting language. Have I gotten you the idea? Please ask and/or discuss this point.

          I do not know if we can provide an easy way to do that. I also experienced before and there are much pains to do that. One of them is: it is not all pojo classes can be exposed as webservice. You will find it is hard to annotate to some java method and choose the doc-bare-literal/doc-wrapped/rpc-literal. And you also do not know how to annotate for the java.lang.NullPointerException . The another problem is : JAXB can not handle the pojo types class that pojo method reference , these types also need some JAXB annotation .
          So , should we provide some tool or utilities to tell user this class can not be exposed to webservice ?
          "maeste" wrote:

          8. Invocation starting from other sources than Java classes (i.e csv or EDI file) using Smooks features. It isn't just a sample, because, even if Smooks support these transformation out of the box, we need some support to support iterative invocation of Wise client. This point could be a subtask of point 9
          9. Wise as Smooks Visitor.

          I do not understand this point . Could you please explain it for me further ?

          • 2. Re: Planning next releases
            maeste

             

            "jim.ma" wrote:

            I do not know if we can provide an easy way to do that......<CUT>

            Of course you are right. It's not an easy task or better is a complicate task that need deeper investigations, but could be great fun to (try to) do the effort isn't it?


            9. Wise as Smooks Visitor.

            I do not understand this point . Could you please explain it for me further ?


            Yep right. From smooks 1.1 user guide
            Basics

            The most commonly accepted definition of Smooks would be that it is a "Transformation Engine". However, at it's core, Smooks makes no mention of "data transformation". The smooks-core codebase is designed simply to support hooking of custom "Visitor" logic into an Event Stream produced by a data Source of some kind (XML, CSV, EDI, Java etc). As such, smooks-core is simply a "Structured Data Event Stream Processor".


            Of course, the most common application of this will be in the creation of Transformation solutions i.e. implementing Visitor logic that uses the Event Stream produced from a Source message to produce a Result of some other kind. The capabilities in smooks-core enable more than this however. We have implemented a range of other solutions based on this processing model:


            1. Java Binding: Population of a Java Object Model from the Source message.
            2. Message Splitting & Routing: The ability to perform complex splitting and routing operations on the Source message, including routing to multiple destinations concurrently, as well as routing different data formats concurrently (XML, EDI, CSV, Java etc).
            3. Huge Message Processing: The ability to declaratively consume (transform, or split and route) huge message without writing lots of high maintenance code.

            So we can implement a visitor that have logic to invoke webservices using wise and working with objects in Smooks' Execution context. Take a look to ESB quickstart for huge message splitting and routing: we can provide there a visitor wise based to invoke WS instead pure Http routing.
            Hoping to have explained a little better. Feel free to come back to me if you have further questions or my explanation is totally bad.


            • 3. Re: Planning next releases
              marklittle

               

              "maeste" wrote:

              2. Add other WS-* implementation to support all WS-* supported by jbossws or related JBoss projects (ie WS-RM, WS-Transaction...please don't consider WS-Eventing I had too much pain with it ;))


              Yes, plus WS-Eventing isn't a standard yet so I would avoid it until we finish the process at W3C.


              3. Finish JAX-RS implementation (some issues opened by Jervis) and complete JAX-RS sample
              4. Project cleanup (some issues opened related to maven and docbook). In particular I think it need to be mavenized since it have too much dependencies and their maintenance could easy become full of pain.
              5. More samples. It would demonstarte advanced using with complex wsdls and complex smooks transformation. It would be good to have also some samples demonstrating possible other integration, ie with seam or Jython. A bit more unit tests too.


              I think 5 is critical. The more examples the better.


              6. Starting server side development (or better investigation of its feasibility) . In a nutshell I have in mind a similar approach we are using to develop WS client also to deploy WS service modifying classes and introducing annotation. This idea could be interesting if we can provide an easy way to deploy service based on classes existing only runtime (aka smooks generated) or classes wrapping scripting language. Have I gotten you the idea? Please ask and/or discuss this point.


              How would that relate to JSR 181?


              7. Issue LMS related on Jira opened by Alessio
              8. Invocation starting from other sources than Java classes (i.e csv or EDI file) using Smooks features. It isn't just a sample, because, even if Smooks support these transformation out of the box, we need some support to support iterative invocation of Wise client. This point could be a subtask of point 9
              9. Wise as Smooks Visitor.

              That's all for the moment.
              Any thoughts are more than welcome


              • 4. Re: Planning next releases
                maeste

                 

                "mark.little@jboss.com" wrote:
                "maeste" wrote:


                6. Starting server side development (or better investigation of its feasibility) . In a nutshell I have in mind a similar approach we are using to develop WS client also to deploy WS service modifying classes and introducing annotation. This idea could be interesting if we can provide an easy way to deploy service based on classes existing only runtime (aka smooks generated) or classes wrapping scripting language. Have I gotten you the idea? Please ask and/or discuss this point.


                How would that relate to JSR 181?

                Well, JSR-181 define annotation to be used to expose a class as webservice. And of course you need to put them in your source code. What I'm purposing is to introduce these annotations runtime on compiled classes. Why? for example to expose a class you haven't source code as a webservice.
                Another things doable with the same approach is to generate also exposed classes runtime for example to wrap a Ruby script or to expose a dynamic generated object model to be passed to a smooks transformation to route, split, or merge it using smooks itself.
                Of course is just a brainstorming at the moment, but I'm pretty sure these things are doable.

                • 5. Re: Planning next releases
                  asoldano

                   

                  "maeste" wrote:
                  "mark.little@jboss.com" wrote:
                  "maeste" wrote:


                  6. Starting server side development (or better investigation of its feasibility) . In a nutshell I have in mind a similar approach we are using to develop WS client also to deploy WS service modifying classes and introducing annotation. This idea could be interesting if we can provide an easy way to deploy service based on classes existing only runtime (aka smooks generated) or classes wrapping scripting language. Have I gotten you the idea? Please ask and/or discuss this point.


                  How would that relate to JSR 181?

                  Well, JSR-181 define annotation to be used to expose a class as webservice. And of course you need to put them in your source code. What I'm purposing is to introduce these annotations runtime on compiled classes. Why? for example to expose a class you haven't source code as a webservice.
                  Another things doable with the same approach is to generate also exposed classes runtime for example to wrap a Ruby script or to expose a dynamic generated object model to be passed to a smooks transformation to route, split, or merge it using smooks itself.
                  Of course is just a brainstorming at the moment, but I'm pretty sure these things are doable.


                  Well, Stefano already knows this... I like this point 6 ;-)

                  Perhaps you already know, but JAXWS Endpoint API makes this even more interesting, as you're already able to programmatically deploy a webservice endpoint on the fly given an endpoint implementation instance (see https://jax-ws.dev.java.net/nonav/2.1.2m1/docs/endpoint.html):
                  import javax.jws.WebService;
                  
                  @WebService
                  public class MyService {
                  
                   public String hello(final String text) {
                   return text;
                   }
                  
                  }
                  
                  
                  import javax.xml.ws.Endpoint;
                  
                  public class Main {
                  
                   private static final int PORT = 58888;
                  
                   public static void main(String[] args) {
                   Endpoint endpoint = Endpoint.create(new MyService());
                   endpoint.publish("http://localhost:" + PORT + "/");
                   }
                  }
                  

                  Perhaps some efforts on this point 6 could lead to something interesting...

                  • 6. Re: Planning next releases
                    asoldano

                     

                    "maeste" wrote:

                    4. Project cleanup (some issues opened related to maven and docbook). In particular I think it need to be mavenized since it have too much dependencies and their maintenance could easy become full of pain.

                    +1

                    5. More samples. It would demonstarte advanced using with complex wsdls and complex smooks transformation. It would be good to have also some samples demonstrating possible other integration, ie with seam or Jython. A bit more unit tests too.

                    +1

                    • 7. Re: Planning next releases
                      jim.ma

                       

                      "alessio.soldano@jboss.com" wrote:

                      Well, Stefano already knows this... I like this point 6 ;-)

                      Perhaps you already know, but JAXWS Endpoint API makes this even more interesting, as you're already able to programmatically deploy a webservice endpoint on the fly given an endpoint implementation instance (see https://jax-ws.dev.java.net/nonav/2.1.2m1/docs/endpoint.html):
                      
                      import javax.jws.WebService;
                      
                      @WebService
                      public class MyService {
                      
                       public String hello(final String text) {
                       return text;
                       }
                      
                      }
                      
                      
                      import javax.xml.ws.Endpoint;
                      
                      public class Main {
                      
                       private static final int PORT = 58888;
                      
                       public static void main(String[] args) {
                       Endpoint endpoint = Endpoint.create(new MyService());
                       endpoint.publish("http://localhost:" + PORT + "/");
                       }
                      }
                      

                      Perhaps some efforts on this point 6 could lead to something interesting...


                      +1. Point 6 can rely on JBossWS function about this .

                      • 8. Re: Planning next releases
                        asoldano

                        Ah, I was looking at specific issues and forgot to cast my +1 on point 1 too, ie. the webgui, as that would restore the fuctionality that was one of the original purpose of Wise ;-)

                        • 9. Re: Planning next releases
                          maeste

                           

                          "alessio.soldano@jboss.com" wrote:


                          Well, Stefano already knows this... I like this point 6 ;-)
                          [...]
                          Perhaps some efforts on this point 6 could lead to something interesting...


                          Hi Have a look to this post:
                          http://oddthesis.org/posts/2009-02-jboss-webservices-and-ruby

                          Bob Have just implemented an idea very close to our point 6 to enable JBossWS webservice in Ruby.
                          A lot of fun.