You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Rajith Attapattu <ra...@gmail.com> on 2007/03/09 20:42:32 UTC
Re: adding a transport
Hi Gerald,
Comments in line.
> > From my understanding QPid fully passes the JMS TCK, so you can use
> > > AMQP out-of-the-box with the existing JMS plug today. So in answer to
> > > your question its trivial to use AMQP.
> >
[RA] We did have a full pass on the JMS TCK.
But, there was rapid changes on the trunk after that and I haven't run the
TCK for a while.
So I can't claim 100% compliance w/o running it again. But I dobut that we
really broke anything serious or else we would have heard from users.
Once the trunk stabalizes a bit I am going to run the TCK again and fix
anything if broken.
> In general, there seems to be a mismatch between AMQP features and the
> > JMS API,
[RA] Gerald, I am in the AMQP spec group and we are currently working on an
AMQP-JMS mapping to standardise the JMS implementation on top of AMQP and to
describe in detail how these to worlds come to gether. This is to ensure
that any JMS impl on top of AMQP can interoperate with each other.
>in particular with the concept of an Exchange missing from
> JMS.
[RA] JMS is just a client API. It doesn't really dictate anything about how
a broker should be implemented.
The concept of exchanges is a broker side artifact. For Qpid we have used
the Direct Exchange to implement point-to-point messaging and Topic Exchange
to implement pub-sub.
>
> > Qpid claims to support "All features required by the Sun JMS 1.1
> > specification". Last time i checked, though, i wasn't able to write a
> > Qpid client without resorting to the Qpid-specific API - but i'll
> > certainly try again and try to hook it up to Synapse/Axis2. Will keep
> > this list posted...
[RA] Gerald we don't have a Qpid (or AMQP) specific java client. Our java
client is actually a JMS implementation on top of AMQP.
JMS was the standard messaging API and we decided to use it rather than have
our own API. Besides there are lots of enterprise apps written on JMS.
So having a JMS client was the best way to convert them transparently on to
AMQP.
However currently we are doing a refactoring on the client side (java) and
we want have a very low level client API and then map the JMS API on top of
it.
We could then use this low level client API to suport native AMQP features
that JMS doesn't provide. For example Rabbit has a non JMS java client.
There seems to be some interest in using AMQP directly without JMS, so a
native AMQP client in java makes more sense now.
>
> > > For example, without any coding you should be able to put an XML
> > > message onto AMQP and have Synapse read it, and then route it to a
> > > WS-ReliableMessaging endpoint - for example a Microsoft .NET server.
> > >
[RA] If synapse needs to inspect the message headers and route and AMQP
message you could do that with the JMS API itself.
I think Asanka already did something to route messages based on the JMS
headers. Asanka is that correct ?
If we use the Qpid JMS client then we can do that.
> > I think the interesting question is whether we can do tighter
> > > integration, and we'd love any input on what that could be.
> >
> for instance: the ability to dynamically declare AMQP exchanges,
> > queues and bindings (which wire an exchange to a queue) from Synapse
> > (possibly based on incoming message properties, etc.), since these
> > dynamic capabilities are a core feature of AMQP that is missing from
> > JMS.
[RA] Certainly these features are missing from the current java client. As
we have directly implemented the JMS API.
Part of my current tasks is to work on a low level java client API to do
these things.
Once we have this client I am happy to work with the synapse team to
integrate this into a syanpse extention if the community thinks it's a
useful feature to have.
> > I'm also interested interested in the wider questions around reliable
> > > messaging protocols, so if you're in a position to share your thoughts
> > > around AMQP I'd love to hear those too.
> >
> > i should consolidate my thoughts first ;-) but it is my impression
> > that AMQP is still in a very early stage of its lifecycle:
> > - there is no standardised Java binding
[RA] We will not do any language bindings. People can implement it in any
lanaguage in any way they want as long as they adhere to the wire protocol
and functionality described in the spec.
However we are currently working on an AMQP-JMS mapping to standadise a
guide for implementors to ensure any JMS implementation will interoperate
with another. The idea is to have a JMS client (or even a C or Phython
client if they want to) to be able to read a JMS map message sent by another
JMS client and make sense out of it. Basically we are trying to standarise
the encoding. We are doing this only for java as there is no other common
message API out there for any other language.
> - even the abstracted API that the spec defines is in flux (e.g. the
> > new message class)
[RA] Slowly but surely we are getting closer to finalize this. We already
have the new message class implemented in a branch in Qpid.
> - i'm unsure as to the interoperability of different AMQP
> > implementations (which is, after all, one central goal for AMQP)
> > - it promisses on-the-wire interoperability without compromising
> > performance,
[RA] Interoperability is key for AMQP. We will be introducing a TCK to
ensure that.
though
> > - it's not firewall-friendly
> > - the spec is very well written ;-)
>
> > cheers,
> > gerald
> >
> > >
> > > Paul
> > >
> > > On 3/9/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Hi asankha,
> > > >
> > > > thanks for your quick response. AMQP transport in Synapse/Axis2 is
> not
> > > > an immediate requirement for us but something that we will want to
> be
> > > > able to do in the not-to-distant future without incurring too much
> > > > effort (based on one of the open-source AMQP implementations i
> > > > mentioned). So it is important to know that you don't consider it a
> > > > difficult task adding it to Axis2. I'll have a look at the relevant
> > > > Axis2 APIs and the code for the JMS transport to get a better
> idea...
> > > >
> > > > As to who is going to do it: that entirely depends on our schedule
> > > > when the concrete need for AMQP arises from our project...
> > > >
> > > > thanks again,
> > > > gerald
> > > >
> > > > On 09/03/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > Hi Gerald
> > > > > > Can you please give me a rough idea of what it entails to add
> support
> > > > > > for a new transport to Synapse? I would want to add support for
> AMQP
> > > > > > (http://www.amqp.org/), which has a JMS-like Java client API
> (see
> > > > > > http://cwiki.apache.org/qpid/, http://www.rabbitmq.com/). Is
> this
> > > > > > trivial or a major task? Since Synapse does not build on JBI, it
> must
> > > > > > have its own APIs for doing this...
> > > > > Adding a new transport to Synapse is the same as adding a new
> transport
> > > > > for Axis2 - and is not a difficult task. There are certain Axis2
> API's
> > > > > you need to implement, and the existing transports should provide
> > > > > adequate examples and code to help guide the effort.
> > > > >
> > > > > Would you be interested in developing an AMQP transport for
> > > > > Synapse/Axis2 yourself, or looking at how you could get the AMQP
> support
> > > > > built into Synapse through the community? Either way I think
> having an
> > > > > actual user requiring a new transport would help in its
> implementation,
> > > > > scope and testing efforts. I will read through some of the links
> you
> > > > > have provided meanwhile..
> > > > >
> > > > > asankha
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>
Re: adding a transport
Posted by Rajith Attapattu <ra...@gmail.com>.
Gerald,
comments inline.
On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
>
> hi Rajith,
>
> thank you very much for giving me some insight into your work at Qpid
> and the AMQP spec group. I definitely look forward to that AMQP-JMS
> mapping!
>
> I don't really agree with your statement that "The concept of
> exchanges is a broker side artifact" and that "JMS is just a client
> API". After all, an AMQP client sends messages to an exchange (so it
> is not just a broker-side artifact) and the JMS-spec defines what
> "administered objects" (Queue, Topic, ConnectionFactory) a JMS client
> can expect to look-up via JNDI from a JMS provider (so JMS also
> defines a JMS provider's behaviour, to some degree). However i trust
> that the AMQP-JMS-mapping will sort these issues out.
[RA] IMO the JMS API doesn't define the JMS providers behaviour, rather it
provides what is expected from a JMS provider.
The broker implementation can be whatever you want as long as you can
provide whats expected from the JMS API. YMMV.
For example you can implement Topics any which way u want and Qpid has
chosen to do it with the topic exchange.
Since this is not the forum to talk about JMS and Qpid, I would like to
invite u to the Qpid mailing list and you can get a more wide varierty of
opinions over there. We really need user feedback and your comments will be
very welcomed.
I also can't fully agree with your assertion that "Our java client is
> actually a JMS implementation on top of AMQP", as this hides the fact
> that Qpid-specific classes (like
> org.apache.qpid.client.BasicMessageProducer) provide essential
> features (such as sending non-persistent and immediate messages) which
> are not available via the JMS interfaces (javax.jms.MessageProducer in
> this case). So it just means to show that the mapping of AMQP to JMS
> needs some clarification, and that there is a part of AMQP that can
> not be mapped to JMS nicely and the Java mapping of that should also
> be standardised.
[RA] Gerald I totally that there is some behaviour in AMQP that cannot be
fully or effectively expressed through JMS.
There is absolutely some value in defining a Java client for AMQP and that
is what I am currently doing. The idea is to expose a protocol level API
using java.
Why we decided to do JMS as the first cut is bcos
a) the code donated to the community was a JMS implementation of AMQP
b) Most enterprise java apps (including the applications from the donor)
were using JMS.
so JMS was the more immediate use case.
However I don't agree the we need a standard java mapping. AMQP is a wire
level protocol. So u really don't need any language mapping bcos what
matters is the byte stream on the wire. There is already a language
independent protocol API defined, so we don't need any language specific
mappings. (it's like SOAP, there is message format and rules on how to
interpret it)
JMS is a special use case. As I mentioned before the AMQP-JMS mapping is
more about interoperability between two JMS impls on top of AMQP and not
really about AMQP itself. Bcos we already have a standardised wire format
for AMQP. So this is like the SOAP/JMS spec.
Hope this helps.
Regards,
Rajith
thanks again and good luck with your endeavours.
>
> I shall let you know if i succeed in integrating Qpid as "just another
> JMS provider" into Synapse...
>
> cheers,
> gerald
>
>
>
> On 09/03/07, Rajith Attapattu <ra...@gmail.com> wrote:
> > Hi Gerald,
> >
> > Comments in line.
> >
> > > > From my understanding QPid fully passes the JMS TCK, so you can use
> > > > > AMQP out-of-the-box with the existing JMS plug today. So in answer
> to
> > > > > your question its trivial to use AMQP.
> > > >
> >
> > [RA] We did have a full pass on the JMS TCK.
> > But, there was rapid changes on the trunk after that and I haven't run
> the
> > TCK for a while.
> > So I can't claim 100% compliance w/o running it again. But I dobut that
> we
> > really broke anything serious or else we would have heard from users.
> > Once the trunk stabalizes a bit I am going to run the TCK again and fix
> > anything if broken.
> >
> > > In general, there seems to be a mismatch between AMQP features and the
> > > > JMS API,
> >
> >
> > [RA] Gerald, I am in the AMQP spec group and we are currently working on
> an
> > AMQP-JMS mapping to standardise the JMS implementation on top of AMQP
> and to
> > describe in detail how these to worlds come to gether. This is to ensure
> > that any JMS impl on top of AMQP can interoperate with each other.
> >
> > >in particular with the concept of an Exchange missing from
> > > JMS.
> > [RA] JMS is just a client API. It doesn't really dictate anything about
> how
> > a broker should be implemented.
> > The concept of exchanges is a broker side artifact. For Qpid we have
> used
> > the Direct Exchange to implement point-to-point messaging and Topic
> Exchange
> > to implement pub-sub.
> >
> > >
> > > > Qpid claims to support "All features required by the Sun JMS 1.1
> > > > specification". Last time i checked, though, i wasn't able to write
> a
> > > > Qpid client without resorting to the Qpid-specific API - but i'll
> > > > certainly try again and try to hook it up to Synapse/Axis2. Will
> keep
> > > > this list posted...
> >
> >
> > [RA] Gerald we don't have a Qpid (or AMQP) specific java client. Our
> java
> > client is actually a JMS implementation on top of AMQP.
> > JMS was the standard messaging API and we decided to use it rather than
> have
> > our own API. Besides there are lots of enterprise apps written on JMS.
> > So having a JMS client was the best way to convert them transparently on
> to
> > AMQP.
> >
> > However currently we are doing a refactoring on the client side (java)
> and
> > we want have a very low level client API and then map the JMS API on top
> of
> > it.
> > We could then use this low level client API to suport native AMQP
> features
> > that JMS doesn't provide. For example Rabbit has a non JMS java client.
> > There seems to be some interest in using AMQP directly without JMS, so a
> > native AMQP client in java makes more sense now.
> >
> > >
> > > > > For example, without any coding you should be able to put an XML
> > > > > message onto AMQP and have Synapse read it, and then route it to
> a
> > > > > WS-ReliableMessaging endpoint - for example a Microsoft .NET
> server.
> > > > >
> >
> > [RA] If synapse needs to inspect the message headers and route and AMQP
> > message you could do that with the JMS API itself.
> > I think Asanka already did something to route messages based on the JMS
> > headers. Asanka is that correct ?
> > If we use the Qpid JMS client then we can do that.
> >
> > > > I think the interesting question is whether we can do tighter
> > > > > integration, and we'd love any input on what that could be.
> > > >
> >
> >
> > > for instance: the ability to dynamically declare AMQP exchanges,
> > > > queues and bindings (which wire an exchange to a queue) from Synapse
> > > > (possibly based on incoming message properties, etc.), since these
> > > > dynamic capabilities are a core feature of AMQP that is missing from
> > > > JMS.
> >
> >
> > [RA] Certainly these features are missing from the current java client.
> As
> > we have directly implemented the JMS API.
> > Part of my current tasks is to work on a low level java client API to do
> > these things.
> > Once we have this client I am happy to work with the synapse team to
> > integrate this into a syanpse extention if the community thinks it's a
> > useful feature to have.
> >
> > > > I'm also interested interested in the wider questions around
> reliable
> > > > > messaging protocols, so if you're in a position to share your
> thoughts
> > > > > around AMQP I'd love to hear those too.
> > > >
> > > > i should consolidate my thoughts first ;-) but it is my impression
> > > > that AMQP is still in a very early stage of its lifecycle:
> > > > - there is no standardised Java binding
> >
> >
> > [RA] We will not do any language bindings. People can implement it in
> any
> > lanaguage in any way they want as long as they adhere to the wire
> protocol
> > and functionality described in the spec.
> > However we are currently working on an AMQP-JMS mapping to standadise a
> > guide for implementors to ensure any JMS implementation will
> interoperate
> > with another. The idea is to have a JMS client (or even a C or Phython
> > client if they want to) to be able to read a JMS map message sent by
> another
> > JMS client and make sense out of it. Basically we are trying to
> standarise
> > the encoding. We are doing this only for java as there is no other
> common
> > message API out there for any other language.
> >
> > > - even the abstracted API that the spec defines is in flux (e.g. the
> > > > new message class)
> >
> >
> > [RA] Slowly but surely we are getting closer to finalize this. We
> already
> > have the new message class implemented in a branch in Qpid.
> >
> > > - i'm unsure as to the interoperability of different AMQP
> > > > implementations (which is, after all, one central goal for AMQP)
> > > > - it promisses on-the-wire interoperability without compromising
> > > > performance,
> >
> >
> > [RA] Interoperability is key for AMQP. We will be introducing a TCK to
> > ensure that.
> >
> > though
> > > > - it's not firewall-friendly
> > > > - the spec is very well written ;-)
> >
> >
> > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/9/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > > > Hi asankha,
> > > > > >
> > > > > > thanks for your quick response. AMQP transport in Synapse/Axis2
> is
> > > not
> > > > > > an immediate requirement for us but something that we will want
> to
> > > be
> > > > > > able to do in the not-to-distant future without incurring too
> much
> > > > > > effort (based on one of the open-source AMQP implementations i
> > > > > > mentioned). So it is important to know that you don't consider
> it a
> > > > > > difficult task adding it to Axis2. I'll have a look at the
> relevant
> > > > > > Axis2 APIs and the code for the JMS transport to get a better
> > > idea...
> > > > > >
> > > > > > As to who is going to do it: that entirely depends on our
> schedule
> > > > > > when the concrete need for AMQP arises from our project...
> > > > > >
> > > > > > thanks again,
> > > > > > gerald
> > > > > >
> > > > > > On 09/03/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > > Hi Gerald
> > > > > > > > Can you please give me a rough idea of what it entails to
> add
> > > support
> > > > > > > > for a new transport to Synapse? I would want to add support
> for
> > > AMQP
> > > > > > > > (http://www.amqp.org/), which has a JMS-like Java client API
> > > (see
> > > > > > > > http://cwiki.apache.org/qpid/, http://www.rabbitmq.com/). Is
> > > this
> > > > > > > > trivial or a major task? Since Synapse does not build on
> JBI, it
> > > must
> > > > > > > > have its own APIs for doing this...
> > > > > > > Adding a new transport to Synapse is the same as adding a new
> > > transport
> > > > > > > for Axis2 - and is not a difficult task. There are certain
> Axis2
> > > API's
> > > > > > > you need to implement, and the existing transports should
> provide
> > > > > > > adequate examples and code to help guide the effort.
> > > > > > >
> > > > > > > Would you be interested in developing an AMQP transport for
> > > > > > > Synapse/Axis2 yourself, or looking at how you could get the
> AMQP
> > > support
> > > > > > > built into Synapse through the community? Either way I think
> > > having an
> > > > > > > actual user requiring a new transport would help in its
> > > implementation,
> > > > > > > scope and testing efforts. I will read through some of the
> links
> > > you
> > > > > > > have provided meanwhile..
> > > > > > >
> > > > > > > asankha
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> synapse-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://www.gerald-loeffler.net
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> http://www.gerald-loeffler.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>
Re: adding a transport
Posted by Gerald Loeffler <ge...@googlemail.com>.
hi Rajith,
thank you very much for giving me some insight into your work at Qpid
and the AMQP spec group. I definitely look forward to that AMQP-JMS
mapping!
I don't really agree with your statement that "The concept of
exchanges is a broker side artifact" and that "JMS is just a client
API". After all, an AMQP client sends messages to an exchange (so it
is not just a broker-side artifact) and the JMS-spec defines what
"administered objects" (Queue, Topic, ConnectionFactory) a JMS client
can expect to look-up via JNDI from a JMS provider (so JMS also
defines a JMS provider's behaviour, to some degree). However i trust
that the AMQP-JMS-mapping will sort these issues out.
I also can't fully agree with your assertion that "Our java client is
actually a JMS implementation on top of AMQP", as this hides the fact
that Qpid-specific classes (like
org.apache.qpid.client.BasicMessageProducer) provide essential
features (such as sending non-persistent and immediate messages) which
are not available via the JMS interfaces (javax.jms.MessageProducer in
this case). So it just means to show that the mapping of AMQP to JMS
needs some clarification, and that there is a part of AMQP that can
not be mapped to JMS nicely and the Java mapping of that should also
be standardised.
thanks again and good luck with your endeavours.
I shall let you know if i succeed in integrating Qpid as "just another
JMS provider" into Synapse...
cheers,
gerald
On 09/03/07, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi Gerald,
>
> Comments in line.
>
> > > From my understanding QPid fully passes the JMS TCK, so you can use
> > > > AMQP out-of-the-box with the existing JMS plug today. So in answer to
> > > > your question its trivial to use AMQP.
> > >
>
> [RA] We did have a full pass on the JMS TCK.
> But, there was rapid changes on the trunk after that and I haven't run the
> TCK for a while.
> So I can't claim 100% compliance w/o running it again. But I dobut that we
> really broke anything serious or else we would have heard from users.
> Once the trunk stabalizes a bit I am going to run the TCK again and fix
> anything if broken.
>
> > In general, there seems to be a mismatch between AMQP features and the
> > > JMS API,
>
>
> [RA] Gerald, I am in the AMQP spec group and we are currently working on an
> AMQP-JMS mapping to standardise the JMS implementation on top of AMQP and to
> describe in detail how these to worlds come to gether. This is to ensure
> that any JMS impl on top of AMQP can interoperate with each other.
>
> >in particular with the concept of an Exchange missing from
> > JMS.
> [RA] JMS is just a client API. It doesn't really dictate anything about how
> a broker should be implemented.
> The concept of exchanges is a broker side artifact. For Qpid we have used
> the Direct Exchange to implement point-to-point messaging and Topic Exchange
> to implement pub-sub.
>
> >
> > > Qpid claims to support "All features required by the Sun JMS 1.1
> > > specification". Last time i checked, though, i wasn't able to write a
> > > Qpid client without resorting to the Qpid-specific API - but i'll
> > > certainly try again and try to hook it up to Synapse/Axis2. Will keep
> > > this list posted...
>
>
> [RA] Gerald we don't have a Qpid (or AMQP) specific java client. Our java
> client is actually a JMS implementation on top of AMQP.
> JMS was the standard messaging API and we decided to use it rather than have
> our own API. Besides there are lots of enterprise apps written on JMS.
> So having a JMS client was the best way to convert them transparently on to
> AMQP.
>
> However currently we are doing a refactoring on the client side (java) and
> we want have a very low level client API and then map the JMS API on top of
> it.
> We could then use this low level client API to suport native AMQP features
> that JMS doesn't provide. For example Rabbit has a non JMS java client.
> There seems to be some interest in using AMQP directly without JMS, so a
> native AMQP client in java makes more sense now.
>
> >
> > > > For example, without any coding you should be able to put an XML
> > > > message onto AMQP and have Synapse read it, and then route it to a
> > > > WS-ReliableMessaging endpoint - for example a Microsoft .NET server.
> > > >
>
> [RA] If synapse needs to inspect the message headers and route and AMQP
> message you could do that with the JMS API itself.
> I think Asanka already did something to route messages based on the JMS
> headers. Asanka is that correct ?
> If we use the Qpid JMS client then we can do that.
>
> > > I think the interesting question is whether we can do tighter
> > > > integration, and we'd love any input on what that could be.
> > >
>
>
> > for instance: the ability to dynamically declare AMQP exchanges,
> > > queues and bindings (which wire an exchange to a queue) from Synapse
> > > (possibly based on incoming message properties, etc.), since these
> > > dynamic capabilities are a core feature of AMQP that is missing from
> > > JMS.
>
>
> [RA] Certainly these features are missing from the current java client. As
> we have directly implemented the JMS API.
> Part of my current tasks is to work on a low level java client API to do
> these things.
> Once we have this client I am happy to work with the synapse team to
> integrate this into a syanpse extention if the community thinks it's a
> useful feature to have.
>
> > > I'm also interested interested in the wider questions around reliable
> > > > messaging protocols, so if you're in a position to share your thoughts
> > > > around AMQP I'd love to hear those too.
> > >
> > > i should consolidate my thoughts first ;-) but it is my impression
> > > that AMQP is still in a very early stage of its lifecycle:
> > > - there is no standardised Java binding
>
>
> [RA] We will not do any language bindings. People can implement it in any
> lanaguage in any way they want as long as they adhere to the wire protocol
> and functionality described in the spec.
> However we are currently working on an AMQP-JMS mapping to standadise a
> guide for implementors to ensure any JMS implementation will interoperate
> with another. The idea is to have a JMS client (or even a C or Phython
> client if they want to) to be able to read a JMS map message sent by another
> JMS client and make sense out of it. Basically we are trying to standarise
> the encoding. We are doing this only for java as there is no other common
> message API out there for any other language.
>
> > - even the abstracted API that the spec defines is in flux (e.g. the
> > > new message class)
>
>
> [RA] Slowly but surely we are getting closer to finalize this. We already
> have the new message class implemented in a branch in Qpid.
>
> > - i'm unsure as to the interoperability of different AMQP
> > > implementations (which is, after all, one central goal for AMQP)
> > > - it promisses on-the-wire interoperability without compromising
> > > performance,
>
>
> [RA] Interoperability is key for AMQP. We will be introducing a TCK to
> ensure that.
>
> though
> > > - it's not firewall-friendly
> > > - the spec is very well written ;-)
>
>
> >
> > > cheers,
> > > gerald
> > >
> > > >
> > > > Paul
> > > >
> > > > On 3/9/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > > Hi asankha,
> > > > >
> > > > > thanks for your quick response. AMQP transport in Synapse/Axis2 is
> > not
> > > > > an immediate requirement for us but something that we will want to
> > be
> > > > > able to do in the not-to-distant future without incurring too much
> > > > > effort (based on one of the open-source AMQP implementations i
> > > > > mentioned). So it is important to know that you don't consider it a
> > > > > difficult task adding it to Axis2. I'll have a look at the relevant
> > > > > Axis2 APIs and the code for the JMS transport to get a better
> > idea...
> > > > >
> > > > > As to who is going to do it: that entirely depends on our schedule
> > > > > when the concrete need for AMQP arises from our project...
> > > > >
> > > > > thanks again,
> > > > > gerald
> > > > >
> > > > > On 09/03/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > Can you please give me a rough idea of what it entails to add
> > support
> > > > > > > for a new transport to Synapse? I would want to add support for
> > AMQP
> > > > > > > (http://www.amqp.org/), which has a JMS-like Java client API
> > (see
> > > > > > > http://cwiki.apache.org/qpid/, http://www.rabbitmq.com/). Is
> > this
> > > > > > > trivial or a major task? Since Synapse does not build on JBI, it
> > must
> > > > > > > have its own APIs for doing this...
> > > > > > Adding a new transport to Synapse is the same as adding a new
> > transport
> > > > > > for Axis2 - and is not a difficult task. There are certain Axis2
> > API's
> > > > > > you need to implement, and the existing transports should provide
> > > > > > adequate examples and code to help guide the effort.
> > > > > >
> > > > > > Would you be interested in developing an AMQP transport for
> > > > > > Synapse/Axis2 yourself, or looking at how you could get the AMQP
> > support
> > > > > > built into Synapse through the community? Either way I think
> > having an
> > > > > > actual user requiring a new transport would help in its
> > implementation,
> > > > > > scope and testing efforts. I will read through some of the links
> > you
> > > > > > have provided meanwhile..
> > > > > >
> > > > > > asankha
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://www.gerald-loeffler.net
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >
> > > > http://bloglines.com/blog/paulfremantle
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://www.gerald-loeffler.net
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
--
http://www.gerald-loeffler.net
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org
Re: adding a transport
Posted by "Asankha C. Perera" <as...@wso2.com>.
>> > > For example, without any coding you should be able to put an XML
>> > > message onto AMQP and have Synapse read it, and then route it to a
>> > > WS-ReliableMessaging endpoint - for example a Microsoft .NET server.
>> > >
>
> [RA] If synapse needs to inspect the message headers and route and AMQP
> message you could do that with the JMS API itself.
> I think Asanka already did something to route messages based on the JMS
> headers. Asanka is that correct ?
> If we use the Qpid JMS client then we can do that.
>
Yes, Synapse can read and write transport headers for JMS/HTTP/s etc..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org