Cloud Interoperability Demo

1,011 views

Published on

"Project Lightning"
Consume an Azure cloud service from Java

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,011
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cloud Interoperability Demo

  1. 1. “Project Lightning” Demo<br />Consume an Azure cloud service from Java<br />
  2. 2. Access an Azure cloud drive from a Java client<br />Microsoft’s Azure tools for Java do not support Azure Cloud Drives. <br />This demo does. <br />Azure<br />JavaClient<br />Cloud Drive Proxies<br />Cloud Drive<br />JNBridgePro<br />The cloud drive API is not part of the Windows Azure Tools for Java that Microsoft distributes. <br />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.<br />Our application will allow us to explore the contents of a normally opaque cloud drive.<br />
  3. 3. Step 1<br /> Azure<br />Java Proxies<br />.NETAssemblies<br />.NETAssemblies<br />On the ground<br />Upload assemblies and generate the proxies used to access the cloud drive API,<br />Or use cloud-resident assemblies/APIs.<br />
  4. 4. Go to Azure-based website that hosts the JNBridgePro proxy generation tool<br />Fill in the name of the project<br />
  5. 5. Browse for the FileSystemView DLL that contains the API we want, and upload it.<br />
  6. 6. Enter the names of the classes we want proxied. The tool will automatically proxy any additional classes that are needed. <br />
  7. 7. Name the proxy jar file. We’ll give it the same name as the project, “TestSeven”.<br />
  8. 8. Build the proxies<br />
  9. 9. The proxy generator’s output displays the generated proxies. The proxies will remain in the cloud until downloaded by the user.<br />
  10. 10. Step 2<br /> Azure<br />JNBridgePro<br />Cloud Drive APIs<br />Java Proxies<br />Java Proxies<br />Java Client<br />On the ground<br />Ensure the proxies are distributed to the clients that need them<br />Download the generated proxies<br />Note: proxies also contain pointers to cloud resources<br />
  11. 11. A different Web page for users to download previously-generated copies of the proxies<br />
  12. 12. The proxy distribution page allows you to choose which previously-generated proxy jar files to download.<br />
  13. 13. As we’re generating the cloud drive explorer, we’ll download the previously-generated proxy jar file generated as part of the FileSystemView project.<br />
  14. 14. Opening the jar file, we see it contains its own copy of the Java-side config file jnbcore_tcp.properties. <br />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.<br />
  15. 15. 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.<br />We’ve also included the JNBridgePro Java-side classes, which simplifies deployment.<br />
  16. 16. Step 3<br /> Azure<br />Cloud Drive<br />JNBridgePro<br />Cloud Drive APIs<br />Cloud Drive API Proxies<br />Java Client<br />On the ground<br />Integrate the proxies with our Java project<br />Use the proxies to access the Windows Azure cloud drive<br />
  17. 17. In Eclipse, we reference the generated proxy jar file.<br />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.<br />
  18. 18. 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.<br />The cloud drive appears as virtual drive L:<br />
  19. 19. 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:<br /><ul><li> Use an API designed only for the cloud in a desktop application.
  20. 20. Use the API in a Java application, without a Java-based version of the cloud drive API.
  21. 21. Know the contents of our cloud drive, and modify them.</li></li></ul><li>Why is this useful?<br />Azure<br />JavaClient<br />Java Proxies<br />.NET Library<br />JNBridgePro<br />.NETClient<br />.NETProxies<br />Access Windows Azure APIs from Java-based applications<br />Access Windows Azure APIs from desktop applications<br />Make .NET-based services, APIs, and components accessible to all, including:<br />Components that are not Web-service enabled<br />Users running Java or .NET clients<br />
  22. 22. Why is this useful?<br />Azure<br />Java Proxies<br />JavaClient<br />Java Proxy<br />.NET Library<br />JNBridgePro<br />Distribute and deploy APIs, even where WSDL doesn’t work<br />Simple, easy, and transparent distribution. <br />
  23. 23. Why is this useful:<br />JavaClient<br />.NETApp<br />Hardware Abstraction Layer<br />“Registry”<br />“File System”<br />Page Blob<br />Cloud Drive<br />Azure<br />A possible first step towards devising a “hardware abstraction layer” <br />Legacy applications can run in the cloud by “thinking” they have access to non-existent legacy facilities like the registry and file system<br />Enables migration to the cloud without completely rewriting the app<br />
  24. 24. Follow our progress<br />www.jnbridge.com/cloud<br />

×