Petals CDK

Why not? We can provide both approaches...

Do you mean you would let the user define which services to activate?
I was rather seeing it as an internal solution.
Meaning I would register a handler programmatically, and not with a XML file.

Maybe this parameters and configuration discussion can be moved to another entry (original subject is about services).

OK for the properties file but it depends for which parameters.

For example, if I take the service pattern I introduced :

<service class="org.ow2.petals.cdk.service.Foo">
  <param name="foo" value="bar"/>
  <param name="hello" value="world"/>
</service>

of course we can also define the service and it's parameters in a properties file :

service.foo=org.ow2.petals.cdk.service.Foo
service.foo.foo=bar
service.foo.hello=world

but it is less explicit than the XML way in this case.

In term of configuration, I really thing that we must keep it simple, something like <parameter name="" value=""/> is generally enough in all cases. No more complex XSD at the CDK level (this is just what I suggest...).

I would be even more purist.

<provides ...>
      <component:properties>myComponent.properties</properties>
</provide>

Besides, the properties would be loaded only once, during the install phase.
Even complex properties are quite simple to write in properties.

And properties files can be auto-documented.
See the Apache HTTP server.

This is exactly what I want to say. The CDK is composed of dozens of services but nobody use the same pattern. The CDK provides facilities to the component developer but can also provides ones for the CDK developers.
Each service can handle things in an Axis2 style ie something like void invoke(Context) where Context contains all things (configuration, JBI things and more). Services can also be grouped and can also have priorities (to manage lifecycles for example).
In term of configuration, I really thing that we must keep it simple, something like <parameter name="" value=""/> is generally enough in all cases. No more complex XSD at the CDK level (this is just what I suggest...).

Could we go further?
The CDK features themselves should be services.

Notifications, policy-retries, etc. should be services.
A component should be able to register or unregister a given service.
The activation or not of a service may impact the configuration (jbi.xml) of the SU and the component.

Besides, there should be for each CDK service a default handler.
For notifications, almost (if not) everyone will keep it activated and use the default handler.
But for policy-retries, we would simply have a default handler that does nothing. Implementing it for a component would consist in writting and registering a different handler.

WSDL management, component native services, timeout management, consume management could be other services.
The default consume management would be to use the jbi.xml parameters to get the operation and the MEP. For some components, like the SOAP, we would simply override the handler to guess it from the request message.

Eventually, the CDK should provide a way to send the right configuration parameters to the associated handler.
Maybe each handler should pick up its parameters in the configuration. Regarding this last part, things are not completely clear in my mind. And Petals configurations is a big issue I will have to split in several topics.