TSSJS2010: JVM Languages for mission-critical applications

The slides for this presentation can be found here

JSR-223: Scripting & what it means to you.

You want to use scripting languages to implement code faster through continous prototyping.

Scripting is built right into Java 6.   Spring has limited support, though.  But it is available on Mule ESB, ServiceMix, and other Spring containers.

Take a look at the javax.script package

Reasons for Scripting

  • Prototyping
  • Better tools for problem domain

Jawk – Processing a lot of text
Jython – System Management tools
XSLT – XML Manipulation

If the only reason you’re using scripting language is for dynamic code deployment, though, you should instead look at OSGi.

There’s also a tool called JRebel that’s worth taking a look at.

The Java Language is Awesome as long as you don’t break its abstractions!

Mule is great for pulling services together across multiple protocols.

TSSJS2010: The Cloud Computing Continuum

Bob McWhirter by far gave the best keynote session I’ve seen yet.   His delivery is humorous, he’s got great stage presence, and the slides were very creative.  Furthermore, he was best able to give me an understanding on what the hell the cloud is anyway.

The cloud is the next logical step in application delivery.

First, we jammed some servers in some closets.
Then we did some colo.
After that, we leased some managed servers.

With the cloud, we lease what appears to be servers.

The Cloud Computing Stack

Software as a Service (SaaS) – Abstracts software
Platform as a Service (PaaS) – Abstracts Services
Infrastructure as a Service (IaaS) – Abstracts Hardware

Tenets of the Cloud

  1. Illusion of Infinite Resources
  2. On Demand Acquisition and Provisioning
  3. Someone Else’s Responsibility

Virtualization makes it affordable to make mistakes.  Repeatedly.

The network isn’t all that slow, compared to spinning disks.

Messaging (REST-MQ)
Scheduling
Security & Identity (OASIS)
Computation (Query and otherwise)
Transaction (REST-TX)
BPM
Telephony

It’s a stack of services, instead of a stack of software.

More info at http://cloudpress.org

TSSJS2010: GWT fu: Going Places with Google Web Toolkit

This session provides an introduction to the GWT for designing web clients.

With GWT 2.0, the Hosted mode browser plugin allows you to run in the various browser directly.

It’s probably due to limitations from my hangover, but apparently we’re running Javascript on the client but it looks like we’re writing Java.  Is GWT somehow converting my Java into Javascript?  I think that Geary alluded to that fact, but I’m not quite sure.  The code for ClickHandler certainly looks like Java though.   As a matter of fact, I later got confirmation that this is indeed the case.   With GWT, you write Java and GWT takes care of generating the Javascript!  So sweet!!

Hosted mode browser plugin – running in the various browsers directly
Code splitting is a useful pattern to use.  Because GWT applications are downloaded to the client as Javascript, they can get pretty big pretty fast.  Code splitting lets you split out your code and lazy download as needed.

Layout panels provide an easy way to create layouts without too much fuss a la Swing.

Client bundles lets you pull down a bundle of resources in one http request

WebAppCreator application is used to generate the web application:

webAppCreator com.clarity.SimpleApp

GWT now creates a bunch of stuff for us.

ant hosted

Import project into Eclipse.   Nice to know it integrates seamlessly with Eclipse, by the way.  😉

All GWT Applications are modules.  From the code, it looks like the server implements a Remote interface.   Also it would seem that GWT allows you to plug into Hibernate.  It isn’t just a Web framework, then?

Event Handlers

Event Handlers are very similar to Swing/AWT/SWT listeners.   They’re typically implemented in anonymous inner classes.

Swing came with adapter classes for event handling with no-ops.   GWT first came out with the same paradigm.   Not all GWT widgets are notified about all events.   You can sync events on a widget to be notified of events you typically wouldn’t receive.

History

GWT has a history mechanism as well.  It’s apparently very slick and it handles something of a state, but I’m not quite understaning why it’s so slick.   Then again, I was at the Blackjack table until 2:30 AM drinking free Gin and Tonics, so my mental capacity is somewhat muted.

Go, Speed Tracer, Go!

