Considerations for a highly-interoperable SOA implementation with Java?

It's be开发者_如何学运维en more than two years since someone asked "Which SOAP XML object serialization library for Java would you recommend?" and assuming a lot of things changed since then, I believe that's enough of a good reason to revamp the topic.

So in lieu of implementing SOA in Java that will be as interoperable as possible with the .NET Framework (or any other enterprise platform for that matter), in a first analysis I'm considering going with Apache Tuscany but I was wondering if there's any reason I should not? Any feedback will be definitely appreciated.

---

Actually, the first consideration I'd make is "do I really need SOAP/XMl?".

In particular:

• WSDL is not nearly as cross-platform as is suggested; it is very easy to get cases that don't work well (there was one here on SO re PayPal earlier this week)
• XML is human readable... But as a result is relatively slow and bloated

There are other ways of sharing a definition - for example, we all manage just fine with an API document that says "this API returns JSON in this shape {...}". WSDL mainly seems to help drag-and-drop developers; of which I am not one.

As such, I suggest looking at simpler (think: YAGNI) protocols. For payload, I'm a big fan of protobuf, which deliberately is a simpler schema and therefore allows for much less uncertainty over what can/can't be handled by different implementations, while still covering every sane use-case. It is also very efficient or both CPU/bandwidth. Very portable, and has a schema definition language (.proto) for defining the data, but MUCH simpler than WSDL. Shock horror! It isn't human readable... Well, there are tools for that :) why impose the failings of us week and slow flesh-based units on our APIs?

---

We use the metro framework and so far it has proven to be highly interoperable with WCF including complex message level security using mutual certificate authentication and username token. In our case WCF is server and Java is client.