Hi Guys, Thank you for the detailed response. What I will try first is to wrap Camel in a java implementation. However there are several benefits which come into my mind in having own camel implementation:
1. The user will not have to write any java code - he will need just to provide the configuration spring xml (or Java DSL file with route descriptions), which from the other side could be generated from some UI tool like http://www.eclipse.org/stp/eid/index.php. If there are some transformations they could also be provided as separate .xq files, which could also be generated from UI mapping tool. Finally the user will not write a single line of code. 2. If Camel is wrapped in implementation.java you will have to convert an arriving XML message to java via JAXB or SDO, which will be bad for the performance in case of pure xml integration scenarios. 3. Personally I see some prospective Camel implementation type work the following way: Every operation in a service of a SCA component will be implemented by one route description and the input and output of the operation will be addressed by camel as endpoints. The route will start from the input endpoint and will end at the output endpoint of the operation. Any error situations will end at the fault endpoint. If we have operation getQuote for example, we could have the following endpoints sca:getQuote:in, sca:getQuote:out, sca:getQuote:fault Also all references of the current SCA component will be described and accessible as endpoints. In this way consumed services can be invoked. So, generally, I see Camel's role here as intergation pattern description language, like Java language and BPEL language. That's why I was thinking of a separate implementation type. 4. It is true that for my case I need syncronous execution, but there are may be other scenarios where asyncronous execution can have some benefits. 5. IBM use SCA for definition of mediation flows (http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topic=/com.ibm.websphere.wesb602.doc/tasks/twesb_listingmediationmodules.html). My be Camel can be used for definition of such mediation flows within an SCA assembly. Bye, Vasil James.Strachan wrote: > > Not sure :) - I've not really done any SCA > > 2008/5/22 Gert Vanthienen <[EMAIL PROTECTED]>: >> James, >> >> Yeah, we could (and probably should) do that, but -- for Vasil's use case >> -- >> what features would you expect on top of what you can do now using >> implementation.java and implementation.spring? >> >> Gert >> >> James Strachan wrote: >>> >>> Agreed - I guess someone could hack up a Tuscany plugin for Camel? >>> >>> 2008/5/22 Gert Vanthienen <[EMAIL PROTECTED]>: >>> >>>> >>>> Vasil, >>>> >>>> >>>> I'm not an SCA expert at all, but... >>>> If you want to use Camel inside an SCA component, I think you should be >>>> able >>>> to Tuscany's implementation.java or implementation.spring to do this. >>>> If >>>> you hide the interaction with the other components behind a Java >>>> interface >>>> as usual, it shouldn't matter if implementation is Camel or any other >>>> Java >>>> code. You can choose to specify the Camel's routes in a java class or >>>> a >>>> Spring configuration file and use that inside your SCA component. >>>> Camel >>>> itself is just a JAR file you have to include in your (not sure about >>>> the >>>> terminology either) SCA composite. It shouldn't be too hard to have >>>> synchronous execution in Camel -- just avoid the typical asynchronous >>>> concepts as seda: endpoints and you should be fine there. >>>> >>>> Suppose we would build a more specific implementation.camel for Apache >>>> Camel, what additional features would you expect from that >>>> implementation? >>>> >>>> >>>> Gert >>>> >>>> >>>> >>>> Vasil wrote: >>>> >>>>> >>>>> Hi Willem, >>>>> >>>>> I was thinking for using the route and pattern description power of >>>>> Camel >>>>> inside an SCA component for a more declarative description of >>>>> integration >>>>> scenario between services to which this component refers. I could have >>>>> used >>>>> BPEL or BPMN for example but this is rather complex and >>>>> procedural-oriented, >>>>> while I need mainly transformation capabilities with simple conditions >>>>> (content-based router), split, agregate, filter, transform (XQuery for >>>>> example), etc. in more data-oriented scenario. >>>>> In this case the different connectivities (components) that Camel >>>>> provides >>>>> will not be needed as SCA cares for this and also anly synchronous >>>>> working >>>>> of the Camel engine will be used. >>>>> >>>>> Do you think this is feasible usage of Camel? >>>>> >>>>> Bye, Vasil >>>>> >>>>> >>>>> willem.jiang wrote: >>>>> >>>>> >>>>>> >>>>>> Hi Vasil, >>>>>> >>>>>> AFAIK , we do not have any plan to integrate Camel with SCA. But you >>>>>> could share you ideas with us in the mail list :) >>>>>> >>>>>> Willem >>>>>> >>>>>> Vasil wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Is there any integration between Camel and SCA planned. If yes, can >>>>>>> you >>>>>>> share some more information. >>>>>>> >>>>>>> Bye, Vasil >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > -- View this message in context: http://www.nabble.com/Camel-and-SCA-tp17335281s22882p17420687.html Sent from the Camel - Development mailing list archive at Nabble.com.
