I do think we need a SE like servicemix-sca (should be renamed to servicemix-tuscany i guess) to host the Java annotated SCA pojo. I see the translation between the SCA assembly to a JBI assembly as something somewhat independant from ServiceMix core that could be reused either at the tooling side, as a command line tool (maven ?) or at runtime in ServiceMix.
The SCA annotated POJOs are just one model amongst several that SCA can support. I'm sure we could define a profile for JAX-WS / EJB3 that we could deploy on servicemix-cxf-se (when it supports EJB3 ;-) ). But we need both to support standard SCA deployments: a SE for SCA annotated POJOS and a translation layer to translate the SCA assembly to a JBI Service Assembly. But your assumptions are right about how to handle that: an implementation.bpel would be translated into a SU for Ode, same for POJOs. In addition several SUs targeted at BCs need to be generated for HTTP/SOAP wires ... Not sure if this is more clear. This is of course subject to discussion, but given my understanding of JBI and SCA, this the best solution I came up with. Any feedback is welcome. 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 >> >> > >
-- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
