You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Rajith Attapattu (JIRA)" <tu...@ws.apache.org> on 2006/09/26 00:29:51 UTC
[jira] Updated: (TUSCANY-753) JMS Binding
[ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ]
Rajith Attapattu updated TUSCANY-753:
-------------------------------------
Attachment: jmsbinding_jira753_25sep06.patch
The basic design is as follows.
I have tried to follow the spec as much as possible eventhough it is still work-in-progress and unpublished.
A draft version will be published soon. I will update the ticket as soon as it's available.
For services
------------------
A Service proxy is created and published as a JMS listener to the specified queue.
the onMessage method will be the entry point.
For references
--------------------
A JMS message will be sent to the specified resource and a temp queue is created for the reply.
I would really appreciate some feedback after reviewing the code.
I will resend a final tested version ASAP.
Regards,
Rajith
> JMS Binding
> -----------
>
> Key: TUSCANY-753
> URL: http://issues.apache.org/jira/browse/TUSCANY-753
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core
> Reporter: Rajith Attapattu
> Attachments: jmsbinding_jira753_25sep06.patch
>
>
> Hi All,
>
> I have attached a patch for the JMS binding. By no means this is 100% complete.
> But I decided to post the source code so that others can have a look and comment on the direction and help out if there is something wrong.
> The unit tests are failing so I haven't attached the test code. JMS binding still has a dependency on SDO since I modeled it on the axis2 binding.
> However Raymond has changed that in axis2 and I am hoping to do the same soon.
>
> Please be kind enough to have a look and start a disucssion on how we can move this forward.
> Regards,
> Rajith
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 26, 2006, at 7:12 PM, Carl Trieloff wrote:
>
>>> Maybe we could also do a AMQP binding too for portability :-)
>>
> Will do, however I think it makes sense to work out some of the
> details with JMS in the next few days, before we add AMQP
> binding so that we can learn for it.
Yea that makes sense.
>> There's no guarantee that there is Java on the far end - JMS is
>> just the API at this end of the messaging infrastructure.
>>
> yip - However I would prefer to use XML in the first cut so that we
> can re-use it for AMQP binding - might be alternate motive but java
> serialization can always be added.
ditto on this too.
>
>> We really need to be able to serialize to any message form: XML,
>> Java serialization, various flavours of byte stream, user-defined
>> mechanisms. Hopefully by hooking this to the databinding framework
>> we can cover all these options.
> Yes, this a fully agree with...
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Carl Trieloff <cc...@redhat.com>.
>> Maybe we could also do a AMQP binding too for portability :-)
>
Will do, however I think it makes sense to work out some of the details
with JMS in the next few days, before we add AMQP
binding so that we can learn for it.
> There's no guarantee that there is Java on the far end - JMS is just
> the API at this end of the messaging infrastructure.
>
yip - However I would prefer to use XML in the first cut so that we can
re-use it for AMQP binding - might be alternate motive but java
serialization can always be added.
> We really need to be able to serialize to any message form: XML, Java
> serialization, various flavours of byte stream, user-defined
> mechanisms. Hopefully by hooking this to the databinding framework we
> can cover all these options.
Yes, this a fully agree with...
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Rajith Attapattu <ra...@gmail.com>.
As soon as we come to an agreement on the databinding stuff I will finalize
the JMS binding.
(We had long discussion on irc about it and Raymond posted the chat log)
As soon as Qpid is available we can have a working sample out there.
The prospect of Tuscany C (amqp binding) working with Tuscany java (amqp
binding) is interesting.
Regards,
Rajith
On 9/26/06, Carl Trieloff <cc...@redhat.com> wrote:
>
> Jim Marino wrote:
> >
> > On Sep 26, 2006, at 1:40 PM, Jeremy Boynes wrote:
> >
> >> On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
> >>> Hmm, maybe I'm missing something, but AFAIK there is no interop in
> >>> JMS across providers, not to mention programming languages.
> >>
> >> I believe I can use a JMS API to ActiveMQ to send a message to a C or
> >> .NET program. I think some commercial products have similar
> >> capabilities.
> > I know of C clients and such for JMS, message bridges, and realize
> > MQSeries can basically talk to anything but if it is JMS, aren't we
> > specifically dealing with a Java API and not interop? I think a
> > generic messaging binding would be great to have, like AMQP or
> > MQSeries too, but it is not "JMS".
> Agree, I think of JMS as the dry run for AMQP. Thus I brought up
> portability of the serialization so that the patterns can be re-used.
> Now there is a bunch of stuff that we need to do in addition. Peter
> provided some great comments on a thread last week. Maybe one of the
> qpid guys can get a cut of an AMQP binding done in two or so weeks and
> start debate on that. I would think we would do a Java one first and
> then one for C++ Tuscany and see if the two tuscany impls can work
> together :-).
>
> I would like to see the following use cases working with Tuscany <-> AMQP
> --Java Tuscany <-> AMQP Java binding <-> AMQP <-> AMQP C++ binding <->
> C++ Tuscany (only works if you have portable serialization, but possible
> as AMQP JMS API maps down to AMQP.)
> --Java Tuscany <-> JMS binding <-> AMQP <-> AMQP C++ binding <-> C++
> Tuscany
> --Plus some Tuscany impl on each side should also work...
>
> >
> > Jim
> >
> >> --
> >> Jeremy
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Carl Trieloff <cc...@redhat.com>.
Jim Marino wrote:
>
> On Sep 26, 2006, at 1:40 PM, Jeremy Boynes wrote:
>
>> On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
>>> Hmm, maybe I'm missing something, but AFAIK there is no interop in
>>> JMS across providers, not to mention programming languages.
>>
>> I believe I can use a JMS API to ActiveMQ to send a message to a C or
>> .NET program. I think some commercial products have similar
>> capabilities.
> I know of C clients and such for JMS, message bridges, and realize
> MQSeries can basically talk to anything but if it is JMS, aren't we
> specifically dealing with a Java API and not interop? I think a
> generic messaging binding would be great to have, like AMQP or
> MQSeries too, but it is not "JMS".
Agree, I think of JMS as the dry run for AMQP. Thus I brought up
portability of the serialization so that the patterns can be re-used.
Now there is a bunch of stuff that we need to do in addition. Peter
provided some great comments on a thread last week. Maybe one of the
qpid guys can get a cut of an AMQP binding done in two or so weeks and
start debate on that. I would think we would do a Java one first and
then one for C++ Tuscany and see if the two tuscany impls can work
together :-).
I would like to see the following use cases working with Tuscany <-> AMQP
--Java Tuscany <-> AMQP Java binding <-> AMQP <-> AMQP C++ binding <->
C++ Tuscany (only works if you have portable serialization, but possible
as AMQP JMS API maps down to AMQP.)
--Java Tuscany <-> JMS binding <-> AMQP <-> AMQP C++ binding <-> C++
Tuscany
--Plus some Tuscany impl on each side should also work...
>
> Jim
>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Carl Trieloff <cc...@redhat.com>.
>>
> AMQP would be awesome. BTW, maybe you or Carl could mention if it
> supports callbacks and conversational id propagation?
>
>
Jim,
With RPC protocols they typically return an object for callbacks,
typically in messaging a reply-to queue and correlation id is
used for conversational state. AMQP can do this.
Carl.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 26, 2006, at 1:57 PM, Rajith Attapattu wrote:
> Once I sort out the JMS binding I will do an AMQP binding :-)
>
AMQP would be awesome. BTW, maybe you or Carl could mention if it
supports callbacks and conversational id propagation?
Jim
> I need to understand the databinding framework a bit more to sort
> this out.
> Then I can concentrate on getting the test cases done.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Rajith Attapattu <ra...@gmail.com>.
Once I sort out the JMS binding I will do an AMQP binding :-)
I need to understand the databinding framework a bit more to sort this out.
Then I can concentrate on getting the test cases done.
Regards,
Rajith.
On 9/26/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Sep 26, 2006, at 1:40 PM, Jeremy Boynes wrote:
>
> > On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
> >> Hmm, maybe I'm missing something, but AFAIK there is no interop in
> >> JMS across providers, not to mention programming languages.
> >
> > I believe I can use a JMS API to ActiveMQ to send a message to a C
> > or .NET program. I think some commercial products have similar
> > capabilities.
> I know of C clients and such for JMS, message bridges, and realize
> MQSeries can basically talk to anything but if it is JMS, aren't we
> specifically dealing with a Java API and not interop? I think a
> generic messaging binding would be great to have, like AMQP or
> MQSeries too, but it is not "JMS".
>
> Jim
>
> > --
> > Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 26, 2006, at 1:40 PM, Jeremy Boynes wrote:
> On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
>> Hmm, maybe I'm missing something, but AFAIK there is no interop in
>> JMS across providers, not to mention programming languages.
>
> I believe I can use a JMS API to ActiveMQ to send a message to a C
> or .NET program. I think some commercial products have similar
> capabilities.
I know of C clients and such for JMS, message bridges, and realize
MQSeries can basically talk to anything but if it is JMS, aren't we
specifically dealing with a Java API and not interop? I think a
generic messaging binding would be great to have, like AMQP or
MQSeries too, but it is not "JMS".
Jim
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 26, 2006, at 1:55 PM, Ignacio Silva-Lepe wrote:
> Ah, so I took the bait. So then the question is what does ActiveMQ
> do when it gets a Java serialized message, e.g., an ObjectMessage?
> It should be able to handle it, otherwise it would be subsetting
> the JMS spec.
I think it delivers it as a series of bytes to the other end. If you
have a Java consumer then it will know how to deserialize and return
an ObjectMessage; if you have a C client then I think that could be
classified as an exercise for the user :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Ah, so I took the bait. So then the question is what does ActiveMQ do when
it gets a Java serialized message, e.g., an ObjectMessage? It should be able
to handle it, otherwise it would be subsetting the JMS spec.
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, September 26, 2006 4:40 PM
Subject: Re: [jira] Updated: (TUSCANY-753) JMS Binding
> On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
>> Hmm, maybe I'm missing something, but AFAIK there is no interop in JMS
>> across providers, not to mention programming languages.
>
> I believe I can use a JMS API to ActiveMQ to send a message to a C or
> .NET program. I think some commercial products have similar capabilities.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
> Hmm, maybe I'm missing something, but AFAIK there is no interop in
> JMS across providers, not to mention programming languages.
I believe I can use a JMS API to ActiveMQ to send a message to a C
or .NET program. I think some commercial products have similar
capabilities.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Comment inline.
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, September 26, 2006 4:26 PM
Subject: Re: [jira] Updated: (TUSCANY-753) JMS Binding
> On Sep 26, 2006, at 1:06 PM, Jim Marino wrote:
>
>>>
>>> XML serialization is better than java serialization - more portable.
>>
>> Yes agreed it is more "portable" and should be an option but with JMS
>> were are not invoking across providers and we are dealing with Java on
>> the receiving end. Also, I think we need to support streaming. Maybe we
>> could also do a AMQP binding too for portability :-)
>
> There's no guarantee that there is Java on the far end - JMS is just the
> API at this end of the messaging infrastructure.
Hmm, maybe I'm missing something, but AFAIK there is no interop in JMS
across providers, not to mention programming languages.
>
> We really need to be able to serialize to any message form: XML, Java
> serialization, various flavours of byte stream, user-defined mechanisms.
> Hopefully by hooking this to the databinding framework we can cover all
> these options.
>
> --
> Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 26, 2006, at 1:06 PM, Jim Marino wrote:
>>
>> XML serialization is better than java serialization - more portable.
>
> Yes agreed it is more "portable" and should be an option but with
> JMS were are not invoking across providers and we are dealing with
> Java on the receiving end. Also, I think we need to support
> streaming. Maybe we could also do a AMQP binding too for
> portability :-)
There's no guarantee that there is Java on the far end - JMS is just
the API at this end of the messaging infrastructure.
We really need to be able to serialize to any message form: XML, Java
serialization, various flavours of byte stream, user-defined
mechanisms. Hopefully by hooking this to the databinding framework we
can cover all these options.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
>
> XML serialization is better than java serialization - more portable.
Yes agreed it is more "portable" and should be an option but with JMS
were are not invoking across providers and we are dealing with Java
on the receiving end. Also, I think we need to support streaming.
Maybe we could also do a AMQP binding too for portability :-)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Carl Trieloff <cc...@redhat.com>.
Rajith Attapattu wrote:
> Hi Jim,
>
> Thank you very much for the feedback I really appreciate it.
> Please see my comments inline marked with [RA]
>
> On 9/26/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> Hi Rajith,
>>
>> Thanks for the patch. I had a couple of quick questions, mostly
>> related to things that could be done to evolve the code (It's before
>> I have had enough coffee so bear with me ;-) ):
>
> [RA] I really appreciate this.
>
>
> 1. Some of the exception handling does printStackTrace() and
>> exceptions derive directly from things like RuntimeException (I
>> realize this is probably just for expediency). Eventually these
>> should probably be converted into descendants of TuscanyException and
>> TuscanyRuntimeException. We did a write-up of this at http://
>> incubator.apache.org/tuscany/codeguidelines.html which may be useful.
>
>
> [RA] Yes this was done for expediency. But thats not an excuse :-)
> Before the code is moved to trunk I want to do proper error handling.
> The exceptions should be meaningful and consistent with the existing
> error
> handling framework.
>
> I will address this with the next patch for sure.
>
> 2. Could you explain what you have in mind w.r.t. data binding? I
>> noticed Axiom is used to parse the configuration and then SDO is used
>> to deserialize the payload. I was thinking the StAX APIs could be
>> used for configuration processing and the binding itself could be
>> configured to support a variety of serialization strategies,
>> including non-textual ones? This would break the dependence on Axiom
>> and SDO.
>
>
> [RA] This was a very primitive attempt at doing databinding. I modeled
> it on
> the axis2 binding.
> Raymond has refactored the code since then to remove the dependency on
> SDO.
> I will do the same in the next patch.
>
> what I had in mind was to serialize the objects to XML and send as Text
> messages in JMS.
> The other end would deserialize it into the format expected by the
> component. I am hoping to leverage the interceptor chain in the data
> binding
> framework
>
> The non-textual angel is interesting too. Are u sugesting java
> serialization
> and send that as a Bytes message in JMS??
> That is something that I had in mind too. But I settled for the XML
> serialization as the first attempt.
XML serialization is better than java serialization - more portable.
>
> 3. There are a couple of places classes are reflectively newed and
>> they can probably be replaced with system services, e.g.
>> SimpleJMSResourceFactory.
>
>
> [RA] The JMS binding spec describes that OperationSelectors can be
> specified as part of the binding.
> Therefore this will be specified as a fully qualified class name. So
> we need
> to support user defined OperationSelectors which is only known at runtime
> and can only be loaded via reflection.
>
> In the absence of that I just do new DefaultOperationSelector().
>
> The same thinking goes behind the JMSResourceFactory as well.
> I hope I explained my point. If u have further questions please feel
> free to
> discuss them.
>
> Once again thank you very much for taking the time to review and
> comment on
> the patch.
>
> Thanks,
>> Jim
>>
>>
>>
>>
>>
>> On Sep 25, 2006, at 3:29 PM, Rajith Attapattu (JIRA) wrote:
>>
>> > [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ]
>> >
>> > Rajith Attapattu updated TUSCANY-753:
>> > -------------------------------------
>> >
>> > Attachment: jmsbinding_jira753_25sep06.patch
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 26, 2006, at 9:47 AM, Rajith Attapattu wrote:
>
>
> 1. Some of the exception handling does printStackTrace() and
>> exceptions derive directly from things like RuntimeException (I
>> realize this is probably just for expediency). Eventually these
>> should probably be converted into descendants of TuscanyException and
>> TuscanyRuntimeException. We did a write-up of this at http://
>> incubator.apache.org/tuscany/codeguidelines.html which may be useful.
>
>
> [RA] Yes this was done for expediency. But thats not an excuse :-)
> Before the code is moved to trunk I want to do proper error handling.
> The exceptions should be meaningful and consistent with the
> existing error
> handling framework.
>
It may not be the most explanatory so any questions feel free to post.
> I will address this with the next patch for sure.
>
> 2. Could you explain what you have in mind w.r.t. data binding? I
>> noticed Axiom is used to parse the configuration and then SDO is used
>> to deserialize the payload. I was thinking the StAX APIs could be
>> used for configuration processing and the binding itself could be
>> configured to support a variety of serialization strategies,
>> including non-textual ones? This would break the dependence on Axiom
>> and SDO.
>
>
> [RA] This was a very primitive attempt at doing databinding. I
> modeled it on
> the axis2 binding.
> Raymond has refactored the code since then to remove the dependency
> on SDO.
> I will do the same in the next patch.
>
> what I had in mind was to serialize the objects to XML and send as
> Text
> messages in JMS.
> The other end would deserialize it into the format expected by the
> component. I am hoping to leverage the interceptor chain in the
> data binding
> framework
>
> The non-textual angel is interesting too. Are u sugesting java
> serialization
> and send that as a Bytes message in JMS??
>
Yes, for handling streaming cases.
> That is something that I had in mind too. But I settled for the XML
> serialization as the first attempt.
>
Yea seems like the reasonable thing to do
> 3. There are a couple of places classes are reflectively newed and
>> they can probably be replaced with system services, e.g.
>> SimpleJMSResourceFactory.
>
>
> [RA] The JMS binding spec describes that OperationSelectors can be
> specified as part of the binding.
> Therefore this will be specified as a fully qualified class name.
> So we need
> to support user defined OperationSelectors which is only known at
> runtime
> and can only be loaded via reflection.
>
Ah o.k..
> In the absence of that I just do new DefaultOperationSelector().
>
> The same thinking goes behind the JMSResourceFactory as well.
> I hope I explained my point. If u have further questions please
> feel free to
> discuss them.
>
> Once again thank you very much for taking the time to review and
> comment on
> the patch.
>
Thanks for working on this - I'm looking forward to trying it out.
> Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Jim,
Thank you very much for the feedback I really appreciate it.
Please see my comments inline marked with [RA]
On 9/26/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Rajith,
>
> Thanks for the patch. I had a couple of quick questions, mostly
> related to things that could be done to evolve the code (It's before
> I have had enough coffee so bear with me ;-) ):
[RA] I really appreciate this.
1. Some of the exception handling does printStackTrace() and
> exceptions derive directly from things like RuntimeException (I
> realize this is probably just for expediency). Eventually these
> should probably be converted into descendants of TuscanyException and
> TuscanyRuntimeException. We did a write-up of this at http://
> incubator.apache.org/tuscany/codeguidelines.html which may be useful.
[RA] Yes this was done for expediency. But thats not an excuse :-)
Before the code is moved to trunk I want to do proper error handling.
The exceptions should be meaningful and consistent with the existing error
handling framework.
I will address this with the next patch for sure.
2. Could you explain what you have in mind w.r.t. data binding? I
> noticed Axiom is used to parse the configuration and then SDO is used
> to deserialize the payload. I was thinking the StAX APIs could be
> used for configuration processing and the binding itself could be
> configured to support a variety of serialization strategies,
> including non-textual ones? This would break the dependence on Axiom
> and SDO.
[RA] This was a very primitive attempt at doing databinding. I modeled it on
the axis2 binding.
Raymond has refactored the code since then to remove the dependency on SDO.
I will do the same in the next patch.
what I had in mind was to serialize the objects to XML and send as Text
messages in JMS.
The other end would deserialize it into the format expected by the
component. I am hoping to leverage the interceptor chain in the data binding
framework
The non-textual angel is interesting too. Are u sugesting java serialization
and send that as a Bytes message in JMS??
That is something that I had in mind too. But I settled for the XML
serialization as the first attempt.
3. There are a couple of places classes are reflectively newed and
> they can probably be replaced with system services, e.g.
> SimpleJMSResourceFactory.
[RA] The JMS binding spec describes that OperationSelectors can be
specified as part of the binding.
Therefore this will be specified as a fully qualified class name. So we need
to support user defined OperationSelectors which is only known at runtime
and can only be loaded via reflection.
In the absence of that I just do new DefaultOperationSelector().
The same thinking goes behind the JMSResourceFactory as well.
I hope I explained my point. If u have further questions please feel free to
discuss them.
Once again thank you very much for taking the time to review and comment on
the patch.
Thanks,
> Jim
>
>
>
>
>
> On Sep 25, 2006, at 3:29 PM, Rajith Attapattu (JIRA) wrote:
>
> > [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ]
> >
> > Rajith Attapattu updated TUSCANY-753:
> > -------------------------------------
> >
> > Attachment: jmsbinding_jira753_25sep06.patch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Updated: (TUSCANY-753) JMS Binding
Posted by Jim Marino <jm...@myromatours.com>.
Hi Rajith,
Thanks for the patch. I had a couple of quick questions, mostly
related to things that could be done to evolve the code (It's before
I have had enough coffee so bear with me ;-) ):
1. Some of the exception handling does printStackTrace() and
exceptions derive directly from things like RuntimeException (I
realize this is probably just for expediency). Eventually these
should probably be converted into descendants of TuscanyException and
TuscanyRuntimeException. We did a write-up of this at http://
incubator.apache.org/tuscany/codeguidelines.html which may be useful.
2. Could you explain what you have in mind w.r.t. data binding? I
noticed Axiom is used to parse the configuration and then SDO is used
to deserialize the payload. I was thinking the StAX APIs could be
used for configuration processing and the binding itself could be
configured to support a variety of serialization strategies,
including non-textual ones? This would break the dependence on Axiom
and SDO.
3. There are a couple of places classes are reflectively newed and
they can probably be replaced with system services, e.g.
SimpleJMSResourceFactory.
Thanks,
Jim
On Sep 25, 2006, at 3:29 PM, Rajith Attapattu (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ]
>
> Rajith Attapattu updated TUSCANY-753:
> -------------------------------------
>
> Attachment: jmsbinding_jira753_25sep06.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org