Create a SwitchYard Gateway vs Implement Camel Component?

[ceefour]

Dear SwitchYard,

I am interested to integrate xws4j (an XEP-0244 IO Data implementation for XMPP) to SwitchYard. The goal is that services can be exposed and used through XMPP IO Data just as easily as they can be exposed (and consumed) through SOAP with SwitchYard.

My questions:

1. It seems I need to create a gateway. How do I create a SwitchYard gateway?
   
   
2. Or should I just create a Camel component? (Note: While Camel already has XMPP component, but IO Data is an asynchronous service protocol runs on top on top of XMPP) That way everybody using Camel can use it, although I'm not sure of its flexibility compared to a SwitchYard gateway.
   
   
3. Does SwitchYard or SCA provide an API/interface/annotation that service implementations can use to serve asynchronous services? I mean, while doing the work, the service can push status updates and other data to the client (the "message contract" of status and informational updates is different than request and response messages).
   
   
4. Related to #3, does SwitchYard or SCA provide an API for clients to consume services that provide push/asynchronous updates? Maybe based on Future<> objects.
   
   
5. If #3 / #4 is "no", is it in the roadmap?

I apologize for the long questions. Thank you very much.

[kcbabo]

Hey Hendy,

Sorry for the lag in reply.  I somehow missed your post. 

1) Take a look at the components repository in GitHub for examples of how to structure and implement SwitchYard components.  One example to look at would be the SOAP gateway.

2) Actually, you don't have to choose.  You can create a SwitchYard component which also implements the appropriate Camel component interfaces as well.

For 3 and 4) The core message exchange API in SwitchYard is designed to be asynchronous, so the send of a message can be decoupled from the receipt (which is handled by an ExchangeHandler in the core API).  You can take advantage of these contracts directly when writing a component.  Creating a service contract around this for implementing business services is a bit higher level and there are a number of approaches.  For example, you could register with a oneway operation and then provide a callback address for subsequent replies.  SCA provides a mechanism for providing a Callback interface, but we do not support that at the moment.

cheers,

keith

[ceefour]

Wow!

Thank you very much Keith for the helpful explanation :-)