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
