Composite dependency

[solimo]

Hello!

I'd like to ask about good practices connected with resolving composite dependency in SwitchYard or SCA generally. Imagine case in which two composites are ready and available by set of composite services - for example HTTP, JMS etc. For some reason one of composites starts to require services of another one. Of course we can prepare composite reference of already ready service bindings but this is situation which I'm not interested in. Due to fact that both composites are meant to be run in one AS (or cluster of them) I'd expect something faster and more internal then bindings described in documentation.

I'm pretty sure that I'm missing a point somewhere or maybe such binding implementation is not ready yet?

Robert

[kcbabo]

Hey Robert,

Not sure if I'm interpreting your question correctly, so let me know if I've gone off track.

In addition to the bindings you've listed above (HTTP, JMS, etc.) we have introduced an SCA binding in our 0.8 release.  The SCA binding is essentially an internal runtime binding that allows you to connect between composites/applications without specifying a concrete endpoint address in a binding.  This can be used to wire applications together inside a single instance or across instances in a cluster.

I'm still working on the docs for 0.8, but the quickstarts are already done which demonstrate use of an SCA binding for inter-application communication in a cluster:

https://github.com/jboss-switchyard/quickstarts/tree/master/demos/cluster

You can download a nightly build of SY 0.8 if you want to give it a go.

hth,

keith

[solimo]

Hello Keith,

You perfectly understand my problem - it is exactly what I was looking for in release... 0.7 final. Due to the fact that it is 0.x, it doesn't matter that it is not here yet. Is it true that version 1.0 is expected in the middle of 2013?

Robert

[kcbabo]

Yes, that's an accurate estimate for 1.0.  0.8.0.Final release should be announced on Monday.

[solimo]

Hello again,

After 0.8 release I've decided to play around with SCA references a bit. In meanwhile I've encountered strange behaviour. I've instanced Camel route which has a reference (based on WSDL with two operations) which is promoted to composite reference of same WSDL as a contract with SCA binding. When camel delivers exchange to endpoint (out) exception about no operationName defined (WSLD width two operations) is being thrown. From what I've researched operationName header should solve the problem. Unfortunately it will not, due to the implementation of org.switchyard.component.camel.SwitchYardProducer.lookupOperationNameFor. Tbh, I'm confused by first two lines (165, 157 version 0.8). getOperationName is meant to return operationName (in case of lack of OperationSelector in Exchange) propagated from Camel endpoint. Going further and extending uri by operationName will result with NPE from SCAInvoker - what is expected I think due to mishmash width switchyard.xml definition of reference.

[splatch]

Hey Robert,

Sadly (or luckily?) this issue is known and there is pull request for solving it. After applying it camel implementations will behave as proxies.

[solimo]

Thanks for update Łukasz,

Since "This JIRA is in the 1.0 bucket, so please don't push for 0.8." to get it fixed, I'm supposed to build trunk right?

[kcbabo]

I agree with Lukasz that the referenced JIRA could help, but I'm not sure it's required for this scenario.  Are you using the operationName parameter of the switchyard:// endpoints in your Camel route?  That's required if there are multiple operations on the reference interface (at least until the JIRA Lukasz mentioned is processed).

The Camel implementation documentation has an example of using it:

https://docs.jboss.org/author/display/SWITCHYARD/Camel

hth,

keith