Ten things that happened 10 years ago:

1. In January, Sun and Microsoft settled their suit. Sun had sued Microsoft for incompletely implementing the Java 1.1 standard. Microsoft paid Sun $20 million, and agreed to phase out their version of Java.
2. J2SE 1.4 was released on February 6, 2002.
3. Microsoft .NET Framework version 1 was released on February 13, 2002.
4. JNBridgePro version 1.0 was released June 3, 2002. Version 1.0 was a one-way bridge that allowed .NET to call Java.
5. JNBridgePro version 1.1 was released on August 9, 2002, it added support for J2EE.
6. JNBridge’s press releases early in the year instructed the reader how to pronounce .NET (“dot net”).
7. JNBridgePro version 1.2, released November 8, 2002, added “one-and-a-half-way” bridging, allowing implicit calls from Java to .NET.
8. The first commercial application using JNBridgePro pulled media advertising information from a Java-based system for a search engine company. A version of that application is still in use today.
9. The second commercial application using JNBridgePro enabled a financial call center to strip Java-based telephony information and pop it into .NET-based screens. That application has been performing flawlessly for almost 10 years.
10. We started bidding on “Java” and “.NET” keywords in Google AdWords in September.  .NET was so new that Google search didn’t know what to make of it yet, so our initial campaigns included lots of negative keywords such as fish and fishing.
11. Going to 11, ten years ago the JNBridge logo looked like this. Good grief!

2010 brought a huge transition to JavaOne, as it morphed from its own event in the Moscone Center under the auspices of Sun to a satellite event of Oracle Open World, relegated to a rabbit warren of hotels around Union Square. Despite all the resulting downsides, we had a good show, as we got to engage with what became new customers and help them quickly solve their interoperability pain.

This year, the downsides have tipped the scale, and we decided to pull out. This decision wasn’t taken lightly — backing out of a commitment is a serious, angst-raising business around here. It wasn’t any single thing, but a whole lot of small things that pushed us away.

We don’t wish to sound snarky or petty, but little things matter, a lot. Despite signing on the dotted line to exhibit in 2011 at the 2010 show, we, like the rest of the world, were left in the dark to interpret bits of speculation in the media about whether JavaOne 2011 would even happen.  When it was announced last April, we were left to discover the news on the web — somehow we’d fallen off of the exhibitor email distribution list, and we stayed off.  When we finally woke up and realized what had happened, it was too late — the desirable hotels were booked, and the stress level of trying to get the team into decent housing was the final straw. This was on top of the hay pile of stuff we experienced last year. No media services: the media room was way off in the bowels of the Moscone Center, journalists and analysts either couldn’t find us or couldn’t fit the 15 minute trek uphill into their crowded schedules.

Other downsides weren’t exclusive to us, they impact all attendees. Relegating JavaOne to the outskirts of Oracle Open World forces it to be a bastard step-child — there’s no way a show of what’s now reduced to 3000 attendees can get the attention it deserves while competing for resources against a 40,000 attendee show. Many services, like extended registration hours and evening events, are that 15-minute walk away. The physical location is a rabbit warren – making both sessions and the exhibit floor difficult to find, so everyone struggles just to figure out where they are going. Gone are the chance confabs in the hall. Gone is the ability to walk up to anyone at the party and ask “so, what do you think?”, as in all probability are they are attending a very different event. We maintain that the Java community deserves better.

Finally, we recognize that we embarked upon a costly experiment some years ago. Would spending our resources and our time on trade shows be fruitful? It’s a tough and rather subjective thing to measure. In retrospect it was probably the right decision. But times have changed, and we now need to experiment with other ways to engage. Look for us in other venues in the coming months and quarters. If you have a preferred way of interacting, we’re all ears!

So, farewell JavaOne. We wish you, and the Java community, much success.

Addendum: Wayne Citrin, our CTO, will be wandering the halls the first two days. Give him a shout at @waynecitrin if you’d like to hook up.

We’ve spent some time with Windows 8, and we’re happy to report that JNBridgePro, as it’s currently released, already works just fine with Windows 8 in desktop mode. So, if you’re already using JNBridgePro and want to move your application to Windows 8, or to create a new application for the Windows 8 desktop, JNBridgePro is as easy to use as always.

