Petals CDK

=> This is more a discussion than a real request.

For the moment, Petals configurations are organized as described below:

• JBI sections
  • CDK parameters
  • Component parameters

The CDK and the component parameters are at the same level.
It is not possible, with the existing technologies, to describe the structure of our jbi.xml.
I mean, the only way is to build a single XSD that describes all the possible jbi.xml. This is what was done in the studio to validate jbi.xml and provide content assistance. Besides, the jbi.xml is parsed and validated at 3 different levels (the container, the CDK and the component).

Modular approaches have been tried, with:

• "redefine" mark-ups. But this mark-up was depreciated in recent versions of XSD, and is supported by very few implementations.
• Abstract elements and substitution groups. But this would force us to change the structure of our jbi.xml (having one "cdk" parent element and one "component" parent element).
• Use type extensions, but that was forcing us to remove the support of "any" elements.

Another suggested approach was to split the configuration into three files:

• The jbi.xml would define the JBI sections, with a sub-element ID.
• There would be a cdk.xml, with a clean XML schemas, each ID having its own CDK section.
• There would be a component.xml, with a clean XML schemas, each ID having its own component section.

The clean part about this would be that each file would be parsed and validated by its own part (jbi.xml by the container, cdk.xml by the CDK and component.xml by the component).

There is another possibility, that comes from a simple fact: there are CDK parameters that are useless for a component. Policy-retry is the most famous one. Only the FTP BC has implemented it (and maybe the SFTP too). One solution could be to remove the CDK parameters and let the component require the CDK parameters. We here face the problem of the CDK duality: both a framework and a library!

However, some components miught play the original and rename CDK-parameters, loosing consistency between components.
That could be handled by an independant framework.

Let's take the example of the Retry-policy.
In our framework configuration file, we would set it to unactivated.
=> The retry-policy service is unregistered, the configuration parser will not search for a retry-policy element, and the generated template for the jbi.xml (configuration file) would not reference it. The component configuration would only contain relevant parameters, for both CDK services and component features.

With jbi.xml that would look-like...

<provides...>
     <soap:wsdl>myWsdl.wsdl</soap:wsdl>
     <soap:service-name>myServiceName</soap:service-name>
     <!-- ... -->
</provides>

... it should be possible to describe our jbi.xml with a single XSD.
We would have an "abstractJbi" element, replaced by a substitution group for "jbi" element.
And this "jbi" element would have a single sequence of known children elements. JAX-B validation should directly work.

One last point about Petals configurations, is the evolution of the configurations and their support.
Known practices:

• Removal of any element. => major change
• Addition of required elements.
  • Can we find a value for this element alone? => make this element optional.
  • Otherwise: => major change.
• Addition of an optional element. => minor change.
• Major change => new major version of the component and update of the TNS of the component.

A component version should support all the configurations from the previous versions (with the same major digit).
A version 3.1 of a component should support SU that were created for the component 3.0.
Obviously, the component 3.0 cannot be asked to support SU of the component 3.1, as their configuration was not defined at the time!

One gain we would have with a merge of the CDK and component parameters would be with respect to CDK evolutions.

• Change of the CDK => update of the CDK TNS => no more support for previous SU.
• With one single level, update of the CDK => check the SU's jbi.xml to determine which services should be activated and for which SU.
• With one single level, support a new feature of the CDK would be like having a new component parameter, that might be optional.

That makes me think CDK features should activated or deactivated for a SU in function of its configuration.
As an example, if there is not Policy-retry for a SU, but the component supports it, it should be deactivated for this SU anyway.