Config for SCA binding extension

[kcbabo]

I'm looking to implement binding.sca this release and also replace our use of binding.remote with extensions to binding.sca.  In a nutshell, binding.sca allows communication between services and references within a domain.  The content model for binding.sca is empty, so there's no additional configuration specific to this binding type.  I want to add extensions to allow the following to be configured:

• Target name : this would be used by references that wish to wire to services in other applications within a domain.  Target is a QName which identifies the namespace and local name of the target service, which means that the reference qualified name (local and/or namespace) can be be different from the service's qualified name.
• Clustering enabled : indicate whether the endpoint should be used within a SY cluster.  For services, this indicates the endpoint should be published in the cluster's distributed service registry.  For references, this indicates that destination endpoints should be resolved from the clustered service registry.
• Load balancing : specifies the load balancing behavior for clustered service invocations.  This only applies to references and can either be a standard load balance policy (e.g. "round-robin", "random-robin", etc.) or a custom, user-supplied implementation.

With that configuration in mind, here's a snip of a possible XML representation.  I put namespace prefixes in there to distinguish between the standard SCA definition (sca:) and our extensions (sy:).

Reference binding with wiring and no clustering:

<sca:binding.sca>
    <sy:endpoint target="ns:foo"/>
</sca:binding.sca>

Service binding with clustering:

<sca:binding.sca>
    <sy:endpoint>
        <sy:cluster/>
    </sy:endpoint>
</sca:binding.sca>

Reference binding with wiring, clustering, and custom load balance strategy

<sca:binding.sca>
    <sy:endpoint target="ns:foo">
        <sy:cluster>
            <sy:loadBalance strategy="custom" class="org.example.MyStrategy"/>
        </sy:cluster>
    </sy:endpoint>
</sca:binding.sca>

Feedback is most welcome!

thanks,

keith

[dward]

1. At first I thought "target" should be targetName or targetService or targetServiceName, but I dunno. Maybe just "target" is fine.
2. For load balancing strategy, we have some options for the config.
   • The value of "strategy" maps to a java enum (LoadBalanceStrategy.ROUND_ROBIN, XYZ, CUSTOM?), so that the "class" attribute is optional unless the strategy is CUSTOM.  And if it's not CUSTOM, we internally map to well-known implementation classes.
   • We do away with the strategy attribute completely, and user always specifies the class.
   • We do like JBoss AS LoginModules, where "strategy" is like "code" and can be the simple name of the class (in an assumed, OOTB package), sort of like UsersRoles is. Or you can provide a fully-qualified pkg+class name. (I changed my mind. I actually think maybe this 3rd option might be best...)

[rcernich]

David Ward wrote:

1. At first I thought "target" should be targetName or targetService or targetServiceName, but I dunno. Maybe just "target" is fine.

I was thinking something similar, but more like:

• domain
• service

{code:xml}

<sy:endpoint domain="urn:some:switchyard:app:namespace" service="SomeService" />

{code:xml}

To be honest, working with QNames can be a pain.  (Thinking of my recent experience with BPEL.)

[dward]

As much as a pain QNames can be, they are all already pervasive for us, so that doesn't phase me. However, it might be a good idea if the domain name and service name are separate, if the domain could be it's own QName.  (Keith, or are domains always 1:1 with namespaces?)

[rcernich]

Hey David,

Other than implementation.bpel@process, where else are wer using QNames for values in SwitchYard?  The pain point is that you need to ensure the prefix used in the value is properly declared (which is the problem I had trying to get the BPEL stuff together in the tooling).  That said, I could easily see where you'd want to declare the namespace once, especially if you're referencing a fair number of services.

Either way, I'm good.  Just throwing out an opinion.

Best,

Rob

[dward]

Internally, all over the place. In configuration, maybe not so.  It's really only an issue if you use attr="prefix:value", at which point the mapping of prefix-to-namespace is a bother.  But if it is attr="{the.actual.name.space}value", then that's standard QName parsing, and easy.

[kcbabo]

Thanks for the feedback, guys.

@Rob - Every service and reference in switchyard.xml is a QName.  The local part is in the name attribute value and the namespace is the targetNamespace of the composite.

@David -

• I agree that "target" might not be expressive enough.  People won't be dealing with the XML directly very much, but I still believe in the spirit of self-description.  If we get consensus on an alternate, then I'm happy to change it.
• Yes on strategy mapping to an enum. The class attribute is used only if "custom" is used for the type.
• As a user, I don't like providing full class names with package.  Even if it's done through tooling, it just feels rough to me when I have to do it.  Your idea about using class name without the package for default impls and package+class name for custom is interesting.

[kcbabo]

OK, incorporating feedback leads to this:

<sca:reference ...>
  <sca:binding.sca>
     <sy:endpoint target="foo" targetNamespace="urn:example:bar"/>
      <sy:clustered>
            <sy:loadBalance strategy="RoundRobin"/>
       </sy:clustered>
  </sca:binding.sca>
</sca:reference>

<sca:service>
   <sca:binding.sca>
      <sy:clustered/>
   <sca:binding.sca>
</sca:service>

Change log:

• <cluster> renamed to <clustered> and moved to sibling of <endpoint>
• QName target has been changed to have target for service name and targetNamespace for namespace.  One can be specified without the other.
• load-balance changed to loadBalance and strategy maps to a class name per the algorithm David outlined

Speak now or forever hold your complaints!

[dward]

I like it. But... (sorry), doesn't "targetNamespace" mean something special in XML? For the schema?

[kcbabo]

Sorry, missed your last comment there David.  The targetNamespace attribute does indeed imply to XML schema definitions.  It also applies to WSDL definitions and to SCA composite definitions.  In other words, targetNamespace gets around. :-)  Since the value of targetNamespace in this case aligns with the targetNamespace attribute in another composite, I think it's appropriate to use that name.  But happy to consider alternates if people feel it's inappropriate.

[kcbabo]

There was a side IRC discussion on how binding.sca can be extended and I forgot to update this thread.  Instead of using extension elements, we need to use attribute extensions based on the SCA binding schema.  Here are equivalent definitions to the examples provided above.  Note that this code has been pushed, so this is the final model.

<sca:reference name="CreditAgency" multiplicity="0..1" promote="DealerBean/CreditAgency">
   <sca:interface.java interface="com.example.switchyard.cluster1.CreditAgency"/>
   <sca:binding.sca sy:clustered="true" sy:target="CreditService" sy:targetNamespace="urn:com.example.switchyard:cluster2:0.0.1-SNAPSHOT"/>
</sca:reference>

<sca:service name="Dealer" promote="DealerBean/Dealer">
    <sca:interface.java interface="com.example.switchyard.cluster1.Dealer"/>
    <sca:binding.sca clustered="true"/>
</sca:service>

Note that the attributes on the <sca:binding.sca> element are namespace qualified and map to the SwitchYard config namespace of "urn:switchyard-config:switchyard:1.0".  I have no doubt that this will produce uncomfortable levels of indigestion in EMF.