JavaOne 2006 – Interop Session (Web services and MainWin)

JavaOne2006 - Interop Session

I went to a few sessions at JavaOne 2006. One was called href="">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 href="">Larry
Moroney of href="">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 href="">ISO
and href="">ECMA
- that part includes the href="">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 href="">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 ASP.NET on a J2EE container, aside from going into unexplored IP territory, isn't really interop anyway.



Comments (10)

  1. Seth Heeren says:

    The mainSoft thing Sounds a lot like good old 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)?

  2. Oved Yavine says:

    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.

  3. After spending several years architecting interoperability solutions in the financial services sphere, I have come to the conclusion that, despite their power and flexibility, Web services aren’t a magic bullet to easy integration, and they’re are not always the best solution to interoperate divergent platforms.  Among the many challenges of working with Web services is the interchange of complex data types. At the JavaOne interop session, Ray Lai demonstrated a case where even a simple data type passed between services can cause problems when the services are on different technology stacks.

    One of the main objectives of the JavaOne talk, and the new interop book ( , is to empower developers, architects and development management to look at the options that are available in solving infrastructure interoperability needs, beyond just Web Services. This excerpt, for example, published on Dr. Dobbs at looks at mixed-mode architectures from the point of view of the implications of managing the runtimes when choosing among different interoperability options.

    I encourage you, and your readers, to take a look at Mainsoft’s and other interop solutions, kick the tires as it were, and decide for yourselves which solution best address your interoperability needs.  The challenges facing companies and developers today are very complex, and growing more complex by the day. The pressures facing us as a developer community are going hand in hand with that. Anything that helps us spend more time focusing on solving business problems, instead of the underlying technology ‘plumbing’ that may not be necessary, is a good thing in my honest opinion.

    One final point is about licensing. Mainsoft is a long-time Mono contributor and development partner, and we believe in the community’s strategies for dealing with any legal issues surrounding subsets of this open source implementation the .NET framework.  We’re not doing anything unique here.  

    Next up, Mainsoft and Mono are working closely together on developing the .NET 2.0 implementation. It’s a big project, Microsoft has put a lot of good stuff in there, and the community has been investing extensively in it. We’ve already successfully run strong advanced samples on the Mono 2.0 framework and encourage you to stay tuned…


  4. cheeso says:

    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,*?   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 ( 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.  


  5. cheeso says:

    re: "At the JavaOne interop session, Ray Lai demonstrated a case where even a simple data type passed between services can cause problems when the services are on different technology stacks. "

    Yes, but!!   Ray also pointed out some simple rules and conventions to follow, in order to avoid those problems.

    Ray’s recommendations are very similar to the ones Microsoft and others have been making since way way back.  I posted just a couple weeks ago on this topic:

    But the fossil record shows we have been  giving this same advice, as far back as 2003, when we all were still learning about web services and interop.

    Bottom line, it’s not that complicated to get it right. Follow the rules, and you can do it.  As Ray pointed out, the mainstream tools are getting ever better at helping out. You don’t need special purpose whiz-bang third-party tools to do interop effectively.  Built-in webservices support in the various platforms (Java, .NET, PHP, etc) are going to get you where you need to go.  

  6. cheeso says:

    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.

  7. lmoroney says:


    I agree with you — the rules and conventions Ray outlined during the session can work really well when you have new product development and relatively simple problems.   And, like so many of my peers, I welcome any and all progress that Microsoft and Sun are making on the Web Services interop front to help make all our lives easier.

    On the other hand, I know countless architects and developers working late at night, attempting to interop existing complex applications for which they have the source, as well interop with components written by

    third parties, for which the source is not available.  A frustrated Java architect summed it up well during last year’s JavaOne 2005

    session, ‘On the Couch with Sun and Microsoft.’  He asked, "What do I do, if I’ve done everything you [Microsoft] have told me to do, and it still doesn’t work?"  Bottom line — there’s a ton of effort needed to rework applications on both the .NET and Java side in order to put in these ‘simple rules and conventions’ into practice.

    I do want to clarify what I said during the conference about security, because it is an important point, and it’s definitely ***NOT*** my conclusion that Microsoft’s products are insecure.  The progress Microsoft has made on the security front is remarkable; Windows Server 2003 is a top notch product [a fact that I stated at the conference].  My point is that perception in the field hasn’t necessarily caught up with reality, and today, I see many data center folks who ‘perceive’ MS software and hardware to be insecure and make their IT decisions accordingly.   This perception gap, and many enterprises’ heavy reliance on Visual Studio developers and the powerful Visual Studio .NET

    IDE, is one of the key reasons virtually all medium- and large-scale data centers have both .NET and Java.  (M&A’s are another)

    Security is an even bigger issue in a mixed mode environment.  After all, with two security architectures/authorities, who’s in charge?  Mainsoft’s software is very effective at addressing the security issue in connected

    systems, for example with an .NET front end and EJB back-end.   Unlike with Web services, where developers would need to create a new layer into the middle of their architecture to get the EJB to talk to the .NET-based presentation tier, they can use Mainsoft’s product to rehost their presentation layer on the same middleware, operating system and

    hardware as the EJBs, thereby reducing the number of potential intrusion points and potential points of failure, as well as simplyfying their software and hardware architecture.

    Mainsoft’s cross-platform engine is built on Sun’s and Microsoft’s common ground, described by Jonathan Schwartz as the strong similarity

    between Java Bytecode and the byte code of the Common Language Runtime

    Our product suite rehosts Mono’s implementation of the open source .NET

    framework on Java.  The runtime has been validated ‘Java Powered for the Enterprise’ and ‘Ready for IBM WebSphere’ Software.  More detailed info is here:

    Grasshopper, Mainsoft’s freely available developer edition, can be downloaded at if you want to give it a try.

    I don’t have much to add on the licensing front.  Our policy is in line

    with Novell’s and with Mono.  

    And as for the rest, well, I suppose we’ll have to agree to disagree.

  8. cheeso says:

    Hey Larry,

    First: you need your own blog. 😉

    You said, A frustrated Java architect summed  up the issue well well during last year’s JavaOne 2005

    session, ‘On the Couch with Sun and Microsoft’ by asking, "What do I do, if I’ve done everything you [Microsoft] have told me to do, and it still doesn’t work?"  

    Interesting question. In my experience, that never happens.  Every time someone comes to me with an interop challenge, I start from the beginning, follow the rules, and it just works. In many cases the tools need to get better at pointing out little things – one time someone had changed the schema namespace to include a trailing slash, and that caused the interop to break. The namespace was 55 characters long, and it was a perfect match, except for the trailing slash.   The tools ought to be able to find those sorts of mismatches, rather than relying on sharp human eyes and meticulous examination.

    Many other interop challenges occur because people don’t or can’t follow the schema-first recommendation.  Or they don’t follow the recommendation to use doc/lit.  

    If they follow the rules, it works.  The person who asked the question needs guidance, not another approach, or a third-party product.

    Larry, you also said, "Bottom line — there’s a ton of effort needed to rework applications on both the .NET and Java side in order to put in these ‘simple rules and conventions’ into practice. "

    No way.  The first steps are relatively easy, which is why XML and web services traffic on corporate networks has ramped up so much.  People are doing it.  It’s much simpler than building an EJB, let me tell you!  The hard parts come when you get to enterprise-wide schema sharing, and versioning.  But that’s another topic.

    As for security – you mentioned that MainWin "addresses the security issue…"  Web services is primarily about enabling loose coupling.  Security is necessarily federated in such an environment.  Running .NET on top of a JVM isn’t "solving" the problem, so much as avoiding it.  If I run .NET on top of a JVM, the systems are no longer loosely coupled, now, are they?  They’re tightly coupled and we’re back to all the challenges associated with that..the challenges that resulted in the web services revolution in the first place.  This is what we’re trying to get away from.

    This gets back to my view, that the MainWin product set is not about interop.  It is about skills migration, or better, skills redirection – that is to say, enabling .NET developers to build on an expensive Java-based platform like Websphere.  This is a reasonable goal to have, if you are IBM or an IBM partner, and you can see the positive developer momentum behind .NET.  They want those .NET developers!  But couching this approach as interop, or as an alternative to web services, is twisted logic.

    Larry, respectfully, if you want to respond, I suggest you do so on your own blog (suggested title: "DotNetSkillsRedirection"), not here on DotNetInterop.  Your responses sound less like engaging on the issues (re: licensing, you wrote "I don’t have much to add"), and more like a commercial advert for MainWin stuff.  With all due respect, please find another outlet for your ads.

  9. Jack Vaughan says:

    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[]

    "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."

  10. cheeso says:

    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.


Skip to main content