jpdl and sca tuscany integration - any?

[radu3000]

Hello,

In my poc I have implemented a soa reference set of apps in two ways:
1 - using sca tuscany.
2 - using jpdl runtime library.

Both products use dependency injection - however for different scopes. SCA emphasis is on service component assembly where jpdl is on the process. However jpdl does a bit of component assembly as well - not at the sca level.

Here is a suggestion - why not leverage sca tuscany assembly model for referencing sca components under actions? Ideally a process definition xml can import .composite file and concentrate purely on bpm - that is what it can do best, right?

Albeit - I am not the only one seeking this ....

Regards,
Radu.

[kukeltje]

- jpdl is not targeted at component assembly, it is targeted at BPM.
- sca is incubator
- it is number x in the line of apache esb/soa/.... projects

why not use jboss ESB with jpdl in it?

Albeit - I am not the only one seeking this ....

How do you know?

[tom.baeyens]

what i understood from sca is that it is a component model so that components can be written in different languages and wired together on the sca level.

but i am not aware that SCA also has an API that we can use so that I can programmatically call an SCA component.

the other way round could also be interesting. if we can define the ins and outs of a jpdl process properly in the SCA way, then the jpdl process could be used in a SCA assembly.

i can see these things conceptually, but i don't know how much work it would take to actually do it.

[radu3000]

Tom,

Thanks for your reply.

In the end it boils down to the age old question: what is first chicken or the egg? Process importing components or components importing process.

Let's take the approach of process importing components - chicken first. Given the current process fragment:




I could change it to:
-----------
import ..\sca\ConsumerFacade.composite
...

<action sca-component-reference="RequestParser"/>


-----------
And done! Isn't this a cleaner separation of process and assmbly responsibility? With a bit more work to integrate an sca tuscany runtime and jpdl runtime - there is so much to gain! JPDL can tap into any (almost any - sca component types are constantly growing ...) type of components defined in sca. The component impls would also implement ActionHandler - easy right?

The SCA api is straight forward:
// line below can be triggered by the above
// "import ..\sca\ConsumerFacade.composite" statment
scaDomain = SCADomain.newInstance("ConsumerFacade.composite");

// line below is triggered when you need the action to be executed
requestParserService = scaDomain.getService(RequestParserImpl.class, "RequstParserComponent");

So what is left?
1. Change jpdl schema to allow:
<action sca-component-reference="RequestParser"/>
2. Make some room in jpdl api to allow references to scaDomain.getService(...) calls.

I would be glad to contribute some time to the above.

Regards,
Radu Marian

[radu3000]

Tom,

Thanks for your reply.

In the end it boils down to the age old question: what is first chicken or the egg? Process importing components or components importing process.

Let's take the approach of process importing components - chicken first. Given the current process fragment:

<node name="Parse service request">
 <action class="com.bofa.crme.gps.servlet.RequestParserImpl"/>
 <transition name="next" to="Transform GCIB request to WCC request"/>
 </node>

I could change it to:

import ..\sca\ConsumerFacade.composite
...
 <node name="Parse service request">
 <action sca-component-reference="RequestParser"/>
 <transition name="next" to="Transform GCIB request to WCC request"/>
 </node>

And done! Isn't this a cleaner separation of process and assmbly responsibility? With a bit more work to integrate an sca tuscany runtime and jpdl runtime - there is so much to gain! JPDL can tap into any (almost any - sca component types are constantly growing ...) type of components defined in sca. The component impls would also implement ActionHandler - easy right?

The SCA api is straight forward:

// line below can be triggered by the above
// "import ..\sca\ConsumerFacade.composite" statment
 scaDomain = SCADomain.newInstance("ConsumerFacade.composite");

// line below is triggered when you need the action to be executed
 requestParserService = scaDomain.getService(RequestParserImpl.class, "RequstParserComponent");

So what is left?
1. Change jpdl schema to allow:

<action sca-component-reference="RequestParser"/>

2. Make some room in jpdl api to allow references to scaDomain.getService(...) calls.

I would be glad to contribute some time to the above.

Regards,
Radu Marian