SCA Interface required for Service or not?

[sdirbach]

Hi,

imagine the following switchyard service, that reads a file through a camel producer and passes it as a message to a camel route.

<?xml version="1.0" encoding="UTF-8"?>
<switchyard xmlns="urn:switchyard-config:switchyard:1.0" xmlns:bean="urn:switchyard-component-bean:config:1.0" xmlns:camel="urn:switchyard-component-camel:config:1.0" xmlns:camel_1="urn:switchyard-component-camel-core:config:1.0" xmlns:file="urn:switchyard-component-camel-file:config:1.0" xmlns:quartz="urn:switchyard-component-camel-quartz:config:1.0" xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="switchyard-fs-example" targetNamespace="urn:com.example.switchyard:switchyard-fs-example:1.0">
  <sca:composite name="switchyard-fs-example" targetNamespace="urn:com.example.switchyard:switchyard-fs-example:1.0">
    <sca:service name="TestService" promote="CamelServiceRoute/TestService">
      <file:binding.file name="fileBinding">
        <operationSelector operationName="doSomething"/>
        <file:contextMapper class="com.example.switchyard.switchyard_fs_example.MyCM"/>
        <file:directory>/home/sascha/sy-test</file:directory>
        <file:consume>
          <file:move>archive/$${file:onlyname}.$${date:now:yyyyMMddHHmmss.SSS}</file:move>
          <file:moveFailed>error/$${file:onlyname}.$${date:now:yyyyMMddHHmmss.SSS}</file:moveFailed>
          <file:idempotent>false</file:idempotent>
        </file:consume>
      </file:binding.file>
    </sca:service>
    <sca:component name="CamelServiceRoute">
      <camel:implementation.camel>
        <camel:java class="com.example.switchyard.switchyard_fs_example.CamelServiceRoute"/>
      </camel:implementation.camel>
    </sca:component>
  </sca:composite>
</switchyard>

Do I need to add an interface (Java, WSDL, ESB-Type) to the Service? What would this interface look like for a camel binding?

From what I experienced, it works fine without an interface (It's optional in the SCA spec) and gets ignored when it is specified. Anyway, the designer does not allow to create services without interfaces and I read somewhere, that an Interface is always required for a SCA Service.

What do you think on that?

Kind regards,

Sascha

[kcbabo]

Interfaces are required for component services and references.  They are also required for composite services and references, but if you don't specify one explicitly in the model, the interface is inherited from the component service/reference being promoted.

[sdirbach]

Hello Keith,

thank you for you answer.

What still bothers me is the fact, that I didn't specify any interface and it works anyway.

Is it added automatically through the Camel Route / Binding? I could image something like:

public void startCamelRoute(Exchange e);

Kind regards,

Sascha

[kcbabo]

Are you saying that the app that goes with the switchyard.xml you included above deploys and runs successfully?  If so, can you attach a copy of that application?  The only way I can see that working is with an annotated Camel route that is generating config.

[sdirbach]

Hi,

as it turned out, I was working on a copy of the switchyard.xml file. It only works when I add

<sca:service name="TestService">
    <sca:interface.java interface="com.example.switchyard.switchyard_fs_example.TestService"/>
</sca:service>

to the sca:component or

<sca:interface.java interface="com.example.switchyard.switchyard_fs_example.TestService"/>

to the sca:service which includes the Camel Binding. This would prove your previous answer.

Interestingly the application also deploys without the interface definition and fails at runtime with a NullPointerException

17:25:17,228 ERROR [org.apache.camel.processor.DefaultErrorHandler] (Camel (camel-161) thread #220 - file:///home/sascha/sy-test) Failed delivery for (MessageId: ID-host-39270-1387370663263-160-1 on ExchangeId: ID-host-39270-1387370663263-160-2). Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException: java.lang.NullPointerException
    at org.switchyard.internal.ServiceReferenceImpl.createExchange(ServiceReferenceImpl.java:109) [switchyard-runtime-1.1.0.M3-redhat-2.jar:1.1.0.M3-redhat-2]
    at org.switchyard.component.camel.SwitchYardProducer.createSwitchyardExchange(SwitchYardProducer.java:190) [switchyard-component-camel-switchyard-1.1.0.M3-redhat-2.jar:1.1.0.M3-redhat-2]
    at org.switchyard.component.camel.SwitchYardProducer.process(SwitchYardProducer.java:94) [switchyard-component-camel-switchyard-1.1.0.M3-redhat-2.jar:1.1.0.M3-redhat-2]
    at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) [camel-core-2.10.0.redhat-60024.jar:2.10.0.redhat-60024]
    at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) [camel-core-2.10.0.redhat-60024.jar:2.10.0.redhat-60024]

To be honest I still don't really like the implications of this. My Interface  looks like this:

void doSomething();

which is pretty much a dumb dummy interface. In my eyes this is useless as it doesn't reflect the actual situation with the binding and only acts as a placeholder.

I can see that this is a general problem, as the service can also be invoked through the API, even though I don't think that this is useful in many cases (i.e. when I have a service that consumes files, it is likely that I also process the filename, which would fail at runtime when the service is called through the API).

In my opinion there should be another interface type "camel" which is generic and can only be applied to services with bindings defined. This Interface would reflect the actual situation better for binding-only services.

Kind regards,

Sascha

[kcbabo]

Every service has a contract, whether you choose to acknowledge it or not.  Let's take a file binding as an example.  You can choose to be very specific about the content of files that are picked up via file binding by using a WSDL interface with an XSD describing the content, for example.  Or you can be generic, and just use a Java interface which has an opaque type like String as a method parameter.  Either way, that service has some implicit contract w/r/t the content that is allowed to be processed.  If you don't want to create an interface file at all, you can use interface.esb, which allows you to specify the type as a string literal in switchyard.xml:

<sca:service name="TestService"> 
     <swyd:interface.esb inputType="java:java.lang.String"/>
</sca:service>

[sdirbach]

Hi Keith,

I didn't question the need for an interface. I was just a bit worried about Interfaces that don't reflect the actual implementation. Anyway I think your last answer pretty much summed it up. Thank you for that clarification.

Kind regards,

Sascha