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