That would be good, there's probably things we could do for databindings as
hinted by Dave in this thread but to start with section 1.6 of the spec does
define a little:

240 <bindingType type="binding.jms"
241                     alwaysProvides="jms"
242                     mayProvide="atLeastOnce atMostOnce ordered
conversation"/>

So how about we get those first few mayProvides going?

   ...ant

On Feb 13, 2008 6:14 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> Hi Ant,
>
> How about bringing in some policy handling into our JMS binding ?  We
> could
> pick some non-functional characteristic that is typical with use of
> messaging.  I am not sure what that could be - is it message encryption ?
>
> If you can help a bit with the things to be done from the JMS side, I will
> take care of all that might need to come from the PolciyFwk side. ?
>
> Thoughts ?
>
> Thanks
>
> - Venkat
>
>
>
> On Feb 12, 2008 11:34 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
>
> > Great, thanks Ant - I shall take a look and see :)
> >
> > On Feb 12, 2008 6:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi All,
> > > >
> > > > I'm trying to ascertain whether it is possible to specify a
> policySet
> > > > applied to a service which would allow us to replace or augment the
> > > > data binding?
> > > >
> > > > The rationale behind this is that we're trying to use a legacy JMS
> > > > system as a binding.jms reference, but the TextMessage payload is
> > > > marked up in XML and we don't have the ability to change the
> > > > interface/implementation of this system to be able to strip off/pad
> > > > the xml as appropriate.
> > > >
> > > > Is this possible?  Or is there another option that would allow me to
> > do
> > > > this?
> > > >
> > > > Cheers,
> > > >
> > > > Dave.
> > > >
> > >
> > > There's no official way to do what you want, all the JMS binding spec
> > says
> > > about this is:
> > >
> > > "231 To support any other type of JMS message, the SCA runtime should
> > > provide the means for supplying and identifying alternative data
> binding
> > > behaviors."
> > >
> > > In early drafts of the spec there was a description of a Message
> > processing
> > > component that provided this but it got removed. We still have some of
> > the
> > > code for supporting those early drafts still left in the jms binding
> > though
> > > and i've just committed a change to make it available again from a
> > composite
> > > so you could try that to see if it does what you need and help us come
> > up
> > > with a good way to do this. This current code adds a
> "messageProcessor"
> > > attribute to the JMS binding scdl, that class must implement the
> > > MessageProcessor interface which gives access to the JMS message to
> > fiddle
> > > with the payloads during the invocation. There's a testcase
> > demonstrating
> > > this at:
> > >
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite
> > >
> > > This is all completely open to change to architect a better, more
> > complete
> > > solution, so if you could try this out and provide feed back that
> would
> > be
> > > great as this seems like this will be quite a common thing to want to
> > do.
> > >
> > >    ...ant
> > >
> >
> >
> >
> > --
> > Dave Sowerby MEng MBCS
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Reply via email to