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
[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
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
