SlideShare slides on Web App Scalability

These look very interesting, enjoy: Web App Scalability Slides.


MySQL, Digg, Twitter, Vox, LiveJournal, ...

Integration Forethought over Afterthought?

DevHawk linked to a post by John Evdemon announcing an e-book from Microsoft on SOA.

From the SOA in the Real World book page:

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought.This book introduces a set of architectural capabilities, and explores them in subsequent chapters.

Now, I haven't read the book, so take this with appropriate disclaimers of ignorance.

I, for one, would rather build on an architecture that promotes integration as an afterthought, so I don't have to think about it before hand!!!

This post to rest-discuss by Nick Gall quotes some important thinkers. Here is the relevant section:

• Unexpected reuse is the value of the web
• Tim Berners-Lee
• Two of the goals of REST: independent evolvability and design-for-serendipity
• Roy T. Fielding
• Engineer for serendipity
• Roy T. Fielding

Writings on Scalability Topics

I suggest reading these blogs.

Jeff Darcy (Canned Platypus) has an great blog, and also this article on High Performance Server Architecture. The article talks about the performance and scalability implications of

1. Data copies
2. Context switches
3. Memory allocation
4. Lock contention

Dan Creswell (author of Blitz JavaSpaces) has collected a Distributed Systems Reading List. The list include references to key papers from Google, MySpace, eBay, Amazon, and also some distributed theory papers.

Google Scalability Conference on Google Video

It looks like the Seattle Conference on Scalability has made it onto Google Video.

Search for the sessions.

REST vs (sort of) SOAP: How to choose?

Summary: REST supports request/response (client/server) interactions best, message passing systems support asynchronous and peer-to-peer message communication systems best.

The first architectural constraint applied to derive REST is client/server. I don't think this can be understated, everything that follows tunes the architecture to provide an elegant request/response system with fantastic results. Many, many, systems are client/server - and those should take advantage of REST (and often HTTP).

Message passing systems involve sending a message (headers + body) to a destination. That may not involve a response message, or may involve a sophisticated set of response messages from various other parties to the originator. HTTP always pairs a request message with a response message; solidifying the client/server interaction.

SOAP (without WSDL and WS-*) is just a message container, and can be used to implement asynchronous and P2P message passing systems. See MEST and SSDL for good examples of using SOAP infrastructure without the WSDL and WS-* cooked right in.

Another useful message passing system I've recently began studying is AMQP. This standard is designed to provide the building blocks for message passing systems, an efficient binary protocol for low latency operations, and a protocol based interaction (instead of programming API). Implementations include: Qpid (Java, C++ and more clientes) and RabbitMQ (Erlang).

Of course, request/response can be built on message passing:

• like most WSDL services that expose RPC
  
• like many JMS systems with replyTo
  
• everything gets shipped over IP (Internet Protocol) anyway, so everything is message based at the bottom
  

and message passing can be built on client/server:

• an HTTP server can be bundled into a client (two inverted client/server relationships form a P2P connection)
• an HTTP server can be polled to simulate a peer message send

but in both of these situations it would be better to pick an architecture that actually matches the problem. (If you can)

Finally, when working on the public internet, it is often not the case that remote machines can listen for P2P messages (because of firewalls and and NAT). STUN is a notable exception, but requires programming on top of UDP (shouldn't there be some library support for this?).

My conclusion: inside the enterprise pick the right architecture, on the internet expose only a client/server RESTful architecture.

Intuitive Aspects: null checks

I've been a fan and user of AspectJ for many years. In fact my employer, New Aspects of Software, offers expert consulting on AspectJ and AOP systems.

Many excellent books and articles have been published on the topic. The one thing that seems to be missing is examples of Aspects that solve small problems so simply and clearly they can be "intuitively" understood. I'm setting out to start creating a small set of examples to fill that gap.

Problem: null values are annoying to track down.

Solution: The following policy should be applied to my code:

1. When a null argument is passed into a method, throw a NullPointerException.
2. When a null is returned from a method, throw a NullPointerException.
   

Java Implementation:
Simple and clear, but also verbose, error prone, and annoying.

public Item findItem(Service service, ItemPattern itemPattern) {
if (service == null || itemPattern == null)
    throw new NullPointerException("null argument!");

Item result=null;

if (service.hasItem(itemPattern))
result = service.getSingleItem(itemPattern);
else
result = service.getDefaultItem(); // may be null?

 if (result == null)
    throw new NullPointerException("null return!");

return result;
}

Now, repeat that in every method. Yuck.

AspectJ Implementation:

public aspect NullChecks {

 /**
  * Before the execution of any method in the com.mycompany packages
  */
 before(): execution(* com.mycompany..*.*(..)) {
  
  // Check for null args
  for (Object arg : thisJoinPoint.getArgs()) {
   if (arg == null) // throw a NullPointerException
    throw new NullPointerException("null argument!");
  }
 }


 /**
  * After returning from the execution of any method in the com.mycompany packages
  */
 after() returning(Object result): execution(Object com.mycompany..*.*(..)) {
  
  // Check for null result
  
  if (result == null) // throw a NullPointerException
   throw new NullPointerException("null argument!");
 }
}

Does this seem like a better solution? Have I reached "intuitive"?

Scalability at Amazon

Some fantastic references from the Google Scalability conference. See Dan Creswell's post.

I can't wait for the video.