Saturday, August 27, 2005

Which Framework Should I Use, .NET or J2EE?

(series cont.)

In this article, Matthew Murphy concludes by asking, "So Which Framework Should I Use, .NET or J2EE?"

One compelling answer is: Use both. Together.

If you've deployed an application server like JBoss or even a servlet container like Apache Tomcat, it is relatively easy to publish Java web services with Apache Axis. Likewise, it is incredibly easy to consume services in .NET. The bridge is XML. And by combining the built-in XSD tools of Visual Studio .NET (or a product like XMLSpy) and a Java-to-XML binding product like Castor, you can build a completely interoperable application in an amazingly short amount of time.

XML works great if you need to pass a complex object from a .NET client to a Java web service. One way to do this is to pass the XML as a byte array and unmarshal it on the other side. You can even compress the array before it goes. Though this is not extremely straightforward, Castor and C# make it relatively easy to do. When a complex object is not necessary or required, I have not experienced a problem with passing primitives, or arrays of primitives, between the two technologies. One exception would be passing a Date. The way I've worked around this problem is to format the date with W3C formatting and pass it as a string.

Another pretty cool feature of this architecture is that C# .NET reports exceptions that occur on the Java web service side. I believe this is due to C# .NET's handling of SOAP faults and wsdl:faults.

The potential snag that I've faced with this architecture is that C# .NET does not have a remote transaction manager (as far as I know). Where we've needed rollback capabilities, we've had to build processes from scratch. I understand how critical this is, but we've found ways around it (admittedly not as elegant as a remote transaction manager...)

So why go down this road? I believe that we're delivering best-in-class technology solutions to our customers. By "best-in-class", I mean a rich UI that is not sluggish or awkward and that users are actually impressed with and identify more with as an installed application. And importantly, a UI that is actually distributed over the web and utilizes HTTPS. Then that, coupled with server technology that is extremely reliable and secure as well as open and portable.

No comments: