Raymond,
Thanks for the answers.
So in the absence of the annotation and the databinding element in the SCDL
what should be the expected behaviour?
Thanks,
Rajith
On 9/20/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Each DataType has a databinding (id) which identifies the format of the
data. The databinding information is either from java annotations or SCDL
extensions.
@DataType(name="org.apache.axiom.om.OMElement")
or
<interface.wsdl ...>
<db:databinding
xmlns:db=http://tuscany.apache.org/xmlns/sca/databinding/1.0
name="commonj.sdo.DataObject"/>
</interface.wsdl>
Basically, the types are expressed by the applications at
interface/operation (potentially parameter) level. We can also
heuristically
introspect the data types (to be done).
Thanks,
Raymond
----- Original Message -----
From: "Rajith Attapattu" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 20, 2006 9:29 AM
Subject: Re: Question on databinding framework
> Raymond,
>
> How does the DatabindingInterceptor recognize the source data type and
> target data type?
> Does the databinding registry checks to see if it's a recognizable data
> type
> by pushing it through the avaialable transformers untill on of them
> recognizes the format?
>
> Regards,
>
> Rajith
>
> On 9/18/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi, Rajith.
>> >
>> > Your questions are just in time. I just reached a point that the
>> > databinding
>> > framework works with the Axis2 binding (Axiom) end-to-end. I'm
planning
>> > to
>> > put together a document to describe how the framework works and how
you
>> > can
>> > plug in extensions.
>> >
>> > Let me try to give you some breif answers first. Please see the
>> > comments
>> > below.
>> >
>> > Thanks,
>> > Raymond
>> >
>> > ----- Original Message -----
>> > From: "Rajith Attapattu" < [EMAIL PROTECTED]>
>> > To: <[email protected]>
>> > Sent: Monday, September 18, 2006 3:23 PM
>> > Subject: Re: Question on databinding framework
>> >
>> >
>> > > Hi,
>> > >
>> > > I would really appreciate if somebody can answer the following
>> > questions
>> > > regarding the data binding framework.
>> > >
>> > > 1. Is DataBindingInteceptor the only interceptor in the chain that
>> > deals
>> > > with data transformation?
>> > >
>> >
>> > Yes. DataBindingInterceptor(s) are added to the wiring to transform
>> > data
>> > between two mappable (compatible but with different databindings)
>> > ServiceContract/Operation(s).
>> >
>> > > 2. The DataBindingInteceptor has a mediator associated with it to
>> > > transform
>> > > the data. The current mediator has a list of Transformers that act
on
>> > the
>> > > data.
>> > > Is my understanding correct?
>> >
>> > Yes, you're right. Mediator is backed by registered DataBinding(s)
and
>> > Transformer(s). It figures a path (potentially multiple hops) between
>> > the
>> > source and target and flow source data over the path so that it can
be
>> > converted to the target format.
>> >
>> > >
>> > > 3. As I see all transformers are categoried as either Pull or Push
>> > based.
>> > > What does this mean?
>> > >
>> >
>> > There are two types of transformations depending on the target side.
>> > Let's
>> > say a-->b, if b is something like a DOM Node, SDO DataObject, or
>> > XMLStreamReader, then it's a pull style because the data is pulled
from
>> > the
>> > source. If b is a data sink, for example, SAX ContentHandler,
>> > OutputStream,
>> > Writer, then it's a push style because the data is pushed into the
>> > target.
>> > Pull-style transformers can natually chained together to form a path.
>> > Push-style transformer can either be used to terminate the
>> > transformation or
>> > it's further piped by DataPipe (which uses the PushTransformer to
>> > populate
>> > data, for example, receive SAX events to create a SDO DataObject or
>> > DOM)
>> > so
>> > that the chain can continue.
>> >
>> > Examples:
>> >
>> > SDO --> XMLStreamReader --> DOM
>> > DOM --> SAX2SDOPipe (A ContentHandler provided by SDO) --> SDO
>> >
>> > > 4. How does all these fit into together? Like can I know the flow
>> > > when
>> > a
>> > > service is accessed or when we invoke on a reference?
>> > > For example what I am expecting is something like this. (I am
>> > familliar
>> > > with axis2, so let me use that as most of u guys are also familliar
>> > with
>> > > axis2)
>> > >
>> > > SOAP msg --> TransportListerner --> in Handler chain -->
>> > MessageReceiver
>> > > --> Service implementation or your Bizz logic
>> > >
>> > > Service Impl --> MessageReceiver --> out Handler chain -->
>> > > TransportSender --> SOAP msg
>> > >
>> > > A flow diagram (simillar to above) of how Tuscant handles a service
>> > > invocation and invoking a reference is very helpfull.
>> > >
>> >
>> > Reference flow: Caller Component --|1|--> Tuscany SCA Reference with
>> > Axis2
>> > binding --|2|--> Axis2 Client (AXIOM) --> SOAP/HTTP
>> >
>> > |1|: DataBindingInterceptor converts the invocation message from the
>> > caller
>> > component format to AXIOM.
>> >
>> > |2|: During "build" phase, the Reference binding builder should make
>> > sure
>> > the WSDL portType (if exists) used by the web service is mappable to
>> > the
>> >
>> > interface declared inside the <reference> or derive the WSDL from
other
>> > IDLs
>> > such as Java interface.
>> >
>> > Service flow: SOAP/HTTP --> Axis2Servlet (AXIOM) --|1|--> Message
>> > receiver
>> > provided by Tuscany SCA Axis2 Service (WSDL portType) ---|2|--> Wired
>> > component (Java interface with SDO or JAXB).
>> >
>> > |1|: During "build" phase, the Service binding builder should make
sure
>> > the
>> > WSDL portType (if exists) used by the web service is mappable to the
>> > interface declared inside the <service> or derive the WSDL from other
>> > IDLs
>> > such as Java interface.
>> >
>> > |2|: DataBindingInterceptor converts the invocation message from
AXIOM
>> > to
>> > the target component format.
>> >
>> > > Thanks in advance,
>> > >
>> > > Rajith.
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
