What is Google App Engine?

What is Google App Engine? Here is a good description from their website:

Google App Engine makes it easy to build an application that runs reliably, even under heavy load and with large amounts of data. The environment includes the following features:

• dynamic web serving, with full support for common web technologies
• persistent storage with queries, sorting and transactions
• automatic scaling and load balancing
• APIs for authenticating users and sending email using Google Accounts
• a fully featured local development environment that simulates Google App Engine on your computer

I love it that Google eats their own dog food. These guys didn't invent a new "product" or come up with something to sell to the masses; they're using the same things that they built their company on! They have enough faith in their internal infrastructure that they're using it to allow us (the masses) to use these great products to build some really neat applications. Google is using the following components for their framework: Python application servers (more languages forthcoming), BigTable (Google's home grown database), and GFS (Google File System) data store services

As pointed out by TechCrunch here, this appears to be in response to Amazon's suite of web application enabling services: S3 (storage), EC2 (virtual servers), and SimpleDB (database). The difference is that Google is offering the whole stack instead of more loosely coupled services. Some SOA junkies would argue that this is not what they want, but I would beg to differ. First, it's Google doing what Google does well: offer everything seamlessly so that a developer can easily get one SDK, use one API, and one common environment to get an application written and deployed quickly. Basically, my money is on Google.

Now, if I were only one of the first 10,000 who got in on the Beta! Here's hoping to a quick run through the wait list! I'll probably download the SDK to play with anyway; I really want to see how Google's Query Language (GQL) stacks up against my favorite: SQL.

Programming for multi-core performance - in Java?

Performance is a huge concern when writing any Java code, especially since many still do not realize the benefits of coding to a hotspot vm and believe Java to be a "slower" language than something like C/C++. As someone with a hardware background, I frequently hear that faster computers are the answer. To an extent, they are correct. To this end, processor architects have been putting more processing power in our beloved machines by adding nifty new technology like hyper-threading, cores, and increasing the on-die caches in recent years. All this is great; however, we can tap this power to a greater extent if we software guys have ways to program closer to this type of hardware.

Back in college, we had a homework assignment to finish adding the hardware in a CPU necessary for the jump assembly command. We did our diagrams and loaded it all into our CAD tool. After we had the full layout of the processor in memory (first time of course!) we had to do some testing. So, we used VERILOG for the first time, and doing so was quite an experience. We were rudely introduced to a programming style that was purely parallel; we were basically coding electrical impulses through tiny wires. In any case, it is a very different feel than doing your standard sequential programming (Java/C/C++/C#)and it is more than a little difficult to get accustomed to. The first few times we tried it we encountered many race-through issues and problems making sure all the code paths lined up. It was quite a learning experience indeed.

For the past few years, there have been many discussions on how to best program threads for this environment in the C/C++ languages. Intel has many good documents on the OpenMP API (here's a good one), along with some interesting comparisons (and arguments) to using PThreads as well. However, what about us Java guys, and could there be a better way than straight-up thread programming?

As I said before, parallel programming is interesting, but it's extremely difficult to master. In addition, we must take into account scalability - programming for 2 cores may be different than programming for 100 cores (thinking ahead, of course). Is it unreasonable for us to find a way to abstract the threading and split up work when the JIT compiling takes place? I hope not, because doing so would be really nifty, especially since the Jedi Thread Masters among us are few and far between.

Enter JSR-166 and JSR-166y fork/join framework! According to Doug Lea, the framework is "a style of parallel programming in which problems are solved by (recursively) splitting them into subtasks that are solved in parallel, waiting for them to complete, and then composing results." Here is his pseudo code to demonstrate:

Result solve(Problem problem) {
if (problem is small)
    directly solve problem
else {
    split problem into independent parts
    fork new subtasks to solve each part
    join all subtasks
    compose result from subresults
}
}

I think this is a really big step in the right direction for Java, but is not quite the holy grail of multi-thread abstraction for the masses. I'm still researching this framework, but at first glance, the framework appears to allow the application to be coded such that depending on the size of the task/algorithm, one can easily fork/spawn a separate subtask that is computed in parallel (waiting for them all to complete of course), then joining them back together. This has enormous potential in my opinion!

I'm going to continue my research and will post my thoughts here. In the meantime, take a look at Doug Lea's paper, "A Java Fork/Join Framework" as well as some of the existing JSR-166 collections in Java SE 6: Deque, BlockingDeque, NavigableSet,NavigableMap, ConcurrentNavigableMap, ArrayDeque, LinkedBlockingDeque, ConcurrentSkipListSet,ConcurrentSkipListMap, TreeMap.

Resources:

A Java Fork/Join Framework by Doug Lea

Concurrency Interest Site

JSR-166 Site

New NASA Website - nasascience.nasa.gov/ !

Ok, I know this is a data access blog, but I'm a geek. A real big uber geek and I love outer space. Therefore I was really excited to come across NASA's new website today! Here's the link:

http://nasascience.nasa.gov/

Some of my favorite things to look at are pictures from space. So, it's the weekend and I'll share the NASA multimedia image gallery site as well:

http://www.nasa.gov/multimedia/imagegallery/

These make great backgrounds and really mark you as a space cadet! Images of all the planets, black holes, everything looks great. I'm nearly done now, here is the link to the hubble site:

http://hubblesite.org/

Next time more on data access, I promise.

JDBC 4.1 BoF at JavaOne 2008!

Just a quick note to say that the JDBC Expert Group (of which I'm unashamedly a part) will be having a Birds of a Feather session on Tuesday night at this year's JavaOne conference! Please drop by and let us know if you have any input on what we're considering and working on for the upcoming JDBC 4.1 features list! Below is the description of the BoF:

This BOF session brings together members of the JDBC Expert Group and other people interested in finding out more about the features being targeted for the JDBC 4.1 specification and its progress to date to discuss priorities and directions for work within the context of the JSR.

The JDBC 4.1 technology is being targeted for the Java Platform, Standard Edition 7 (Java SE 7 Platform).

I don't want to spoil anything for Lance, but we've got some really nice things to add to the spec for the next version to make JDBC Data Access better than ever.

Secure Mashups with SMash

I was doing some investigation into web service security, and ran across another nifty IBM tool: SMash. Smash (meaning secure mashups) is basically a technology designed to solve security problems when writing a mashup (a.k.a. situational application). These applications generally consume data/information from several different web services, and you need to ensure that there are measures in place to secure the data that they give to their calling applications.

Security is a concern by IT departments as mashups are typically written by non-IT staff and there is potential for leaked security. So, IBM wrote (and donated) SMash so that you can now authenticate your AJAX Web Services (Smash is javascript, so it's AJAX only at the moment). This is nifty as it appears as though you can secure your mashups by making sure that they can only access certain services you approve, or you can do other certificate based authentication.

The only issue I see with this is that it's non-standard. If the future is in services, seems like we should strive to come together and come up with a standards based way to do web service security (would WS-Security fit here?).

Well, since this is only javascript, I'm back to my research. For now, if you're interested in SMash, try out the code here (part of OpenAjax) or read more in this whitepaper from IBM.