Completely agree. We'll need a means of running the annotated java as well as the translation layer.
So, lets assume for now we need a servicemix-tuscany SE, and a sca-jbi-translation plugin for maven. (just so it is easier to talk about) With respect to the <implementation.jbi/>, i haven't completely thought it through yet, but I don't think it raises JBI quite to the level of SCA because it would be an SCA component implementation, on par with the other component implementations (e.g. BPEL, EJB and JMS). This would establish the same relationship between SCA and JBI as exists between JMS or EJB and JBI (positioning JBI as a lower level "implementation" construct). I understand your concerns though, and haven't yet decided whether or not an <implementation.jbi/> would be a good thing -- or even useful. -brian On 6/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
On 6/28/07, Brian O'Neill <[EMAIL PROTECTED]> wrote: > > 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. See my reply to Gert. I do think we need both a component (that could be use without a SCA assembly) and a translation layer. Having a component that can support deployment of SCA assemblies is not a good idea imho, as it will not leverage JBI components: I think all SOAP/HTTP calls should go through the HTTP/SOAP BC, and the only real way to do that is to deploy a SU onto the BC (hence the need for a translation layer). 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 don't really understand the purpose of this one. JBI is really about the ability to plugin different components that can easily work together, the common packaging model and management. These are not concerns to SCA at all. I don't see the benefit of bringing the JBI stuff at the user level. Can you explain a bit more on what it would mean to have a implementation.jbi ? Imho, this would bring JBI at the same level than SCA, whereas I think JBI should be below SCA, providing the infrastructure where to deploy a SCA application. 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 > -- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
-- 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