Speed Tracer monitors any web application and gives all kinds of data as to how many requests are being made, how long it takes, etc.  In short, it’s a GWT supplied performance analysis app and it’s good to use to improve the performance of your web app.

Code Splitting

Code Splitting is achieved by surrounding the code you don’t need right away inside a GWT.runAsync() block.   That allows for lazy-loading of code that’s not needed right away.

Best Practices

  • Use History from outset
  • Design for UIBinder from the outset
  • Consider MVP and on event bus
  • Use Speed Tracer and code splitting for performance

GWT, in many respects, is like Swing.  It allows you to build your web page GUI using a very Swing-like API.  No Javascript, No Ajax.  Just pure 100% Java goodness!

TSSJS2010: Mission Critical Enterprise/Cloud Application Case Study

Not a good start.   The speaker, Eugene Ciurana, is nowhere to be found.   Apparently he’s on his way.  Hopefully his mission critical apps are more responsive than he is.  😉   He finally arrives out of breath as he was apparently working out at the gym.   After he catches his breath, we begin.

The presentation is about how to design, implement and roll-out cloud/enterprise hybrid applications.   There are a lot of different cloud architectures:  PaaS, SaaS, and IaaS (infrastructure as a service).   Technologies include: ESB, clods, mini-clouds, Java, App Engine, Chef!/Puppet, etc.    Cloud technologies lower your cost:

* Which applications are best suited for cloud deployment?
* Identify the advantages of PaaS or SaaS resources?
* What are the caveats of cross-platform and cross-language integration?
* High-performance alternatives to XML serialization for data exchange?  (i.e., JSON)

What is the Cloud Anyway?
* Platform as a Service (Amazon, Google, Rackspace, etc.)
* Software as a Service (Salesforce.com, Amazon)
* Infrastructure as a Service (IBM, HP)
* Pure-infrastructure (Data centers)

Cloud Services Features
* Quick deployment of prepackaged components
* Uses commodity, virtualized hardware and network resources
* “Pay as you consume”
* Horizontal scalability is achieved by adding or removing resources as needed
* May host full applications or only services
* They could replace the data centre
* Basic administration moves to the application owner
* For the bean counters… it’s an operational expense!
* Assuming sensible SLAs, the ROI is better than for co-located or company-owned data centres (but won’t achieve 4 9s)

Uptime != Availability.   Many factors affect availability: network, storage, process

Hybrid Cloud Architecture

* Many mission-critical systems will live behind the corporate firewall
* The cloud is used for high-load applications and services
* The cloud applications work independentlyof the data center applications, and vice-versa.

Case Study: Video game company with  hybrid cloud application

Objectives
* Stable architecture
* Low cost
* Build scalability whenever possible
* Optimal data transfer rate for all properties

Initially, there were some 8 machines that were running everything: QA, PROD, debugging, etc.   The performance was atrocious!

Phase 1: Scalability

* Introduces a CDN for asset delivery (media, images)
– Amazon S3 for asset delivery
– Reduces load on company servers and bandwidth costs
* Introduces database replication for production environments
* Establishes a continuous integration environment
– Improved build/release process
* Fail-over with traditional database replication techniques

Phase 2: Cloud Deployment
* Web applications move to a uniform technology (.Net)
* The database and stored procedures normalized and optimized
* Applications use common resources via Mule ESB and services
– No more direct calls from apps to database
– Business logic is implemented as stateless POJOs
* Software stacks was best of breed
* Web and other RPC services must coexist
– Different partners use different protocols
* Bandwidth can be expen$ive!
* Data exchange protocols
– clients: custom, XML, JSON
– images: HTTPD, S3
– Cloud-to-HQ: custom, XML/SOAP, protocol buffers
– HQ data center: XML/SOAP, protocol buffers
* Replication strategy: data centre
– The cloud isn’t trustworthy yet
* Deployment involves using an Amazon Machine Image (AMI)
* AMIs need a post-configuration step in a load-balanced environment
* Elastic Load Balancer and Elastic IP limitations

And so it ends.   This session clearly pitched to C-levels (in particular CIOs.)  There was very little meat and substance for Java geeks to get their hands on.   It’s a shame.   Clearly Eugene has a lot of knowledge, but this was just way too high in the clouds (pun intended)

