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_version>20060317</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 thinking along the same lines? >>> >>>> >>>> So I have a few questions that you may help answering: >>>> * where does SDO comes in ? is it mandatory, optional, unspecified ? >>> >>> An SCA component can use (and flow on its business methods) simple Java >>> types, complex Java types, or any Java data binding technology that's >>> convenient for it to use, including Axiom, XMLBeans, SDO, JAX-WS etc. >>> >>> Some binding technologies come with a databinding baggage, for example >>> Axis2 will present the data using Axiom. >>> >>> Same for some component implementation support runtimes, for example >>> the >>> Bean Scripting Framework uses Axiom (if I remember correctly), BPEL/ODE >>> uses DOM etc. >>> >>> To save a Java application developer to have to know 5 different >>> databinding technologies just to put 3 or 4 business components >>> together >>> and talk to a SOAP or JSON service... Tuscany provides a data binding >>> transformation capability, handling the necessary conversions between >>> the databindings automatically, as long as the supporters of particular >>> databindings provide us with the right transformers. >>> >>> We currently support transformations between Axiom, SDO, Jax-WS, JSON, >>> and XMLBeans. However I'd recommend to not go crazy with >>> databindings in >>> a single application and try to stick to one or two to avoid any >>> surprises, since none of these databindings are perfect... >>> >>>> * how is the mapping between the soap call and the java method >>>> invocation specified ? >>>> I know how JAX-WS can be used to specify the web methods, xml >>>> mapping, but how can >>>> you configure this in SCA ? >>> >>> The mapping depends on which databinding you're using. If you're using >>> JAX-WS, its mapping rules will be used, if you're using SDO, the data >>> mapping is defined by the SDO spec, if you're using Axiom, well... >>> everything maps to an Axiom element :) >>> >>> If your service interface is a Java interface, we'll introspect it to >>> figure which databinding you're using. >>> >>> You can also declare the databinding in your SCA composite assembly, >>> when there is no Java interface to introspect for example, like this: >>> <reference name="EchoReference" promote="ComponentB/echoReference"> >>> <interface.wsdl >>> interface="http://example.com/echo.wsdl#wsdl.interface(EchoPortType)" >>> wsdli:wsdlLocation="http://example.com/echo.wsdl >>> wsdl/echo.wsdl"> >>> <db:databinding >>> xmlns:db="http://tuscany.apache.org/xmlns/sca/databinding/1.0"; >>> name="org.apache.axiom.om.OMElement" /> >>> </interface.wsdl> >>> <e:binding.echo/> >>> </reference> >>> >>>> This is also needed when you want to >>>> translate a java call >>>> to an xml invocation (when using client proxies / references to >>>> other >>>> components). >>>> >>> >>> I didn't quite get that part. If your SCA component is a Java >>> component, >>> and as an application developer you just want to use Java interfaces >>> and >>> don't know anything about WSDL or XSD, I guess you shouldn't have to >>> know that the underlying runtime infrastructure uses XML to transport >>> your business data, but I'm not sure I understand the scenario you're >>> talking about here... >>> >>>> >>>> On 6/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Guillaume Nodet wrote: >>>>> > Copying tuscany dev list ... >>>>> > >>>>> > On 6/22/07, Bruce Snyder <[EMAIL PROTECTED]> wrote: >>>>> >> >>>>> >> On 6/22/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>>>> >> > Thanks, great work ! >>>>> >> > >>>>> >> > Sorry about these problems, but I guess this is a direct >>>>> >> consequence of >>>>> >> it >>>>> >> > being sandboxed :-( >>>>> >> > So you'll find that the SE is not complete, but the idea was to >>>>> >> implement a >>>>> >> > JBI binding for tuscany >>>>> >> > so that you can deploy SCA annotated POJOs on this SE. IIRC, >>>>> the >>>>> >> provider >>>>> >> > part was working >>>>> >> > somewhat but I think the consumer part is missing (being able >>>>> to call >>>>> >> > external services through java >>>>> >> > proxies). >>>>> >> > >>>>> >> > I guess I stopped because I did not completely understood how >>>>> the xml >>>>> >> > mapping and java / wsdl >>>>> >> > mapping were to be written. While I see how JAX-WS works, >>>>> there is >>>>> >> > something that have escaped >>>>> >> > me somehow with SCA (or maybe this isn't specified and that >>>>> could >>>>> >> be the >>>>> >> > reason I did not found it). >>>>> >> >>>>> >> We should invite some Tuscany folks to discuss this topic so we >>>>> can >>>>> >> work though it. Is anyone subscribed to the Tuscany dev list >>>>> already >>>>> >> who can CC that list? I'm at a client site right now and don't >>>>> have >>>>> >> the time to do it ATM. >>>>> >> >>>>> >> Bruce >>>>> >> -- >>>>> >> perl -e 'print >>>>> >> >>>>> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" >>>>> >> );' >>>>> >> >>>>> >> Apache Geronimo - http://geronimo.apache.org/ >>>>> >> Apache ActiveMQ - http://activemq.org/ >>>>> >> Apache ServiceMix - http://servicemix.org/ >>>>> >> Castor - http://castor.org/ >>>>> >> >>>>> >>>>> Hi, >>>>> >>>>> I work on Tuscany, I may be able to help with some of these >>>>> questions :) >>>>> >>>>> The servicemix-sca module under [1] seems to use an old level of >>>>> SCA and >>>>> Tuscany. The SCA programming model and the Tuscany SCA SPIs have >>>>> evolved >>>>> since then but they are pretty stable now so it might be the right >>>>> time >>>>> to port servicemix-sca to SCA 1.0 and the Tuscany 0.90 release (or >>>>> the >>>>> upcoming 0.91 release, which provides the same SPIs). >>>>> >>>>> Do you have specific Tuscany or SCA questions that we can help with? >>>>> >>>>> Could you describe the type of application and scenario supported by >>>>> servicemix-sca? Is there a sample showing how an application >>>>> developer >>>>> will use Tuscany and ServiceMix together? >>>>> >>>>> >>>>> [1] >>>>> >>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/sandbox/servicemix-sca/ >>>>> >>>>> >>>>> -- >>>>> Jean-Sebastien -- Brian ONeill Founder, Source Equity (http://www.sourceequity.com) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
-- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
