Mashed Articles

Ubuntu uses nautilus as the default file manager. You can effectively use nautilus to increase your productivity. Here I am telling about a useful hack for power users for opening folders in terminal . See the screen shot below
It allows user to open a selected folder in a terminal window by right clicking on the folder.
For installing “open in terminal” feature you need to install package “nautilus-open-terminal” .
open a terminal

$sudo apt-get install nautilus-open-terminal

or you can use synaptic package manager.

After installing the package you have to logout and login back , Now you can right click on a folder you will get “open in Terminal option.

“Loosely coupled” is a heavily used term in SOA land. To me, loosely coupling means the use of a standardized contract/interface (aka canonical message format) and preferably also synchronous messaging such as JMS.

Found an interesting presentation that describes the “facets” of loosely coupling. And it compares the different types of web services with relation to “decoupling”.

JMS or Java Message Service is the basis and standard API for asynchronous, reliable messaging.

After 10 years, a new (2nd) edition of the book “Java Message Service” was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.

Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.

Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),

Messaging solutions are still the core backbone for many ESB’s and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.

SOAP is the HTML for machine-to-machine communication.

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 Entrprise 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, HTTP header use_intranet=true is set.
• 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.