.NET/Java Interop is not a reason for SOA

I see this all too often.

A company has some legacy (read "good") code in one platform (let's just use Java for this example). This company has now decided to standardize on the other platform (Microsoft's happy). The company doesn't want to throw away and/or rewrite the assets they already have from the previous platform.

What do they do?

Web Services, of course!

Obviously this has to be a part of the "grand" SOA effort currently under way. Here's a chance to build some reusable services, right?

The only problem is that in order for things to work right they (sometimes, but way too often) implement a chatty interface between the two platform-oriented services and flow transaction contexts between them as well as use other poor practices.

So, what's the solution?

Well, Web Services isn't the only kind of interop out there. Take a look at what the guys from MainSoft are doing. Not only does it work, it's been working for years now. You can go the other way too - run .NET code on JVM based application servers. And there are more solutions out there. There's JNBridge (with some nifty online demos), and EZ JCOM who also do COM interop.

Bottom line, there are good technical solutions out there for reusing and interop-ing with assets from multiple platforms. Therefore, now that we've slain the holy cow of interop, there is absolutely no good reason or justification to create tightly coupled services.

Period.

Posted by Udi Dahan at 04:09 PM  Permalink