11 Replies Latest reply: May 3, 2012 11:54 AM by Keith Babo RSS

    SCA BPEL Schema Version

    Rob Cernich Master

      Hey all,


      I noticed that the schema used for the BPEL component references an older version of the SCA schema.  Is it possible for us to modify the component code to use the BPEL definition provided by the sca-1.1-cd06 version of the SCA specification (i.e. sca-implementation-bpel-1.1-cd03.xsd instead of bpel-v1.xsd)?


      The only change is the namespace for the implementation.bpel element.  (The element definition is essentially the same.)

      New: http://docs.oasis-open.org/ns/opencsa/sca/200912

      Old: http://docs.oasis-open.org/ns/opencsa/sca/200903




        • 1. Re: SCA BPEL Schema Version
          Gary Brown Master

          Hi Rob


          Thats fine with me - do you mind applying the change?




          • 2. Re: SCA BPEL Schema Version
            Rob Cernich Master

            No problem.  Will do.


            Thanks Gary.

            • 3. Re: SCA BPEL Schema Version
              Tomohisa igarashi Master

              Hi Rob,


              Did you try that? I wonder the current org.switchyard.config.model.Descriptor may only support just one marshaller for each one namespace, so in order to use other Schemas in SCA namespace, we may need to add marshaller logic into V1CompositeMarshaller in the core repo, or change the namespace and isolate from SCA default.




              • 4. Re: SCA BPEL Schema Version
                Rob Cernich Master

                Hey Tomo,


                Good point.  I haven't looked into it in that much detail.  I think you are correct, which makes me wonder about the best way to deal with this, if at all.


                Thanks for highlighting the issue.




                • 5. Re: SCA BPEL Schema Version
                  Keith Babo Master

                  Assuming I understand the problem correctly, the quickest and cleanest way to solve this might be to simply acknowledge that multiple marshallers can be registered for a given namespace.  Not sure how nicely fits with the current config API though.

                  David and I were actually chatting about the config API the other day.  He put a lot of work into it back in the day and it's pretty much just plugged along without major mods for the better part of a year.  In that year, we developed a better understanding of what our runtime and components would need from a config standpoint.  In fact, I think we are still learning on that front.  I sense that there will be one large (and final) refactoring there, and I don't believe we are ready for that yet.  My preference would be to sit down with David and others and discuss all the changes at once instead of just updating as we go.  So my feeling here would be to go with the least complex solution possible.  If that's keeping a distinct namespace for now, let's just do that.  If it's trivial to allow multiple handlers per namespace, then we can do that instead and use the standard SCA namespace.  IMHO, what we should *not* do is drop 2-3 weeks on this right now when there are so many other important things to get done for 0.5.


                  ~ keith

                  • 6. Re: SCA BPEL Schema Version
                    Rob Cernich Master

                    The simplest is to do nothing now and address it as part of the future refactoring effort.


                    That gets my vote.

                    • 7. Re: SCA BPEL Schema Version
                      Keith Babo Master

                      This just occurred to me, but yet another option is that all of the standard SCA config support is added inside the config project.  Or maybe we split all the SCA config into a distinct module.  In any case, the standard SCA stuff would all go there, including things like BPEL.  This is all standard stuff and not tied up with component code at all.  Now, if a component has an extension to the SCA types that it wants to register, then that goes in the component project module with a distinct namespace.


                      Now that I think about it, I think this is better than the other two ideas I discussed above.

                      • 8. Re: SCA BPEL Schema Version
                        Keith Babo Master

                        @Rob : right, none of this has to happen immediately.

                        • 9. Re: SCA BPEL Schema Version
                          David Ward Master
                          1. I like the idea of getting the SCA stuff out of config.
                          2. I agree that it would be best for us to get all our config requests/requirements put together instead of messing around as we go.
                          3. I would need to go back and research the possibilities/impact/estimate on the multiple namespaces front. It indeed has been plugging right along on it's own now for quite some time, so I'm a bit dusty on what I wrote - LOL.  And as Keith said, we already have enough to do for 0.5.
                          • 10. Re: SCA BPEL Schema Version
                            Jeff DeLong Master

                            I am not sure what David means but getting the SCA stuff out of the config. Do you mean out of switchyard.xml. Or is this purely an internal discussion?

                            • 11. Re: SCA BPEL Schema Version
                              Keith Babo Master

                              Purely a Maven and modularity thing.  At present, the core config has model classes for SCA elements (composite, component, etc.).  We're talking about moving that to a distinct SCA config module in the project structure.