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/ > > > > >
