Stories by: Rick Grehan

Linux is, among other things, a customizable operating system. Clever developers can craft a Linux whose kernel and packages are configured for a specific purpose, to serve as a sort of vertical-market operating system. The benefit to users is somewhat akin to walking into a hardware store. On the shelves are tools, each suited to a specific task. And it's particularly nice that all the tools are free.

Connecting your application into the Amazon Web Services (AWS) isn't complicated, particularly if you've done Web service programming on other projects.

Amazon's Web Services (AWS) are based on a simple concept: Amazon has built a globe-spanning hardware and software infrastructure that supports the company's Internet business, so why not modularize components of that infrastructure and rent them? It is akin to a large construction company in the business of building interstate highways hiring out its equipment and expertise for jobs such as putting in a side road, paving a supermarket parking lot, repairing a culvert, or just digging a backyard swimming pool.

In the beginning, Mainsoft released Visual MainWin for Java EE, which compiled .Net CIL (Common Intermediate Language) code into Java bytecode. As technically fascinating as that was, on its own it provided limited traction. Much of Microsoft's attractiveness to the enterprise goes beyond its .Net languages and runtime frameworks. It is Microsoft's enterprise applications such as SharePoint and SQL Server that -- for many enterprise programmers -- make the .Net environment worth using. A tool that simply moves .Net code into Java moves that code out of reach of Microsoft's enterprise applications.

If you believe the documentation, the white papers, and the news releases, iTKO's recently released LISA 4 is an SOA testing tool. That descriptor, however, is modesty riding on the back of the still trendy acronym "SOA" because LISA goes well beyond testing what are typically understood to be SOA components: Under one roof, it houses the abilities to test Web and Java applications, the ESB (enterprise service bus), JMS (Java Message Service) systems, EJBs, databases, combinations of the above, and -- oh yes -- Web services.

Android is Google's foray into the handheld OS realm. It follows a path trodden by -- among others -- Symbian's Quartz, the SavaJe operating system, and J2ME. In fact, one of Android's stated goals is to overcome some of J2ME's shortcomings. Whether or not Android succeeds, either at that specific goal, or in general, remains to be seen.

SOAP is the currency of the SOA marketplace -- for now, anyway. Though SOAP's significance may diminish as Web services evolve, its importance for the time being is unquestionable. Therefore, a substantial portion of the QA work by Web service providers and consumers must entail verifying the accurate exchange of SOAP messages. Not surprisingly, several SOAP-focused Web service testing tools have appeared.

Imagine if you will: you are the chief database administrator for a large corporation. Your organization's databases are on different continents, which has never been a problem. What is a problem is that those databases have been written by different divisions, using different database technologies: Oracle here, Sybase there, some Cobol down there, and so on.

Parasoft continues to send its Jtest Java testing suite out to hunt down bad Java code. And Jtest knows that the definition of bad Java code continues to expand: One bit of code might be bad because its developer didn't follow best practices for coding style, making it difficult for other programmers to understand and interface with it. Yet another bit might be bad because it is poorly factored and overly complex, or because it crashes when executed. A different bit of code might be bad because it was written with no consideration for security and could be easily compromised by a malicious hacker.

The basic goal of an SOA is to make resources available on a network in such a way that the resources are accessible by client applications without the applications having to resort to low-level (language- or platform-specific) APIs. The resources often have processing capabilities and are therefore referred to as services. In that sense, accessing a service looks a lot like making a very elaborate remote procedure call.

Open source application straddles virtualization-emulation line with aplomb.