Fiber optic sabotage

At the start of Javaposse podcast #244, Dick et al explain how they got digitally disconnected from the outside world... Saboteurs digged 2 holes and cut a crucial fiber cable at 2 different locations. Hacking with a shovel!

Anyway, this is a new type of cyber attack, or is it warfare? Fiber optic cables are usually deployed as rings. So if the cable gets cut at one point, the other part of the ring still works fine and can handle all the traffic. But if you cut it at 2 points, end of story. Not only the Internet connections were down for 50.000+ people, but cell phones were dead as well.

Connecting back from the Azure cloud

Invoking services within the Intranet was in the design of Azure from the start. The .Net Services Bus of Azure allows local services to be called from the cloud.

A connection is setup from within the corporate firewall to the Azure servers in the cloud. This bidirectional connection is used to invoke services on the Intranet. The Services Bus is much more advanced than the Secure Data Connector from Google.

Azure is not limited to .Net, there are also Ruby and Java SDK for .Net Services available! To learn a bit, I downloaded and installed the Java chat sample. Encountered the error "The subscription cannot be created" during my first experiments. But waiting a while resolved the issue: probably the service didn't unregister correctly during my first runs and the service bus needs to detect that the service was no longer present.

In the Chat example, client and service are running in the same application (multi-threaded). No need to deploy the service implementation in an application server. Also nice to see how the JAX-WS API is leveraged to create the service.

Connecting from Azure to Amazon (or the other way around) should be trivial. But integrating Azure with AppEngine (or Force.com) is a different story. Both cloud have there own version and solution for integration and interoperability. A ESB hosted in the cloud or behind the corporate firewall will bring that interoprability.

Connecting back from the Google cloud

Big news this week, the rumor finally became true: Google App Engine supports Java, next to Python. So Google AppEngine is now a big Servlet Engine in the cloud.

Along with the Java on Google App Engine announcement, I noticed another component: the Secure Data Connector. This SDC allows applications running in the Google cloud to inter operate with Intranet applications. Through the Secure Data Connector, Intranet applications can be accessed.

Scenario:

• The Secure Data Connector is installed on a Linux server within the Enterprise.
• An administrator configures the SDC to access certain resources within the Intranet.
• The SDC is started and runs continuously as a background process.
• The SDC connects to Google (https://apps-secure-data-connector.google.com) on port 443 (HTTPS). The connection is made from the enterprise to Google, so no need to configure the firewall at Enterprise side to allow inbound connections (from Google into the Enterprise).
  
• The SDC authenticates itself using username and password.
• Once the SSL connection is established, the connection remains open.
• An application running in the Google cloud (AppEninge, Google Spreadsheet, ...) needs to access data from the Intranet or send data to the Intranet.
  
• In AppEngine, this is done using the URLFetchService. To specify that an Intranet resource should be accessed, add the HTTP header use_intranet=true in the request.
  
• From the Google AppEngine, a call is made to the SDC deployed in the Enterprise. Remember, TCP connections are bidirectional!
• The SDC verifies if the access the local resources, e.g. using the local DNS from within the Enterprise.
• The SDC accesses the local resource or web service and returns the data back to the applicaton running in te Google cloud. The size of request and response messages is limited to 1 MB.
  

The access to protected data within the enterprise is somewhat of a challenge. The only mechanism the SDC can provide credentials to Intranet application/service/resource is OpenSocial and OAuth signatures. And

One of the evolutions that I envision is that ESB's or B2B services will embed the SDC logic as an adapter. The ESB is able to transform the requests coming from Google into other protocols or formats and add the necessary credentials.

Some more thoughts and remarks I made while going through the Secure Data Connector docs:

• How is the configuration file of the SDC protected? In particular the username and password contained therein.
  
• Support is limited to Linux. What prevents this open source code to be ported to other platforms?
• How about load balancing or failover?
• How about interoperability between clouds: anyone already tried to deploy the SDC on EC2?
• Where is the SOAP support? How to invoke SOAP web services using the URLFetchService?
  
• How about identity services and mapping the identity of a Google user to an internal Enterprise user account?
• The SDC is not comparable to the .Net Services Bus of Windows Azure.
• Can the SDC access the Internet through a proxy?
• To deploy the Secure Data Connector in a large enterprise, you might have a hard time convincing the security department.

Talking with Talis - great podcast

Another podcast that I can strongly recommend: Talking with Talis. Interviews with some very knowledgeable people and good sound quality. Lately, the focus was on Cloud Computing: Appistry, RightScale, the Eucalyptys project, HP, SalesForce and Force.com, Windows Azure, ...