JavaOne 2006 - Interop Session (Web services and MainWin)
JavaOne2006 - Interop Session
I went to a few sessions at JavaOne 2006. One was called Best
Practices for Interoperability Between Java Technology and .NET
Server Applications - it was put on by Ray Lai, an independent,
and Marina Fisher of Sun, along with Larry
Moroney of MainSoft. This was a pretty
popular session, I would guess somewhere between 500 and 750
people were in attendance. Apparently it's a topic of interest!
About half of the session covered options for
interconnecting Java apps with .NET, including webservices and
other approaches. The second half wasn't really interop; instead it covered
Mainsoft's Mainwin product.
In the section covering webservices, Ray Lai gave some very
good advice: start with schema first, confine your interfaces
to a simple subset of XML Schema. Test often. Look out for edge
cases. All good stuff. By the way, that applies regardless of the endpoints: Java, .NET, PHP, C++, or anything else.
Marina Fisher talked about other possibilities for interop.
Message queues, for example - a good interop mechanism. She did
not mention that MSMQ can be an effective bridge between Java
and .NET. She implied that it would take a JMS bridge and some
other magic, when it's actually much simpler than that, as I
have previously described. The simple approach also works with
IBM MQseries (and I sound like I am repeating myself, but yes, I
have described that previously, too)
But for the most part, the interop portion of the session
was good, solid, fundamental advice.
On to Mainwin
Then we moved to the Mainwin portion of the session. MainWin
apparently allows people to develop in ASP.NET apps in Visual
Studio, then run the result on a J2EE-compliant app server.
This isn't interop per-se, or at least I don't think of it as
interop. It is more like cross-compiling or cross-targeting,
rather than inter-system communication. So I felt it was a
little out of place in this session. But it wasn't my session
and they didn't ask me, did they?
Mainsoft, I gather, is able to pull off this magic by
translating MSIL to Java bytecode. That takes care of the
ASP.NET app itself, but what about the underlying ASP.NET
runtime? Well, apparently Mainsoft also ran the
MSIL-to-bytecode translator on the .NET runtime from project
Mono. So the app, plus the underlying ASP.NET runtime, are all
compiled into Java bytecode. The result just works, so they
say; it just runs on a J2EE container. (I didn't try this)
I suppose there would be a few problems, for example, if you
tried to reference a class that Mono does not implement, or if you
tried to reference a 3rd-party assembly from within the ASP.NET
app - let's say you wanted to connect to IBM MQSeries from
within the app via the IBM MQ Classes for .NET. I don't think
this assembly is available (in translated form) on the Mainsoft
runtime. Not sure, though. I'm just guessing.
Also, I don't know if Mono has kept current with ASP.NET 2.0,
including the membership stuff, and the other providers.
What about Licensing?
One of the first
questions the audience asked was, "what about licensing - are
there license implications if you run ASP.NET on J2EE on Linux,
for example?" The answer from Mr Moroney of Mainsoft was: "No. No
license is required."
Needless to say, this was a surprising answer. Microsoft
considers .NET to be its intellectual property. We've invested
considerable effort building .NET, including ASP.NET. Part of
.NET was standardized with ISO
and ECMA
- that part includes the C# language as
well as a subset of the CLR and the .NET base class
library. Part of .NET was not submitted to ECMA or ISO.
Mono replicates the stuff that is standardized, but goes
further by also replicating the parts of .NET that are not
standardized, and adding other pieces. The second category of
stuff (parts of .NET that are not standardized) are Microsoft's
intellectual property. For someone from Mainsoft to say "there
are no license implications" ignores that fact. Even the Mono
website doesn't
say that. I don't know of an agreement between Mainsoft and
Microsoft on the license of this particular technology. Nor do I
know of any agreement between Microsoft and Novell (owner of the
Mono project) on same.
I am not a lawyer, but "no problem, dude!" seems like too
quick an answer to me. I pointed that out in the room, when I
got a chance to speak.
Downplaying web services?
I also did not agree with the spin on webservices from
Mainsoft. Essentially it was, "Did you see all those
interop pitfalls Ray Lai pointed out? Use Mainwin and get
interop, while avoiding that stuff." I am paraphrasing, but that
was the honest gist of it.
That seems like overselling to me. My position: Web services works, and
works well. This approach solves lots of problems today, and it
is the main area of interop investment by Sun, Microsoft, IBM,
and many other companies. It works today, and it's mostly
pretty easy, and it's just going to get better. The correct
message is: You should have exceptional conditions to do
something other than webservices for interop today.
And ...re-hosting ASP.NET on a J2EE container, aside from going into unexplored IP territory, isn't really interop anyway.
Cheers,
-Dino
Comments
- Anonymous
May 22, 2006
The mainSoft thing Sounds a lot like good old IKVM.NET (http://www.ikvm.net) which I know to be around for quite a while. It allows you to use DotNET from Java transparently and vice versa.
It works with Mono 1.1/MS. NET 1.1
I've been using it extensively in the past compiling using Mono.NET and then deploying to a Microsoft based Java environment (using MS .NET framework). Of course, I happen to stay away from ASP/WinForms, but hey.... others are talking Web Services on this page.... so that shouldn't be a real limitation.
PS. work seems underway with winforms (IKVM comes with some Dll's suggestive of things WinForms)
What does mainSoft offer that wasn't mentioned yet (aside from the marketing)? - Anonymous
May 22, 2006
Regarding "if you tried to reference a class that Mono does not implement" and "let's say you wanted to connect to IBM MQSeries from within the app"
Since the resulting code is a native java byte code, you can just call the MQSeries java API directly and you do not need to use the "IBM MQ Classes for .NET." . In fact, you are open to use any Java class library from ASP.NET using the MainWin product. So, if you are using a 3rd party assembly and you do not have the source code for it, just code again the Java alternative. - Anonymous
May 23, 2006
The comment has been removed - Anonymous
May 24, 2006
re: "you are open to use any Java class library from ASP.NET using the MainWin product"
ok, that sounds like a flexible approach. Does it work? What does it look like? What is the syntax in an ASP.NET code-behind file, to reference, for example, com.ibm.mq.jms.*? Do I use a "using" statement or an "import"? or something else? Do I get intellisense (code completion)? And what are the implications, for when I want to do PCF, for example, which involves callbacks? Can I code the callbacks in VB or must I use Java (to get proper type matching)? Essentially, are there seams between the Java world and the .NET world - it seems there are.
Stepping back just a bit, this feels sort of hacky to me. Coding Java APIs in ASP.NET - is that a friendly place for a Java developer? Probably not. for a VB developer? definitely not. So who is it good for?
The entire premise of MainWin's approach is hand-wavey. Larry Moroney said in the presentation, "we all know the problems with scalability and reliability of Windows Server and .NET." that's not a verbatim statement, but it captures the gist of a statement he made. Do we all know this? What hard data shows it? If you are going to point to Melissa or Slammer or other 3-yr old issues, remember that most of these dealt with security holes that had been fixed, well prior to the broad events in question. The issue isn't "product X is insecure"; in fact the problem was more accurately stated, "microsoft patches for known exploits were not being deployed when they became available."
It is easy to toss off statements like "Microsoft software is insecure", but statements like that deserve examination before using them as a justification for adopting an approach that introduces new seams, new moving parts, new complexity into a system. Larry didn't offer any data in the presentation. Just "we all know Microsoft is insecure." But the data I have seen from Secunia (http://blogs.msdn.com/michael_howard/archive/2004/10/15/242966.aspx) shows, for example, fewer security vulnerabilities in IIS6 as compared to Apache 2.0 or Apache 1.3, over the same period of time. These facts don't support Moroney's conclusion.
Certainly, that's just one small slice of data. The web engine is not the entire platform. That bit of data certainly doesn't settle the question of security. But the point is, without a thorough examination of the data, it is irresponsible or sloppy to conclude "Windows Server security is substandard" and then take architecture decisions based on that unsupported conclusion.
When designing an interop strategy, it seems hasty to rule out mainstream approaches like webservices or bridging, based on unsupported assumptions.
-Dino - Anonymous
May 24, 2006
The comment has been removed - Anonymous
May 24, 2006
re: "we believe in the community’s strategies for dealing with any legal issues surrounding subsets of this open source implementation the .NET framework. "
Laurence, after the session, I believe you said you would check into the license issues. Have you done that? What did you find? Did Mainsoft sign a license with Microsoft for the relevant intellectual property?
"We believe in the community's strategies..." is a pretty fuzzy statement. - Anonymous
May 24, 2006
The comment has been removed - Anonymous
June 01, 2006
The comment has been removed - Anonymous
June 22, 2006
Re licensing...MainSoft has had deals with Microsoft. How deep and long they go I dont know... but here is Bill Gates talking at UnixExpo in 1996[http://www.microsoft.com/billgates/speeches/industry&tech/uexpo.asp]
"Now, as we recognize that large Unix space that's out there, there's a lot of things we've done to make these things fit together. First is this idea of taking a Windows application and running it on Unix. And we have three partnerships that fit into this:Wyse provides the Windows interface source environment, and we work together with them to make sure they've got the very latest Windows API technology. Bristol and Mainsoft also provide source and binary compatibility, and again that's a close relationship where it's not just some old version of Windows, it's the very latest." - Anonymous
July 09, 2006
Jack Vaughan, thanks for pointing out what may not have been obvious: there is a business relationship between Microsoft and Mainsoft. The nature of the license agreements in that business relationship is what is at question here.
-Dino