TSSJS2010: Cloud Computing with Scala & GridGain

I’m here at the beautiful Caesar’s Palace waiting to hear more about Scala.   James Gosling’s keynote speech this morning was a bit of a letdown.   I was hoping to hear a visionary speech from the father of Java, perhaps not with Obama’s oratory skills, but nevertheless captivating.   What I got instead was a 60 minute informercial on Sun’s current product offerings.   Yes, Java EE 6 and GlassFish 3.0 are totally slick, and I do like the concept of using annotations for event handling.   That said, I was hoping he would talk more about the future of Java, especially with all the Oracle merger and everything.   Anyway, no-go.   So now I’m here waiting to hear what the hell is Scala and how I can use it.   From what I’ve read, they’re using it at Twitter, so it’s gotta be somewhat scalable, right?  😉

The presentation is broken down with 20% talking and 80% live coding.   Nikita Ivanov, the presenter, has a very good stage presence and I enjoy his direct approach.

We start with the talking part by defining a few terms for us neophytes (including myself!)  What is Grid/Cloud Computing?   A Grid is defined as two or more computers working in parallel.   Grid Computing is comprised of Computer Grids + Data Grids.    The Cloud, meanwhile, is comprised of Data Center Virtualization.  Clouds are the new way to deploy and run grid applications.

Why Grid/Cloud Computing?

It solves problems often unsolvable otherwise.   Google has ~1,000,000 nodes in its grid.   Put another way, it’s about money.   Amazon says that 100 ms latency cost 1% of sales.  Google says that 500 ms latency drops traffic 20%.   In the financial sector, one millisecond costs $4M in currency markets.

GridGain at a Glance

The project was started in 2005 as Java-based Cloud Development Platform:
* Compute Grid (aka, MapReduce)
* Data Grid (aka. Distributed Cache)
* Auto-scaling on the cloud

Scala at a Glance

* Started in 2004 by Matin Odersky at EPFL  (author of ‘javac’ and Java Generics)
* Scala is Post-Functional Language (combines functional and OO approach)
* Fully inter-compatible with Java (runs on JVM, Call Java and called from Java methods)
* Statically typed (Unique and powerful type inference)

Apparently, there’s more use of Scala in Europe than there is here in the US.   A large national French bank already has a dozen Scala projects rolling out.   In the audience here today, only one hand was raised when asked who was using Scala today?

Why Scala?
* Performance largely equal to Java
* Statically typed
* Inter-compatible with Java
* Scalable language

Scalar – Scala-based cloud computing DSL + GridGain 3.0
* Uses Scala
– Functional-impertive
– Runs on JVM
– Reuses 100% Java libraries
* Running on top of GridGain 3.0 runtime

DSL – Domain Specific Language
* Provide simple cloud computing model
* Draws on functional features of Scala
* Dramatically simplifies cloud computing applications

The demo is to build a Scala grid application in 10 minutes!

import org.gridgain.grid.gridify.Gridify
import org.gridgain.grid.GridFactory

object ScalaDemo {
    def main args: Array string {
        GridFactory start

        try {
            say "hello Scala Las Vegas"
        }
        finally
            GridFactory stop true
        }
    }

    @Gridify
    def say msg: String   { println msg }
}

This code automatically deployed the object to the Grid and executed it on one of the nodes!   That’s mindblowing and so cool!   Clearly there’s tons of complexity behind the scenes.   The class definition must be serialized, the grid must be located, some scheduler must identify the node on which the object is to run.   I’m totally blown away by how painless it is to deploy on a grid!

Ivanov proceeded to write a task in about 10 lines of code that split the string into words and dispatched the job of printing those words onto the various nodes.

The same demo was then given using Scalars, which is a GridGain construct.    That got a little more cryptic, in my humble opinion.   Still, it did require less lines of codes to get the job done.   The tradeoff, though, seems to be readability.  You’re slowly creeping into the world of Python, which I’ve never enjoyed because only the original developer can ever make bug fixes.

Still, Scala clearly is pretty slick and it looks like the integration with GridGain in order to parallelize tasks is very easy.   I’ll definitely need to investigate how I can leverage this for risk analysis.