Re: [.Net] NMS
On 6/1/07, John O'Hara <[EMAIL PROTECTED]> wrote: Looking at the WCF specifications, I think there is a lot of value in doing a WCF -> AMQP-midlevel - > Framing implementation. The route that I have taken for the re-factored java client is more or less the same. JMS --> AMQP client --> framing. If there is an established way of doing things in a particular language, then it's wise to follow that.(Ex JMS for java) It would be difficult to convince people to use a different API in java when there is JMS no matter what the short comings are. If WCF is what is established then it's wise to follow that route. However I have left the option for people who want do more than JMS and go haywire with AMQP the chance to do so. 1) They can use the more fine grained AMQP low level client to work at the protocol level classes 2) A more coarse grained AMQP client to work at a more high level. Even though both these clients have a clearly defined set of interfaces, I wouldn't call that an API. I'd rather introduce them as a framework (or a set of tools) for people who want more control of the AMQP messaging layer. There is already an interest from other projects in using this type of framework as opposed to using JMS. While end user will like to use JMS, other middleware related projects who wants AMQP support will prefer to use this type of framework to make things more fast and flexible). This is something I suggest that should be thought carefully when designing the .NET client as well. So designing a low level .NET AMQP client and on top WCF as our user visible API for .NET can satisfy both worlds. Regards, Rajith. WCF has a lot of nice toys that C# developers will want to use. They'll not be going near a JMS style API if they can help it at all. Looking at WCF, the more important thing is to make sure we have a good end-to-end experience from XML or binary XML between Java/C# using Qpid drivers. John On 01/06/07, John O'Hara <[EMAIL PROTECTED]> wrote: > > Legal issues are troublesome for end users; it's the end users who get > told to cease and desist! > > Also, I +1 Rob on the WCF front; it's WCF that Windows users will be > using. They won't care about JMS at all. NMS only exists because JMS has > no wire level transport > It would be a mistake to say Spring are the same project on Java and .NET; > > > We should target WCF as our user visible API on .NET. There will be WCF > drivers for all major middleware products and 3rd party technologies will be > plugging into WCF - not NMS. > > How we implement WCF then matters less; but NMS is unlikely to be the > optimal way. > > Cheers > John > > > On 01/06/07, Arnaud Simon < [EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > > > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > > > > > As I said, we would not define the NMS API as we do not change the > > JMS > > > > API. We would only implement it. > > > > > > But we do currently extend JMS, through the use of eg > > > org.apache.qpid.jms.Session extends javax.jms.Session. > > > > We can extend it but the API itself is not changed. > > > > > > I don think that implementing NMS would impact upon interop. An I > > agree > > > > with you that having an API isn't enough but again I am suggesting > > that > > > > we define it but that we implement it. Moreover this code should not > > > > even be hosted by our project but rather on the NMS Apache project. > > > > > > But to implement it we need a clear understanding of the precise > > > semantics. If they are defined to be "exactly the same as JMS" (which > > > itself is open to interpretation in a few areas!) then that is a start > > > > > I suppose notwithstanding the legal issues with that. > > > > I suppose that the NMS project would have to worry about legal issues. > > > > > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions > > > > > can they be exposed elegantly with that model? > > > > I know a person that already has a WCF channel based on NMS. We would > > therefor be able to reuse it without any change. We would also gain > > being compatible with spring .Net. > > > > Again, I see a NMS implementation as a way of speeding up AMQP adoption > > within the .Net community. We will have a WCF channel and a BizTalk > > adapter, NMS is just an additional advantage for people that don't want > > to deal with the cumbersome BizTalk. > > > > Arnaud > > > > > > >
Re: [.Net] NMS
I'm new here, so help me understand where we're trying to go with this. Looking at WCF, the more important thing is to make sure we have a good end-to-end experience from XML or binary XML between Java/C# using Qpid drivers. Absolutely. On the API front, there are several goals we might want to achieve - which game(s) are we playing? 1. Neutrality. One goal is to have an API that works on multiple platforms, and which leverages all of the features of AMQP. Ideally, this API should fit cleanly into other APIs by supporting standard XML APIs, but it would not try to support features that depend on the platform being supported, but would try to encourage support for standards. For instance, SAX, streaming text, and W3C standards like MTOM and the upcoming EXI binary XML standard would be supported (when it is available), but we would not try to support Microsoft's binary XML representation (which does not work across .NET versions or across platforms). To achieve neutrality, we need a simple story for our XML in Qpid, defining an API that works cleanly with other existing APIs, without dictating which one to use. Our use cases could be informed by use cases presented for WCF and other systems. This approach has the advantage of leveraging AMQP features not supported by other APIs, avoiding mismatches with the models on which other APIs are built, and providing platform independence. 2. Full support for familiar APIs. Another good goal is to provide full support for existing APIs like JMS or WCF. We're already doing this with JMS. Currently, our Java implementation pursues this strategy, and our other implementations seem to follow the neutrality strategy. To do this well, we would have to find the common ground among WCF, JMS, and perhaps other APIs, and determine how much impedance mismatch there is with our own model and among the models we want to support. I'd think some careful analysis would be needed to see how well this can be done. This approach has the advantage of minimizing new learning for people already familiar with one or more existing APIs. We should only play this game for well entrenched APIs that we can't easily coax people off of. 3. Protocol support for JMS-like APIs. We have to support JMS, so perhaps we could extend our support to Windows using NMS. In this scenario. AMQP is invisible to the users, and provides compatibility. A difficulty with this approach is that Windows programmers may not be interested in using a JMS-like API. I'd argue that we need to play the "neutrality" game regardless in order to fully support AMQP, we're stuck playing at least the JMS game at this point, but should do very careful analysis to be sure we can support WCF well before going that direction. At the very least, we should have a good neutral story that handles the WCF use cases well. How large is the NMS community? Jonathan
Re: [.Net] NMS
Looking at the WCF specifications, I think there is a lot of value in doing a WCF -> AMQP-midlevel - > Framing implementation. WCF has a lot of nice toys that C# developers will want to use. They'll not be going near a JMS style API if they can help it at all. Looking at WCF, the more important thing is to make sure we have a good end-to-end experience from XML or binary XML between Java/C# using Qpid drivers. John On 01/06/07, John O'Hara <[EMAIL PROTECTED]> wrote: Legal issues are troublesome for end users; it's the end users who get told to cease and desist! Also, I +1 Rob on the WCF front; it's WCF that Windows users will be using. They won't care about JMS at all. NMS only exists because JMS has no wire level transport It would be a mistake to say Spring are the same project on Java and .NET; We should target WCF as our user visible API on .NET. There will be WCF drivers for all major middleware products and 3rd party technologies will be plugging into WCF - not NMS. How we implement WCF then matters less; but NMS is unlikely to be the optimal way. Cheers John On 01/06/07, Arnaud Simon < [EMAIL PROTECTED]> wrote: > > On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > > > As I said, we would not define the NMS API as we do not change the > JMS > > > API. We would only implement it. > > > > But we do currently extend JMS, through the use of eg > > org.apache.qpid.jms.Session extends javax.jms.Session. > > We can extend it but the API itself is not changed. > > > > I don think that implementing NMS would impact upon interop. An I > agree > > > with you that having an API isn't enough but again I am suggesting > that > > > we define it but that we implement it. Moreover this code should not > > > even be hosted by our project but rather on the NMS Apache project. > > > > But to implement it we need a clear understanding of the precise > > semantics. If they are defined to be "exactly the same as JMS" (which > > itself is open to interpretation in a few areas!) then that is a start > > > I suppose notwithstanding the legal issues with that. > > I suppose that the NMS project would have to worry about legal issues. > > > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions > > > can they be exposed elegantly with that model? > > I know a person that already has a WCF channel based on NMS. We would > therefor be able to reuse it without any change. We would also gain > being compatible with spring .Net. > > Again, I see a NMS implementation as a way of speeding up AMQP adoption > within the .Net community. We will have a WCF channel and a BizTalk > adapter, NMS is just an additional advantage for people that don't want > to deal with the cumbersome BizTalk. > > Arnaud > > >
Re: [.Net] NMS
Legal issues are troublesome for end users; it's the end users who get told to cease and desist! Also, I +1 Rob on the WCF front; it's WCF that Windows users will be using. They won't care about JMS at all. NMS only exists because JMS has no wire level transport It would be a mistake to say Spring are the same project on Java and .NET; We should target WCF as our user visible API on .NET. There will be WCF drivers for all major middleware products and 3rd party technologies will be plugging into WCF - not NMS. How we implement WCF then matters less; but NMS is unlikely to be the optimal way. Cheers John On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > As I said, we would not define the NMS API as we do not change the JMS > > API. We would only implement it. > > But we do currently extend JMS, through the use of eg > org.apache.qpid.jms.Session extends javax.jms.Session. We can extend it but the API itself is not changed. > > I don think that implementing NMS would impact upon interop. An I agree > > with you that having an API isn't enough but again I am suggesting that > > we define it but that we implement it. Moreover this code should not > > even be hosted by our project but rather on the NMS Apache project. > > But to implement it we need a clear understanding of the precise > semantics. If they are defined to be "exactly the same as JMS" (which > itself is open to interpretation in a few areas!) then that is a start > I suppose notwithstanding the legal issues with that. I suppose that the NMS project would have to worry about legal issues. > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions > can they be exposed elegantly with that model? I know a person that already has a WCF channel based on NMS. We would therefor be able to reuse it without any change. We would also gain being compatible with spring .Net. Again, I see a NMS implementation as a way of speeding up AMQP adoption within the .Net community. We will have a WCF channel and a BizTalk adapter, NMS is just an additional advantage for people that don't want to deal with the cumbersome BizTalk. Arnaud
Re: [.Net] NMS
On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > As I said, we would not define the NMS API as we do not change the JMS > > API. We would only implement it. > > But we do currently extend JMS, through the use of eg > org.apache.qpid.jms.Session extends javax.jms.Session. We can extend it but the API itself is not changed. > > I don think that implementing NMS would impact upon interop. An I agree > > with you that having an API isn't enough but again I am suggesting that > > we define it but that we implement it. Moreover this code should not > > even be hosted by our project but rather on the NMS Apache project. > > But to implement it we need a clear understanding of the precise > semantics. If they are defined to be "exactly the same as JMS" (which > itself is open to interpretation in a few areas!) then that is a start > I suppose notwithstanding the legal issues with that. I suppose that the NMS project would have to worry about legal issues. > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions > can they be exposed elegantly with that model? I know a person that already has a WCF channel based on NMS. We would therefor be able to reuse it without any change. We would also gain being compatible with spring .Net. Again, I see a NMS implementation as a way of speeding up AMQP adoption within the .Net community. We will have a WCF channel and a BizTalk adapter, NMS is just an additional advantage for people that don't want to deal with the cumbersome BizTalk. Arnaud
Re: [.Net] NMS
On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: As I said, we would not define the NMS API as we do not change the JMS API. We would only implement it. But we do currently extend JMS, through the use of eg org.apache.qpid.jms.Session extends javax.jms.Session. I don think that implementing NMS would impact upon interop. An I agree with you that having an API isn't enough but again I am suggesting that we define it but that we implement it. Moreover this code should not even be hosted by our project but rather on the NMS Apache project. But to implement it we need a clear understanding of the precise semantics. If they are defined to be "exactly the same as JMS" (which itself is open to interpretation in a few areas!) then that is a start I suppose notwithstanding the legal issues with that. Does WCF sit easily on top of NMS? If we have Qpid-specific extensions can they be exposed elegantly with that model? RG
Re: [.Net] NMS
On Fri, 2007-06-01 at 10:21 +0100, Robert Greig wrote: > However I would argue that having the same API across different > languages is not actually that useful in all cases. In particular, > where there is an established API in a language/platform that users > are "likely" to be familiar with or use first. > > In the Java world, we obviously have JMS and that is why I have always > said that no matter what we think of JMS any Qpid API must be an > extension of JMS not a different approach. The situation where you say > to users "if you want to use you need to use our > other API and rewrite your application" is just unacceptable. +1 > Having another API that we would support that sits under WCF is just > making work for ourselves. If you have an API you have to document it, > you have to promise to support it and not change it randomly from > release to release and you have to be able to justify to users why you > have several APIs. As I said, we would not define the NMS API as we do not change the JMS API. We would only implement it. > On the subject of NMS, are its semantics documented carefully? We know > from our experience of the JMS TCK that without clear and precise > documentation (and ideally a test suite) it wouldn't really offer > interop. Having an API isn't enough - for it to be worthwhile you need > to offer users clear semantic guarantees. I don think that implementing NMS would impact upon interop. An I agree with you that having an API isn't enough but again I am suggesting that we define it but that we implement it. Moreover this code should not even be hosted by our project but rather on the NMS Apache project. Arnaud
Re: [.Net] NMS
On 01/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote: Standardizing on APIs that others are already using sounds like a worthwhile thing to me. I certainly think the performance impact of the layers is important to consider. However I would argue that having the same API across different languages is not actually that useful in all cases. In particular, where there is an established API in a language/platform that users are "likely" to be familiar with or use first. In the Java world, we obviously have JMS and that is why I have always said that no matter what we think of JMS any Qpid API must be an extension of JMS not a different approach. The situation where you say to users "if you want to use you need to use our other API and rewrite your application" is just unacceptable. Now I am not terribly familiar with .NET but from my casual observance it appears that WCF is likely to be the standard API that people are going to be familiar with. If that is true, then I should have thought that WCF ought to be the basis of our client implementation with any Qpid-specific functionality available through that API (I have no idea how it works for extension points etc.) Having another API that we would support that sits under WCF is just making work for ourselves. If you have an API you have to document it, you have to promise to support it and not change it randomly from release to release and you have to be able to justify to users why you have several APIs. On the subject of NMS, are its semantics documented carefully? We know from our experience of the JMS TCK that without clear and precise documentation (and ideally a test suite) it wouldn't really offer interop. Having an API isn't enough - for it to be worthwhile you need to offer users clear semantic guarantees. RG
Re: [.Net] NMS
On Fri, 2007-06-01 at 09:51 +0100, John O'Hara wrote: > The trouble with makeing a JMS-look-alike API is that the JMS specification > specifically licenses the technology "only for Java" or something like that. > > As part of keeping things clean, we really shouldn't be implementing a > JMS-alike API on Qpid; unless Apache is a Sun JMS licensee in some > capacity. So without advice from Cliff, I would say do something different. NMS is an Apache API that looks like JMS, I was not suggesting that we define NMS but that we implement it. As NMS is already an Apache project I don't expect any legal issues. > > We also know that an API closer to AMQP constructs will be more efficient, > and since people are likely to ultimately access the API through WCF on the > .NET platform, this would make for a more efficient mapping: > > BizTalk -> WCF -> ".NET AMQP API" I think that the bottleneck is more on the wire level and I therefor do not expect that adding one level of abstraction would impact on performances. > Finally, there will be some work done to standardise the "shape" of the API > across languages/implementations later this year. That API is likely to > look AMQP'ish, not JMS like. This is certainly a good thing to do. However, currently NMS is an Apache API that is integrated with Spring .Net that a lot of people also use in conjunction with WCF. I would say that NMS support will be done on top of the AMQP'ish interface. It has two main advantages: 1) provides .Net programmer with a know interface 2) Allows AMAP to be plugged within Spring .Net 3) Increase reuse of WCF and BizTalk components 4) We can drop support when the AMQP'ish API is widely adopted Arnaud
Re: [.Net] NMS
I meant: BizTalk -> WCF -> NMS -> Qpid AMQ API -> framing layer versus: BizTalk -> WCF -> framing layer NMS -> framing layer Qpid AMQ API -> framing layer Rupert On 01/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote: Standardizing on APIs that others are already using sounds like a worthwhile thing to me. However, there is something I wonder about, and I also wonder about it with the proposed more layered Java client too: Will the stacking of API's slow things down? (for small messages, low latency requirements, obviously large messages i/o bound to network). A call to send a message goes through: BizTalk -> NMS -> Qpid AMQ API -> Framing layer -> Which is potentially a very long chain of method calls before your message gets down to the wire. It all depends which part of the chain is the bottleneck. For example, in the Java code the framing layer is definitely the bottleneck at the moment, so adding more layers above might not significantly change things. Where is the bottleneck in the .Net client? Might it be better to implement things like: BizTalk -> Framing layer -> NMS -> Framing layer -> AMQ API -> Framing layer -> for example? Rupert On 31/05/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote: > > Arnaud, > > > When looking at the .Net client it came to me that we should look at > > what the guys from ActiveMQ have done. They have created an Apache > > project that defines a .Net Messaging API. The project name is NMS > > for .Net Message System API which is an interface to messaging systems > > rather like JMS is for Java (the project can found here: > > http://activemq.apache.org/nms/what-is-nms.html ) > > > > The main strengths of NMS are that it is already implemented > (ActiveMQ, > > STOMP and MSMQ) and integrated with Spring. Note that I know people > > form > > the industry that use NMS (especially the ActiveMQ implementation). > > > > The idea would be to first implement NMS and then use it to implement > a > > WCF channel or a BizTalk adapter. Thus, the way things would > > look is: > > WCF channel <-- > > - NMS implementation (C#) ---> Qpid broker > > BizTalk adapter <-- > > > > (We may have spring .Net in between the WCF channel and the BizTalk > > adapter) > > > > One main advantage of going this way is that we would be able to reuse > > existing WCF implementation done for ActiveMQ. > > > > It would be nice if the .Net guys (Carlos, Tomas, Marnie, etc.) can > > comment on that. We may even decide to host our NMS implementation on > > the NMS project. > > Thanks for the suggestion. I was not aware of this (indeed, I didn't > even > know ActiveMQ had a .NET implementation), and it certainly looks > worthwhile. > > I'll spend some time over the weekend looking at this and I'll post my > findings here. > > > Tomas Restrepo > http://www.winterdom.com/weblog/ > > > > >
Re: [.Net] NMS
Standardizing on APIs that others are already using sounds like a worthwhile thing to me. However, there is something I wonder about, and I also wonder about it with the proposed more layered Java client too: Will the stacking of API's slow things down? (for small messages, low latency requirements, obviously large messages i/o bound to network). A call to send a message goes through: BizTalk -> NMS -> Qpid AMQ API -> Framing layer -> Which is potentially a very long chain of method calls before your message gets down to the wire. It all depends which part of the chain is the bottleneck. For example, in the Java code the framing layer is definitely the bottleneck at the moment, so adding more layers above might not significantly change things. Where is the bottleneck in the .Net client? Might it be better to implement things like: BizTalk -> Framing layer -> NMS -> Framing layer -> AMQ API -> Framing layer -> for example? Rupert On 31/05/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote: Arnaud, > When looking at the .Net client it came to me that we should look at > what the guys from ActiveMQ have done. They have created an Apache > project that defines a .Net Messaging API. The project name is NMS > for .Net Message System API which is an interface to messaging systems > rather like JMS is for Java (the project can found here: > http://activemq.apache.org/nms/what-is-nms.html ) > > The main strengths of NMS are that it is already implemented (ActiveMQ, > STOMP and MSMQ) and integrated with Spring. Note that I know people > form > the industry that use NMS (especially the ActiveMQ implementation). > > The idea would be to first implement NMS and then use it to implement a > WCF channel or a BizTalk adapter. Thus, the way things would > look is: > WCF channel <-- > - NMS implementation (C#) ---> Qpid broker > BizTalk adapter <-- > > (We may have spring .Net in between the WCF channel and the BizTalk > adapter) > > One main advantage of going this way is that we would be able to reuse > existing WCF implementation done for ActiveMQ. > > It would be nice if the .Net guys (Carlos, Tomas, Marnie, etc.) can > comment on that. We may even decide to host our NMS implementation on > the NMS project. Thanks for the suggestion. I was not aware of this (indeed, I didn't even know ActiveMQ had a .NET implementation), and it certainly looks worthwhile. I'll spend some time over the weekend looking at this and I'll post my findings here. Tomas Restrepo http://www.winterdom.com/weblog/
Re: [.Net] NMS
The trouble with makeing a JMS-look-alike API is that the JMS specification specifically licenses the technology "only for Java" or something like that. As part of keeping things clean, we really shouldn't be implementing a JMS-alike API on Qpid; unless Apache is a Sun JMS licensee in some capacity. So without advice from Cliff, I would say do something different. This is the relevant license, copied directly from the JMS Spec document: "Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification internally solely for the purpose of designing and developing your Java applets and applications intended to run on the Java platform. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification." We also know that an API closer to AMQP constructs will be more efficient, and since people are likely to ultimately access the API through WCF on the .NET platform, this would make for a more efficient mapping: BizTalk -> WCF -> ".NET AMQP API" We know that JMS as an API for messaging leaves some things to be desired. We do it on Java because its what everyone expects and knows. We shouldn't carry JMS onto .NET without a really good reason, and some clear legal advice. Finally, there will be some work done to standardise the "shape" of the API across languages/implementations later this year. That API is likely to look AMQP'ish, not JMS like. What do you think? John On 31/05/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote: Arnaud, > When looking at the .Net client it came to me that we should look at > what the guys from ActiveMQ have done. They have created an Apache > project that defines a .Net Messaging API. The project name is NMS > for .Net Message System API which is an interface to messaging systems > rather like JMS is for Java (the project can found here: > http://activemq.apache.org/nms/what-is-nms.html ) > > The main strengths of NMS are that it is already implemented (ActiveMQ, > STOMP and MSMQ) and integrated with Spring. Note that I know people > form > the industry that use NMS (especially the ActiveMQ implementation). > > The idea would be to first implement NMS and then use it to implement a > WCF channel or a BizTalk adapter. Thus, the way things would > look is: > WCF channel <-- > - NMS implementation (C#) ---> Qpid broker > BizTalk adapter <-- > > (We may have spring .Net in between the WCF channel and the BizTalk > adapter) > > One main advantage of going this way is that we would be able to reuse > existing WCF implementation done for ActiveMQ. > > It would be nice if the .Net guys (Carlos, Tomas, Marnie, etc.) can > comment on that. We may even decide to host our NMS implementation on > the NMS project. Thanks for the suggestion. I was not aware of this (indeed, I didn't even know ActiveMQ had a .NET implementation), and it certainly looks worthwhile. I'll spend some time over the weekend looking at this and I'll post my findings here. Tomas Restrepo http://www.winterdom.com/weblog/
RE: [.Net] NMS
Arnaud, > When looking at the .Net client it came to me that we should look at > what the guys from ActiveMQ have done. They have created an Apache > project that defines a .Net Messaging API. The project name is NMS > for .Net Message System API which is an interface to messaging systems > rather like JMS is for Java (the project can found here: > http://activemq.apache.org/nms/what-is-nms.html ) > > The main strengths of NMS are that it is already implemented (ActiveMQ, > STOMP and MSMQ) and integrated with Spring. Note that I know people > form > the industry that use NMS (especially the ActiveMQ implementation). > > The idea would be to first implement NMS and then use it to implement a > WCF channel or a BizTalk adapter. Thus, the way things would > look is: > WCF channel <-- > - NMS implementation (C#) ---> Qpid broker > BizTalk adapter <-- > > (We may have spring .Net in between the WCF channel and the BizTalk > adapter) > > One main advantage of going this way is that we would be able to reuse > existing WCF implementation done for ActiveMQ. > > It would be nice if the .Net guys (Carlos, Tomas, Marnie, etc.) can > comment on that. We may even decide to host our NMS implementation on > the NMS project. Thanks for the suggestion. I was not aware of this (indeed, I didn't even know ActiveMQ had a .NET implementation), and it certainly looks worthwhile. I'll spend some time over the weekend looking at this and I'll post my findings here. Tomas Restrepo http://www.winterdom.com/weblog/
