Gert, Correct. What we've been discussing most recently is the SCA translation layer that would convert the lingo as you described. I wouldn't even call this a component.
The second approach I believe also works (creating an SCA SE), but I think we believe the SCA translation layer would provide the most value. FWIW, I think there is a third approach: to create a a SCA component implementation specification for JBI. (e.g. introduce an implementation.jbi element into SCA contributions) I tried to outline the different strategies here: http://www.jbizint.org/wiki/index.php?title=SCA best regards, -brian On 6/28/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote:
L.S., Just trying to grasp what the problem/question is... So, if I understand correctly, the servicemix-sca component will be somewhat different from any other JBI component. We won't be building an SCA container as a service engine (like you would do for e.g. EJBs), but rather build some kind of support for deploying SCA artifacts directly on ServiceMix. In order to do this, the 'metadata' that is available in the SCA artifact (sorry for not using the correct terminology, definitely need to read up on SCA) needs to be translated into JBI lingo, e.g. if an SCA component with implementation.bpel is being deployed, it needs to be translated into a service unit, targeted at the Ode JBI SE? We are looking at the design some kind of SCADeploymentService, with translation plugins to enable translation from e.g. an SCA (implementation.bpel) -> ODE JBI SU... right? Gert Brian O'Neill wrote: > OK, per Guillaume's suggestion perhaps we start anew basing everything > on 0.90 sca. > > So, what are peoples thoughts towards the design of the translation > layer? > > Should we leverage Tuscany's parsing capabilities to read in the SCA > contribution? > Then, from the parsed structure generate the service-unit JBI artifacts? > Each type of implementation(e.g. implementation.bpel) will generate > different artifacts. So, this will need to be pluggable / extensible. > > Perhaps we start with Jean-Sebastien's example, then implement the > translation layer first? (independent of both tuscany and servicemix) > > What do people think? > > -brian > > > On 6/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> [snip] >> Guillaume Nodet wrote: >> > Jean-Sebastien said that the apis are quite stable now, so I guess >> > the best way would be upgrade to the latest released version. >> > Maybe Jean-Sebastien can provide more inforamtions here. >> > >> > Imo, the tuscany code has changed so much so that it may be >> > better to try uinderstanding how the SE works and maybe start >> > a new one (at least for the tuscany binding classes). >> > >> > As for the sources, I guess we should be able to find >> > a svn revision that would match the date somehow: >> > March the 17th 2006. >> > >> >> I'd recommend to use the Tuscany SCA 0.90 release and SDO 1.0 beta 1 >> levels... March 17th 2006 is more than a year ago :) >> >> -- >> Jean-Sebastien >> >> > >
-- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