We’re also happy to report that the JNBridgePro plug-in for Visual Studio will work with the upcoming Visual Studio 11 Developer Preview with only minor changes, which will be incorporated in an upcoming JNBridgePro release.  This means that JNBridgePro will be ready for the new Visual Studio by the time VS 11 is released, and likely sooner.  In the meantime, if you want to use JNBridgePro in conjunction with VS 11 development, we recommend using the standalone proxy generation tool.  If you’d like to be a tester for the JNBridgePro plug-in for VS 11, please contact us.

As might be expected, Metro-style development, along with the more restrictive WinRT and new .NET Metro profile, offer a few challenges.  During the run-up to the Windows 8 release, we will be addressing those challenges.

We’d be interested to know whether any customers or prospective customers are planning to produce Metro apps, and whether they anticipate building .NET/Java interoperability into those applications.  If you are planning to produce such applications, we’d like to hear from you, and work with you, at this early stage in the Windows 8 product cycle — please contact us.

Over the coming months, we’ll periodically post new blog entries discussing interesting technical aspects of Metro and WinRT, as they affect interoperability.  We expect to learn a lot during this process, and we look forward to sharing it with you.

This new version supports Java/.NET interoperability projects where one or both of the end points are in the cloud. JNBridgePro 6.0 enables you to build and distribute integrated applications anywhere, including:

• Intra-cloud, where both end points reside in the same cloud, either in the same or separate instances
• Inter-cloud, where the instances belong to different clouds — even across cloud vendors
• Ground-to-cloud and cloud-to-ground, where one end point is in a cloud instance and the other is an application running on the ground

JNBridgePro 6.0 extends its full set of interoperability features from the ground to the cloud, so now you can build integrated applications that run anywhere. Read more details and check out some sample use case scenarios.

You may have recently seen a wee bit of press about our launch. As Michael Coté from RedMonk says: “There’s so much valuable data and process locked in Java and .Net applications that can’t just be left behind in whatever cloud-y future is out there – and refactoring all of that to be cloud friendly would be an onerous task. Instead, you need tools that help modernize those pools.”

Try it out for yourself! We’re eager to hear what you think.

It doesn’t work

“It doesn’t work”? is an extreme statement, isn’t it? And Microsoft has demonstrated that it can create Java Web apps and run them on Azure, so why do I say it doesn’t work? The problem is that these examples are extremely constrained. For example, Azure makes a virtue of its lack of a persistence mechanism. Instances can fail or restart at any time, which means that data isn’t persistent between instances, and applications therefore must not depend on persistent data. However, both Java Web applications and the servers they run on do depend on some sort of persistence or state. With effort, the applications can be re-engineered, but one has to wonder whether it’s worth the effort to do this, or whether the time might be spent moving to a different cloud offering where this re-engineering doesn’t need to be done. There’s also the problem that the Tomcat and Jetty servers themselves require persistent data to be stored. And the problem gets even worse when we go from a simple servlet container to a full-fledged application server like JBoss, WebLogic, or WebSphere: application servers, and the Java EE programs that run on them, rely even more deeply on persistent data. While some Java EE application servers can be altered to use alternative persistence mechanisms like Azure storage, the process is arcane to most Java EE developers and not worth the trouble; it would probably be simpler to use a cloud offering where the application server can be deployed without alteration.  In addition, a default application server relies on an extensive array of network endpoints for a variety of protocols that exceeds the number allowed by a worker role or a VM role. To run an app server on Azure, it is necessary to cut down the number of endpoints to the point where much useful functionality is lost. While it may be possible to construct Java EE examples that work as demos, it’s unlikely that any real Java EE apps, web-enabled or otherwise, can be migrated to the Azure cloud without drastic, impractical or impossible, modifications to the underlying application servers in order to accommodate the persistence and networking issues.

It’s not what users want

Beyond the technical issues in getting an app server running on the Azure platform, we need to ask why we would want to do this on a Platform-as-a-Service (PaaS) such as Azure, when it would be far simpler to run such an application on an Infrastructure-as-a-Service (IaaS) offering like Amazon EC2. It’s one thing to say it can be done; it’s another thing to actually want to do it, as opposed to the easier alternatives. The market seems to bear this out – a recent Forrester study shows that Eclipse (that is, Java) developers prefer Amazon EC2 or Google App Engine, while Visual Studio (that is, .NET) developers prefer Windows Azure. Developers really don’t want to go through the contortions of packaging up their Java app plus the app server or servlet container, then configure and start it up as a special action under elevated privileges in an Azure worker role, just so that they can run Java EE, when they can easily install their application on a convenient Amazon EC2 image.

