“Project Lightning” Demo Consume an Azure cloud service from Java
Access an Azure cloud drive from a Java client Microsoft’s Azure tools for Java do not support Azure Cloud Drives. This demo does. Azure JavaClient Cloud Drive Proxies Cloud Drive JNBridgePro The cloud drive API is not part of the Windows Azure Tools for Java that Microsoft distributes. The cloud drive API is only designed to work when called form a cloud-based application. We will get it to work from a desktop application. Our application will allow us to explore the contents of a normally opaque cloud drive.
Step 1 Azure Java Proxies .NETAssemblies .NETAssemblies On the ground Upload assemblies and generate the proxies used to access the cloud drive API, Or use cloud-resident assemblies/APIs.
Go to Azure-based website that hosts the JNBridgePro proxy generation tool Fill in the name of the project
Browse for the FileSystemView DLL that contains the API we want, and upload it.
Enter the names of the classes we want proxied. The tool will automatically proxy any additional classes that are needed.
Name the proxy jar file. We’ll give it the same name as the project, “TestSeven”.
The proxy generator’s output displays the generated proxies. The proxies will remain in the cloud until downloaded by the user.
Step 2 Azure JNBridgePro Cloud Drive APIs Java Proxies Java Proxies Java Client On the ground Ensure the proxies are distributed to the clients that need them Download the generated proxies Note: proxies also contain pointers to cloud resources
A different Web page for users to download previously-generated copies of the proxies
The proxy distribution page allows you to choose which previously-generated proxy jar files to download.
As we’re generating the cloud drive explorer, we’ll download the previously-generated proxy jar file generated as part of the FileSystemView project.
Opening the jar file, we see it contains its own copy of the Java-side config file jnbcore_tcp.properties. We supply it as part of the proxy jar file because we already know where in the cloud the Java side will be, and the user doesn’t have to.
Opening the property file, we see that the proxy generator has supplied a host address in the Azure cloud. This address can be used without modification. We’ve also included the JNBridgePro Java-side classes, which simplifies deployment.
Step 3 Azure Cloud Drive JNBridgePro Cloud Drive APIs Cloud Drive API Proxies Java Client On the ground Integrate the proxies with our Java project Use the proxies to access the Windows Azure cloud drive
In Eclipse, we reference the generated proxy jar file. This special cloud-enabled jar file contains the Java-side configuration and the JNBridgePro Java-side runtime components, so no additional Java-side components need be included.
We’ve modified the open-source project Java File Manager (JFM). Ordinarily used to explore on-disk file systems, it now uses the Azure cloud drive API associated with FileSystemView.jar, and shows the content of the cloud drive. The cloud drive appears as virtual drive L:
Now we can drill down into the folders in the cloud drive, and manipulate the files as if they were on a local drive. This capability enables us to:
Use an API designed only for the cloud in a desktop application.
Use the API in a Java application, without a Java-based version of the cloud drive API.
Know the contents of our cloud drive, and modify them.
Why is this useful? Azure JavaClient Java Proxies .NET Library JNBridgePro .NETClient .NETProxies Access Windows Azure APIs from Java-based applications Access Windows Azure APIs from desktop applications Make .NET-based services, APIs, and components accessible to all, including: Components that are not Web-service enabled Users running Java or .NET clients
Why is this useful? Azure Java Proxies JavaClient Java Proxy .NET Library JNBridgePro Distribute and deploy APIs, even where WSDL doesn’t work Simple, easy, and transparent distribution.
Why is this useful: JavaClient .NETApp Hardware Abstraction Layer “Registry” “File System” Page Blob Cloud Drive Azure A possible first step towards devising a “hardware abstraction layer” Legacy applications can run in the cloud by “thinking” they have access to non-existent legacy facilities like the registry and file system Enables migration to the cloud without completely rewriting the app