kitplummer (im)Agreed...and I believe based on my limited knowledge of
Tuscany that updating the TuscanyRuntime to be able to deploy a SCA POJO
should be straight forward - and simpler with the EmbeddedSCADomain.
I also agree on the tooling to provide the mapping between an SCA
Composite to a JBI integration based on the included SCA bindings. This
is definitely a sporty undertaking though. But, it could be a key
discriminator (from a "selling" SM perspective).
I believe we're all on the same page.
Kit
Guillaume Nodet wrote:
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
>>
>>
>
>
