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