4 Replies Latest reply on May 9, 2008 12:08 PM by radu3000

    jpdl and sca tuscany integration - any?

    radu3000 Newbie

      Hello,

      In my poc I have implemented a soa reference set of apps in two ways:
      1 - using sca tuscany.
      2 - using jpdl runtime library.

      Both products use dependency injection - however for different scopes. SCA emphasis is on service component assembly where jpdl is on the process. However jpdl does a bit of component assembly as well - not at the sca level.

      Here is a suggestion - why not leverage sca tuscany assembly model for referencing sca components under actions? Ideally a process definition xml can import .composite file and concentrate purely on bpm - that is what it can do best, right?

      Albeit - I am not the only one seeking this ....

      Regards,
      Radu.

        • 1. Re: jpdl and sca tuscany integration - any?
          Ronald van Kuijk Master

          - jpdl is not targeted at component assembly, it is targeted at BPM.
          - sca is incubator
          - it is number x in the line of apache esb/soa/.... projects

          why not use jboss ESB with jpdl in it?

          Albeit - I am not the only one seeking this ....

          How do you know?

          • 2. Re: jpdl and sca tuscany integration - any?
            Tom Baeyens Master

            what i understood from sca is that it is a component model so that components can be written in different languages and wired together on the sca level.

            but i am not aware that SCA also has an API that we can use so that I can programmatically call an SCA component.

            the other way round could also be interesting. if we can define the ins and outs of a jpdl process properly in the SCA way, then the jpdl process could be used in a SCA assembly.

            i can see these things conceptually, but i don't know how much work it would take to actually do it.

            • 3. Re: jpdl and sca tuscany integration - any?
              radu3000 Newbie

              Tom,

              Thanks for your reply.

              In the end it boils down to the age old question: what is first chicken or the egg? Process importing components or components importing process.

              Let's take the approach of process importing components - chicken first. Given the current process fragment:




              I could change it to:
              -----------
              import ..\sca\ConsumerFacade.composite
              ...

              <action sca-component-reference="RequestParser"/>


              -----------
              And done! Isn't this a cleaner separation of process and assmbly responsibility? With a bit more work to integrate an sca tuscany runtime and jpdl runtime - there is so much to gain! JPDL can tap into any (almost any - sca component types are constantly growing ...) type of components defined in sca. The component impls would also implement ActionHandler - easy right?

              The SCA api is straight forward:
              // line below can be triggered by the above
              // "import ..\sca\ConsumerFacade.composite" statment
              scaDomain = SCADomain.newInstance("ConsumerFacade.composite");

              // line below is triggered when you need the action to be executed
              requestParserService = scaDomain.getService(RequestParserImpl.class, "RequstParserComponent");

              So what is left?
              1. Change jpdl schema to allow:
              <action sca-component-reference="RequestParser"/>
              2. Make some room in jpdl api to allow references to scaDomain.getService(...) calls.

              I would be glad to contribute some time to the above.

              Regards,
              Radu Marian



              • 4. Re: jpdl and sca tuscany integration - any?
                radu3000 Newbie

                Tom,

                Thanks for your reply.

                In the end it boils down to the age old question: what is first chicken or the egg? Process importing components or components importing process.

                Let's take the approach of process importing components - chicken first. Given the current process fragment:

                <node name="Parse service request">
                 <action class="com.bofa.crme.gps.servlet.RequestParserImpl"/>
                 <transition name="next" to="Transform GCIB request to WCC request"/>
                 </node>

                I could change it to:

                import ..\sca\ConsumerFacade.composite
                ...
                 <node name="Parse service request">
                 <action sca-component-reference="RequestParser"/>
                 <transition name="next" to="Transform GCIB request to WCC request"/>
                 </node>


                And done! Isn't this a cleaner separation of process and assmbly responsibility? With a bit more work to integrate an sca tuscany runtime and jpdl runtime - there is so much to gain! JPDL can tap into any (almost any - sca component types are constantly growing ...) type of components defined in sca. The component impls would also implement ActionHandler - easy right?

                The SCA api is straight forward:
                // line below can be triggered by the above
                // "import ..\sca\ConsumerFacade.composite" statment
                 scaDomain = SCADomain.newInstance("ConsumerFacade.composite");
                
                // line below is triggered when you need the action to be executed
                 requestParserService = scaDomain.getService(RequestParserImpl.class, "RequstParserComponent");


                So what is left?
                1. Change jpdl schema to allow:
                <action sca-component-reference="RequestParser"/>

                2. Make some room in jpdl api to allow references to scaDomain.getService(...) calls.

                I would be glad to contribute some time to the above.

                Regards,
                Radu Marian