What users do want, it doesn’t do

Users will want to do things with Java on Azure, but not what the creators of the Azure Starter Kit for Java think they want to do. Rather than running a self-contained Java server in an Azure role (something they can more easily do elsewhere), they will want to integrate their Java with the .NET code more directly supported by Azure. For example, they may well have a Java library or application that they want to integrate with their .NET application. Depending on the Java side’s architecture, the Java might run in the same process as the .NET code, or it might run in its own process, or even a separate worker role. In any case, the Java side wouldn’t need to run in a full-fledged app server; it would simply expose an API that could be used by the .NET application.

A scenario like this is exactly the sort of thing that JNBridgePro supports. Java can be called from .NET code, and can run in the same process or in separate processes running on different machines. Up until now, those JNBridgePro deployments have been in on-premises desktop and server machines. In our upcoming JNBridgePro Cloud Edition, it will be just as straightforward to implement these interoperability scenarios in the cloud.

In summary, there’s a role for Java in the Azure cloud, but we think Microsoft is pushing the wrong scenarios. The Azure Starter Kit for Java is clever, but it (incompletely) solves a problem that cloud developers don’t have, while ignoring the real-world problems that cloud developers do have.

If you ask most people how software vendors can move into the cloud, they will say that the vendor should take their traditional products, put them in the cloud, and offer them as services. And that’s often fine. But what about software vendors like JNBridge who create components that other developers incorporate in their programs? In most cases, offering the component as a service doesn’t make sense.

The main challenge to running components like JNBridgePro in cloud-based programs has to do with prosaic but essential issues like licensing and billing. Windows Azure has absolutely no provision for third-party licensing (determining whether a user is entitled to use the product) and billing (charging for the use of the product). I would imagine that Microsoft feels that this should be the purview of some other third-party vendor, but I also imagine that potential vendors in this space are reluctant to invest in offerings until the demand materializes. It’s a chicken-and-egg problem. If Microsoft is serious about their software partners producing for Azure (and not just end-user customers creating custom applications), they will have to jump-start the market themselves, by offering their own billing mechanism. Since they are already billing Azure users, this shouldn’t be a stretch.

Unlike Microsoft, Amazon does have a licensing and billing service, called DevPay, that allows third-party developers running on Amazon’s EC2 (Elastic Compute Cloud) service to determine whether a user is authorized to run their products, and to charge for that use in a variety of ways. This service almost has it right, but it not quite there. It seems to be centered around Amazon’s S3 (Simple Storage Service), but will not run with their more modern EC2 images that are backed by EBS (Elastic Block Storage), which is the mechanism that most current EC2 users employ. In addition, the DevPay documents do not seem to have been updated in several years, and many questions on the DevPay support forum have gone unanswered, which leads to questions about Amazon’s commitment to this service.

Don’t worry, we’ve gotten around this problem, and it’s not preventing us from coming out with our cloud-based offering. But it surprises me that this new frontier of the cloud does not seem to have been designed to accommodate software vendors who want their products to work in the cloud. One would think that barriers to entry wouldn’t be there, and that the cloud providers would do all they could to encourage software vendors to help settle this new frontier, but they haven’t. I’m particularly surprised that Microsoft, which, in almost all other areas goes out of its way to cultivate a thriving partner ecosystem, has not done that with Azure, and doesn’t seem to have thought through the issues that would encourage such an ecosystem. And without that robust partner community, cloud adoption will be that much slower for everyone.

Version 2.1 of the JMS Adapter for BizTalk Server adds:

• Fault-tolerant connections for JMS Server shutdown scenarios. This feature provides the ability to configure specific behaviors for send and receive locations when the JMS server is explicitly brought down. Locations can be configured to either disable or periodically attempt to reconnect to the JMS server.
• Support for ISO 8859-15 encoding. Used almost exclusively in Europe, ISO 8895-15 is a single byte encoding that includes the Euro currency character.
• Ability to add a unique identifier to a receive location. This allows multiple receive locations to access the same JMS queue or topic providing a mechanism to support concurrent message consumption using JMS message selectors.
• New configuration documents for SonicMQ and GlassFish/OpenMQ.
• Improved logging and error reporting.

