Re: servicemix-sca: updating tuscany dependency
Just an update I put a diagram, and a little more text up on: http://www.jbizint.org/wiki/index.php?title=SCA To keep things focused, I deleted the verbage around a potential SCA JBI component implementation. I added a diagram and Jean-Sebastien's BigBank example (with a few alterations) Kit and I created a page for the serivcemix-java-sca component: http://www.jbizint.org/wiki/index.php?title=Servicemix-java-sca As you can see, we're going to keep the component in a side repo until we have it working, but we'll build it in the servicemix build structure under deployables/serviceengines. So, it will be able to drop right in when we have it working. best regards, brian On 6/29/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 6/29/07, Brian O'Neill [EMAIL PROTECTED] wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Sure, though I would have started with something more simple like servicemix-saxon, but servicemix-bean is closer I guess but more complicated. Anyway, I you have any questions, feel free to ask. Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] 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? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- 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
Re: servicemix-sca: updating tuscany dependency
Sounds good. If you already have something set up...that's fine with me. Kit Brian O'Neill wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] 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? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- Jean-Sebastien
Re: servicemix-sca: updating tuscany dependency
On 6/29/07, Brian O'Neill [EMAIL PROTECTED] wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Sure, though I would have started with something more simple like servicemix-saxon, but servicemix-bean is closer I guess but more complicated. Anyway, I you have any questions, feel free to ask. Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] 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? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- 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/
Re: servicemix-sca: updating tuscany dependency
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
Re: servicemix-sca: updating tuscany dependency
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/
Re: servicemix-sca: updating tuscany dependency
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
Re: servicemix-sca: updating tuscany dependency
[snip] 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? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- Jean-Sebastien
Re: servicemix-sca: updating tuscany dependency
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
Re: servicemix-sca: updating tuscany dependency
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 :) --
Re: servicemix-sca: updating tuscany dependency
[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
Re: servicemix-sca: updating tuscany dependency
Kit Plummer Advanced Programs Raytheon Missile Systems 520.360.4729 (cell) 520.545.9346 (desk) kitplummer (im)Thanks again Jean-Sebastian. At this point I think Guillaume is correct - we need to look at the SE. I'm _guessing_ that the current TucsanyRuntime class gets simplified, or replaced by the use of EmbeddedSCADomain. I'm tied up for the next few days - but, will hopefully get some free time to dig a bit deeper... Kit Jean-Sebastien Delfino wrote: [snip] Kit Plummer wrote: Guillaume, I think we figured out how to build/install the latest Tuscany, referencing it from the servicemix-sca pom.xml. I'm sure by the time we have this stuff straight Tuscany will be at 1.0 - or so. ;} On to the problem of getting up-to-date with Tuscany. The existing test case instantiates a TuscanyRuntime, which doesn't appear to be the way to do it anymore... Jean-Sebastian, do you think we can just mimic the sca/itest/interop-xsq-client/src/test/java/interop/ClientTestCase.java to get a runtime environment? Thanks for your effort, BTW. Kit interop-xsq-client is old stuff, not part of the build at the moment, I just moved it out to an itest/old directory to make this more clear. I'd suggest to start with these samples: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/ Booting an SCA runtime and domain is much simpler now, here's the test case from the calculator sample: ** * This shows how to test the Calculator service component. */ public class CalculatorTestCase extends TestCase { private CalculatorService calculatorService; private SCADomain scaDomain; protected void setUp() throws Exception { scaDomain = SCADomain.newInstance(Calculator.composite); calculatorService = scaDomain.getService(CalculatorService.class, CalculatorServiceComponent); } protected void tearDown() throws Exception { scaDomain.close(); } public void testCalculator() throws Exception { // Calculate assertEquals(calculatorService.add(3, 2), 5.0); assertEquals(calculatorService.subtract(3, 2), 1.0); assertEquals(calculatorService.multiply(3, 2), 6.0); assertEquals(calculatorService.divide(3, 2), 1.5); } } If SCADomain does not provide the level of flexibility you need, try EmbeddedSCADomain. A test case showing how to use it is there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/sca/host/embedded/impl/EmbeddedSCADomainTestCase.java
Re: servicemix-sca: updating tuscany dependency
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. On 6/26/07, Brian ONeill [EMAIL PROTECTED] wrote: Jean-Sebastien / Guillaume, I'm about to delve into the tests for servicemix-sca. As expected, they are failing out of the box. The tests are throwing NPEs down in the tuscany code (JavaContextFactoryBuilder). To make progress, I'd like to either upgrade the dependency, or grab the source for the version of tuscany that the component is presently using: tuscany_version20060317/tuscany_version Jean-Sebastien, can you recommend a stable branch to move to? Guillaume, any suggestions? -brian Kit Plummer wrote: Hey guys. Here's the direct link to the use case that Brian referenced: http://www.jbizint.org/wiki/index.php?title=SCA_translation_layer I like the target of deploy this SCA contribution to ServiceMix. Kit Brian ONeill wrote: Jean-Sebastien, It is a pleasure meeting you. Yes. I/we was/were thinking exactly along those lines. In fact, I have a nearly identical example / write-up here: http://www.jbizint.org/wiki/index.php?title=SCA_Service_Engine I appreciate all the input. Kit Plummer and I are trying to resurrect the engine and build on what Guillaume has put in place. I hope to get back to this today and will let you know when we have updates. best regards, brian Jean-Sebastien Delfino wrote: Guillaume Nodet wrote: Hi Jean-Sebastien ! The tuscany SE, as you said, is very old, and has never been finished (that's why it is in the sandbox). The idea was to be able to deploy SCA annotated POJOs onto it and leverage Tuscany to host them. I think there are some areas where I'd need a few explanations (see below). We're investigating how SCA and JBI can be bridged. I'm thinking that one way is to think about SCA as a development designer and JBI as the runtime. So one goal is to investigate how we could transform an SCA assembly into a JBI Service Assembly: each java component would be deployed onto the afore mentionned Service Engine, a bpel implementation could be deployed onto the Ode Service Engine (etc...) while wires / bindings would lead to several Service Units for Binding Components (HTTP, JMS, etc...). Yes, makes sense. To make sure that I got what you said right, let's use an example to illustrate the approach. Here's an SCA composite describing a simple banking app, made of: - a Java component providing account data - a BPEL component implementing an Account service - a StockQuote reference with a Web Service binding used to get the price of the stock in your account - a JSON RPC binding providing the Account service to JSON clients ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://mybank; xmlns:b=http://mybank; name=MyBank service name=AccountJSONService promote=AccountServiceComponent interface.java interface=bigbank.account.AccountService/ binding.jsonrpc/ /service component name=AccountServiceComponent implementation.bpel process=b:AccountProcess/ reference name=accountDataService target=AccountDataServiceComponent/ /component component name=AccountDataServiceComponent implementation.java class=mybank.AccountDataImpl/ /component reference name=StockQuoteReference promote=AccountServiceComponent/stockQuoteService binding.ws wsdlElement= http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference /composite As an application developer, I write an SCA composite assembly, the Java class and BPEL process, use the WSDL I got for the StockQuote Web service. Then I package all these artifacts in an SCA contribution (a form of archive described in the SCA spec). When I deploy this SCA contribution to ServiceMix: - The Java component gets deployed to a Java SCA Service Engine that supports the SCA API and Annotations. - The BPEL component gets deployed to a BPEL Service Engine. The BPEL accountDataService partner links gets bound as described in the SCA composite. - The StockQuoteReference and AccountJSONService get deployed to corresponding ServiceMix Binding Components, configured as described in the SCA composite. So, at development time, the application developer uses the SCA programming model, at deployment time most of the SCA metadata gets converted to JBI/ServiceMix configuration, at run time a mix of SCA metadata and ServiceMix configuration is used. Where you
Re: servicemix-sca: updating tuscany dependency
Guillaume, I think we figured out how to build/install the latest Tuscany, referencing it from the servicemix-sca pom.xml. I'm sure by the time we have this stuff straight Tuscany will be at 1.0 - or so. ;} On to the problem of getting up-to-date with Tuscany. The existing test case instantiates a TuscanyRuntime, which doesn't appear to be the way to do it anymore... Jean-Sebastian, do you think we can just mimic the sca/itest/interop-xsq-client/src/test/java/interop/ClientTestCase.java to get a runtime environment? Thanks for your effort, BTW. Kit 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. On 6/26/07, Brian ONeill [EMAIL PROTECTED] wrote: Jean-Sebastien / Guillaume, I'm about to delve into the tests for servicemix-sca. As expected, they are failing out of the box. The tests are throwing NPEs down in the tuscany code (JavaContextFactoryBuilder). To make progress, I'd like to either upgrade the dependency, or grab the source for the version of tuscany that the component is presently using: tuscany_version20060317/tuscany_version Jean-Sebastien, can you recommend a stable branch to move to? Guillaume, any suggestions? -brian Kit Plummer wrote: Hey guys. Here's the direct link to the use case that Brian referenced: http://www.jbizint.org/wiki/index.php?title=SCA_translation_layer I like the target of deploy this SCA contribution to ServiceMix. Kit Brian ONeill wrote: Jean-Sebastien, It is a pleasure meeting you. Yes. I/we was/were thinking exactly along those lines. In fact, I have a nearly identical example / write-up here: http://www.jbizint.org/wiki/index.php?title=SCA_Service_Engine I appreciate all the input. Kit Plummer and I are trying to resurrect the engine and build on what Guillaume has put in place. I hope to get back to this today and will let you know when we have updates. best regards, brian Jean-Sebastien Delfino wrote: Guillaume Nodet wrote: Hi Jean-Sebastien ! The tuscany SE, as you said, is very old, and has never been finished (that's why it is in the sandbox). The idea was to be able to deploy SCA annotated POJOs onto it and leverage Tuscany to host them. I think there are some areas where I'd need a few explanations (see below). We're investigating how SCA and JBI can be bridged. I'm thinking that one way is to think about SCA as a development designer and JBI as the runtime. So one goal is to investigate how we could transform an SCA assembly into a JBI Service Assembly: each java component would be deployed onto the afore mentionned Service Engine, a bpel implementation could be deployed onto the Ode Service Engine (etc...) while wires / bindings would lead to several Service Units for Binding Components (HTTP, JMS, etc...). Yes, makes sense. To make sure that I got what you said right, let's use an example to illustrate the approach. Here's an SCA composite describing a simple banking app, made of: - a Java component providing account data - a BPEL component implementing an Account service - a StockQuote reference with a Web Service binding used to get the price of the stock in your account - a JSON RPC binding providing the Account service to JSON clients ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://mybank; xmlns:b=http://mybank; name=MyBank service name=AccountJSONService promote=AccountServiceComponent interface.java interface=bigbank.account.AccountService/ binding.jsonrpc/ /service component name=AccountServiceComponent implementation.bpel process=b:AccountProcess/ reference name=accountDataService target=AccountDataServiceComponent/ /component component name=AccountDataServiceComponent implementation.java class=mybank.AccountDataImpl/ /component reference name=StockQuoteReference promote=AccountServiceComponent/stockQuoteService binding.ws wsdlElement= http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference /composite As an application developer, I write an SCA composite assembly, the Java class and BPEL process, use the WSDL I got for the StockQuote Web service. Then I package all these artifacts in an SCA contribution (a form of archive described in the SCA spec). When I deploy this SCA contribution to ServiceMix: - The Java component gets deployed to a Java SCA Service Engine that supports the SCA API