On Wed, Aug 27, 2008 at 7:39 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> 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 > I've added some JMS specific scenarios to the wiki page (which has moved to http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Plugability+and+Native+Message+Processing ). ...ant
