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








Reply via email to