Version 2.1 of the JMS Adapter for .NET adds:

• Support for .NET 4.0.
• Support for version 2.0 of Microsoft’s WCF Line-of-Business adapter framework providing support for Visual Studio 2010.
• Support for Microsoft’s Azure AppFabric API, allowing .NET client endpoints running in the cloud to consume and produce JMS messages from JMS servers on the ground.
• Extended configuration and tuning documentation.

Both adapters are now:

• Built on top of JNBridgePro 5.1, which adds support for .NET Framework 4 and Visual Studio 2010.

Check out the press release, or download now.

JNBridgePro awarded in middleware, SOA and server-based tool market category

Boulder, Colorado, November 4, 2010

JNBridge, (www.jnbridge.com), the leading provider of interoperability tools that connect the Java and .NET Frameworks, today announced that JNBridgePro received a Readers Choice Merit Award in the Visual Studio Magazine (VSM) 18th Annual Readers Choice Awards. The 2010 winners are chosen by the readers of VSM and honor the best Visual Studio-related tools available in the market today. JNBridgePro was selected by readers for a Merit Award for adding significant value to the developer market in the Middleware, SOA and Server-based tools category.

“We rely on Visual Studio Magazine subscribers to drive our annual Readers Choice Awards, because they are among the most demanding and knowledgeable developers on the planet,” said Michael Desmond, editor-in-chief of Visual Studio Magazine. “Our readers live and die by their tools. So when a product earns recognition in our survey, it really means something. These tools have proven themselves out where it really counts—not in a reviewer’s lab, but in the field. I commend all the winners in this year’s VSM Readers Choice Awards.”

The Readers Choice Awards are based on the hard-won expertise and insight of VSM subscribers. Every year, the publication invites a select subset of readers to fill out survey ballots and identify the top products across specific tooling categories. The process ensures the awards reflect the opinion of VSM readers.

“We are honored to be recognized by those who know our products the best – developers – as there is no better confirmation that we are delivering upon our promise to provide useful tools that bridge Java and .NET and remove the complexities of cross-platform interoperability,” said Wayne Citrin, CTO of JNBridge. “It has been a rewarding experience to see the rapid adoption of JNBridgePro by enterprise developers who seek to connect Java and .NET Framework components and APIs together. We look forward to continuing to deliver solutions which meet developers’ needs.”

For more information on JNBridge and their interoperability product offering, please visit: (www.jnbridge.com).

About Visual Studio Magazine

1105 Redmond Media Group’s Visual Studio Magazine provides news, analysis and how-to, practical articles that teach enterprise developers how to create applications with Visual Studio better, faster and more easily. The award-winning editorial reaches the core of the Microsoft developer community–software architects, senior developers and development managers. The publication reaches 75,000 subscribers monthly. For more information, visit (VisualStudioMagazine.com).

About JNBridge

JNBridge connects Java and .NET Framework-based components and applications together with tools and adapters that are fast, simple to use and remove the complexities of cross-platform interoperability. JNBridge is a privately-held company based in Boulder, Colorado. Founded in 2001, JNBridge has over 400 unique customers in 40 countries that use JNBridge’s award-winning solutions in a wide variety of applications in financial services, insurance, media, manufacturing and other industries. Please visit www.jnbridge.com for more information.

Try it yourself: download a free trial or see how it works.

We’ve also posted the slides  on the Oracle OpenWorld and JavaOne On Demand site: http://openworld.vportal.net. You’ll need to log in and then visit http://openworld.vportal.net/?profile=23108&show=presentations.

The synopsis:

Cross-platform transactions between enterprise Java and .NET should be easy, right?  After all, both platforms have implemented the same specification.  How hard can it be? This session will attempt to answer that question by providing an in depth look at distributed transactions including implementations in enterprise Java and .NET.  Technologies that provide cross-platform transactions will be demoed providing a look at code from examples using  WS-AT/WS-Coor and direct bridging using a shared-memory JVM-to-CLR implementation. In closing, the session will discuss performance benchmarking, “gotchas�?, tips and tricks and the move towards eXtreme Transaction Processing and what that means for current Java EE and .NET based technologies.