Nice diagrams.
We probably should call it something else (such as Invocation Handler
Extensibility) as it really goes beyond data transformation.
Thanks,
Raymond
From: Simon Laws
Sent: Wednesday, August 27, 2008 11:13 AM
To: [email protected]
Subject: Re: Tuscany data binding framework enhancements
On Wed, Aug 27, 2008 at 5:55 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I guess the key is to define the extensibility on the edges of invocation
chains. For reference binding or component implementation, the invoker is
transforming the SCA messages into native messages (such as JMSMessage, JCA
CCI Record, or SOAPEnvelope). For service binding, the binding listener is
responsible for bridging the native messages into SCA messages. In the
middle, we have the invocation chains that consist of Interceptors that deal
with SCA messages only. The pipelines are illustrated below.
Reference Binding and Implementation
Data: ------ SCA
Message --------- ------------------------------------ Native
Message ----------------------------------------------------------------------------------------
Invocation: Interceptor...Interceptor... Invoker ... (Some code to deal
with the transformation from SCA message to binding/implementation specific
message)
Service Binding
Data: -- Native
Message ----------------------------------------------------------------------------------------------------------------------------------------
-- SCA Message ---
Invocation: Binding Listener... ... (Some code to deal with the
transformation from SCA message to binding/implementation specific
message)...Interceptor ... Invoker
One idea is that we could wrap the native message into SCA message with the
body set to the native message. This way, we can just contribute Inteceptors
to deal with the native messages. For example, in the JMSBinding case, we
could have FunctionSelector (maps the JMS message to an operation) and
MessageMapper (unpack/pack the JMSMessage from/to SCA payload). The
inteceptors that deal with native messages can be positioned to phases next
to the bindings. The new picture can be:
----------------------- native JMS
------------------- ----------------------- SCA message with normalized
payload -----------------
JMSListener --> FunctionSelector --> MessageMapper --> Other Interceptors
..............................................................................
--- SCA Message --- ----------------------- native JMS
Message -----------------
MessageMapper --> JMS Binding Invoker
Thanks,
Raymond
From: ant elder
Sent: Wednesday, August 27, 2008 2:15 AM
To: [email protected]
Subject: Tuscany data binding framework enhancements
While working on the JMS binding I've been wondering if we could enhance the
current data binding framework to provide more APIs which a binding could
use help with the process of conversion to/from Tuscany messages to protocol
specific messages. I don't have a completely clear idea of what this would
look like yet but it would be things like doing operation selection and
transformation of the message body to/from protocol specific headers and
payloads. The JMS binding currently has a JMSMessageProcessor which does
some of this but it seems like it might be better if more could be done by
the data binding framework to replace that and to come up with a more
standard and consistent approach that we could use across all extensions and
using the new <databinding> scdl element being discussed by the spec group.
Does anyone else have any ideas on this or are interested in help looking at
this area?
...ant
I'm still mulling over Raymond's suggestion but I'm interested in this and
I'd like to throw a couple of things in the ring. Firstly I kicked of a page
on the wiki [1] for collecting together info on this subject. I've put up a
couple of diagrams that give me (at least) a little background.
The second point is slightly tangential. I'm looking at policy things at the
moment and that can also add reference and service policy providers to the
wire chain so having access to the native message could be useful. We will
also need to be able to plug in binding specific policy processing which is
slightly different but I'll keep these items on the table for now in case
there is synergy.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Plugability
