Mitch Pronschinske 
Trying to Catch "Project Lighting" in a Bottle
Email
The Cloud Zone is presented by DZone and Microsoft. Let our tutorials, design patterns, and news guide you through the maze of constantly increasing cloud solutions. Microsoft has a host of tools to let you deploy Node.js, PHP, and Java apps on their Windows Azure platform.
At JavaOne this week, Wayne Citrin, the CTO of JNBridge, tried to gauge developer interest in a solution that would bring significant .NET/Java interoperability into the cloud. The project is currently called "Project Lighting" and it builds on JNBridge's existing expertise in Java and .NET systems interoperability.
“We believe that what is typically discussed under the rubric of cloud interoperability is so insufficient it will destroy the promise of the cloud,” said Citrin. “JNBridge’s position is that ‘Cloud Interoperability’ must encompass full Cloud-to-Cloud access, where any cloud service can access any other cloud’s service, full Cloud-to-Ground access, where any cloud service can be consumed from any client or on-premise platform, and full interoperability within a cloud service. In order for this to work, developers need the ability to write cloud services using any platform, easily, simply and quickly, and regardless of the cloud vendor. Our vision of cloud interoperability is any object, on any platform, in any language, anywhere, and at any time.”
Currently, much of the focus is on API interoperability in the cloud, which consists of multiple APIs targeting each platform. This is easy for new developers of cloud services to pick up, but it doesn't help with the migration of applications to the cloud and it doesn't make it any easier to consume cloud services.
Legacy apps are another problem. Any legacy application that tries to access a file system or registry (which clouds don't have) will not run on the cloud. This is why Java applications, for example, are very narrowly constrained in Microsoft's Azure cloud. Service consumption is also not interoperable between platforms - Java clients can't be pointed at Azure/WCF services and WCF clients can't be pointed at Java-based services. .NET clients won't consume Azure WSDL either.
How JNBridge Would Bring Java/.NET Interop to the Cloud
At JavaOne, JNBridge presented several demos and one of them showed how Java-based clients could access .NET-based services in the cloud. Here were some main points:
Access a .NET library in the cloud from a Java client.
Make .NET-based services/APIs accessible to all comers, even .NET clients.
Distribute/deploy APIs where WSDL doesn't work.
Devise a hardware abstraction layer so that legacy apps think they have access to certain facilities such as the registry and file system in the cloud.
And here are the 3 steps from the demo:
Read more about JNBridge's thoughts on cloud interoperability and why it must succeed in order for the cloud to survive.
“We believe that what is typically discussed under the rubric of cloud interoperability is so insufficient it will destroy the promise of the cloud,” said Citrin. “JNBridge’s position is that ‘Cloud Interoperability’ must encompass full Cloud-to-Cloud access, where any cloud service can access any other cloud’s service, full Cloud-to-Ground access, where any cloud service can be consumed from any client or on-premise platform, and full interoperability within a cloud service. In order for this to work, developers need the ability to write cloud services using any platform, easily, simply and quickly, and regardless of the cloud vendor. Our vision of cloud interoperability is any object, on any platform, in any language, anywhere, and at any time.”
Currently, much of the focus is on API interoperability in the cloud, which consists of multiple APIs targeting each platform. This is easy for new developers of cloud services to pick up, but it doesn't help with the migration of applications to the cloud and it doesn't make it any easier to consume cloud services.
Legacy apps are another problem. Any legacy application that tries to access a file system or registry (which clouds don't have) will not run on the cloud. This is why Java applications, for example, are very narrowly constrained in Microsoft's Azure cloud. Service consumption is also not interoperable between platforms - Java clients can't be pointed at Azure/WCF services and WCF clients can't be pointed at Java-based services. .NET clients won't consume Azure WSDL either.
How JNBridge Would Bring Java/.NET Interop to the Cloud
At JavaOne, JNBridge presented several demos and one of them showed how Java-based clients could access .NET-based services in the cloud. Here were some main points:
Access a .NET library in the cloud from a Java client.
Make .NET-based services/APIs accessible to all comers, even .NET clients.
Distribute/deploy APIs where WSDL doesn't work.
Devise a hardware abstraction layer so that legacy apps think they have access to certain facilities such as the registry and file system in the cloud.
And here are the 3 steps from the demo:
Read more about JNBridge's thoughts on cloud interoperability and why it must succeed in order for the cloud to survive.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Whether it's IaaS or PaaS, there are many options and features for developers to consider when deploying applications to cloud environments. Cloud Zone is your trusted guide through the jungle of diverse cloud solutions. Get clear cut information on solutions like Windows Azure, open and flexible cloud platform to develop, deploy and manage applications on Microsoft's datacenters. You can see how well your apps run on Azure with their free 3 month trial.
