Cloud Interoperability Demo

  • 852 views
Uploaded on

"Project Lightning" …

"Project Lightning"
Consume an Azure cloud service from Java

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
852
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. “Project Lightning” Demo
    Consume an Azure cloud service from Java
  • 2. 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.
  • 3. 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.
  • 4. Go to Azure-based website that hosts the JNBridgePro proxy generation tool
    Fill in the name of the project
  • 5. Browse for the FileSystemView DLL that contains the API we want, and upload it.
  • 6. Enter the names of the classes we want proxied. The tool will automatically proxy any additional classes that are needed.
  • 7. Name the proxy jar file. We’ll give it the same name as the project, “TestSeven”.
  • 8. Build the proxies
  • 9. The proxy generator’s output displays the generated proxies. The proxies will remain in the cloud until downloaded by the user.
  • 10. 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
  • 11. A different Web page for users to download previously-generated copies of the proxies
  • 12. The proxy distribution page allows you to choose which previously-generated proxy jar files to download.
  • 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.
  • 14. 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.
  • 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.
    We’ve also included the JNBridgePro Java-side classes, which simplifies deployment.
  • 16. 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
  • 17. 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.
  • 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.
    The cloud drive appears as virtual drive L:
  • 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:
    • Use an API designed only for the cloud in a desktop application.
    • 20. Use the API in a Java application, without a Java-based version of the cloud drive API.
    • 21. 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
  • 22. 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.
  • 23. 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
  • 24. Follow our progress
    www.jnbridge.com/cloud