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

 

Best,

Rob

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

    Hi Rob

     

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

     

    Regards

    Gary

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

    No problem.  Will do.

     

    Thanks Gary.

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

    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.

     

    Thanks,

    Tomo

  • 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.

     

    Best,

    Rob

  • 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.