| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next

C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

Last 100 entries

LPIR - Steganography in Practice; How I Am 6; Clear Explanation of Verizon / Level 3 / Netflix; Teenage Girls; Formalising NSA Attacks; Switching Brakes (Tektro Hydraulic); Naim NAP 100 (Power Amp); AKG 550 First Impressions; Facebook manipulates emotions (no really); Map Reduce "No Longer Used" At Google; Removing RAID metadata; New Bike (Good Bike Shop, Santiago Chile); Removing APE Tags in Linux; Compiling Python 3.0 With GCC 4.8; Maven is Amazing; Generating Docs from a GitHub Wiki; Modular Shelves; Bash Best Practices; Good Emergency Gasfiter (Santiago, Chile); Readings in Recent Architecture; Roger Casement; Integrated Information Theory (Or Not); Possibly undefined macro AC_ENABLE_SHARED; Update on Charges; Sunburst Visualisation; Spectral Embeddings (Distances -> Coordinates); Introduction to Causality; Filtering To Help Colour-Blindness; ASUS 1015E-DS02 Too; Ready Player One; Writing Clear, Fast Julia Code; List of LatAm Novels; Running (for women); Building a Jenkins Plugin and a Jar (for Command Line use); Headphone Test Recordings; Causal Consistency; The Quest for Randomness; Chat Wars; Real-life Financial Co Without ACID Database...; Flexible Muscle-Based Locomotion for Bipedal Creatures; SQL Performance Explained; The Little Manual of API Design; Multiple Word Sizes; CRC - Next Steps; FizzBuzz; Update on CRCs; Decent Links / Discussion Community; Automated Reasoning About LLVM Optimizations and Undefined Behavior; A Painless Guide To CRC Error Detection Algorithms; Tests in Julia; Dave Eggers: what's so funny about peace, love and Starship?; Cello - High Level C Programming; autoreconf needs tar; Will Self Goes To Heathrow; Top 5 BioInformatics Papers; Vasovagal Response; Good Food in Vina; Chilean Drug Criminals Use Subsitution Cipher; Adrenaline; Stiglitz on the Impact of Technology; Why Not; How I Am 5; Lenovo X240 OpenSuse 13.1; NSA and GCHQ - Psychological Trolls; Finite Fields in Julia (Defining Your Own Number Type); Julian Assange; Starting Qemu on OpenSuse; Noisy GAs/TMs; Venezuela; Reinstalling GRUB with EFI; Instructions For Disabling KDE Indexing; Evolving Speakers; Changing Salt Size in Simple Crypt 3.0.0; Logarithmic Map (Moved); More Info; Words Found in Voynich Manuscript; An Inventory Of 3D Space-Filling Curves; Foxes Using Magnetic Fields To Hunt; 5 Rounds RC5 No Rotation; JP Morgan and Madoff; Ori - Secure, Distributed File System; Physical Unclonable Functions (PUFs); Prejudice on Reddit; Recursion OK; Optimizing Julia Code; Cash Handouts in Brazil; Couple Nice Music Videos; It Also Works!; Adaptive Plaintext; It Works!; RC5 Without Rotation (2); 8 Years...; Attack Against Encrypted Linux Disks; Pushing Back On NSA At IETF; Summary of Experimental Ethics; Very Good Talk On Security, Snowden; Locusts are Grasshoppers!; Vagrant (OpenSuse and IDEs); Interesting Take On Mandela's Context; Haskell Cabal O(n^2) / O(n) Fix; How I Am 4

© 2006-2013 Andrew Cooke (site) / post authors (content).

HowTo Make POJO Workflows

From: "andrew cooke" <andrew@...>

Date: Tue, 16 Jan 2007 11:44:16 -0300 (CLST)

I think I just solved the POJO workflow problem.  I'm not sure this works
(in particular, I'm not sure how it would interact with transactions), but
if it does it would be amazingly sweet.

OK, so the problem is that if you're doing lightweight SOA, you write
services as POJOs.  That's fine for "one shot" services that have no
persistent state between messages, but doesn't work so well for services
that need to maintain conversational state - typically these are composite
services (orchestrators) which call one service ("synchronously") and then
another.

The root of the problem is the "synchronous" call.  This can be
constructed from asynchronous messaging using "replyTo" in an envelope -
no problem there - but the replyTo identifies an *instance*.  So if the
instance dies while the call is being made, the return value has nowhere
to go.

And the obvious solution is to explicitly store state before calls and use
some kind of index to retrieve state for the response.  But this requires
(as far as I can tell, until now) explicit management of state inside the
POJO, or the use of a separate workflow (eg. BPEL engine).

The alternative is to somehow convert a POJO so that it stores state
transparently.  How to do this has not been clear 'til now, although it's
pretty obvious that continuations would be a component.

So.  Here's the trick.  You wrap the *called* service (typically injected
via Spring) in a dynamic proxy which preserves the interface but, when
called:
- triggers a new thread to continue with processing in the injected class
(which is presumably an adapter to call messaging).
- constructs a continuation in the old thread and then throws a runtime
exception (is this exception necessary?  perhaps the wrapper simply stores
the continuation?)

The composite service is itself wrapped in a dynamic proxy which catches
the exception raised at the bean's entry point.

When the response comes back to the wrapper around the called service it
collaborates with the wrapper around the caller bean (or if the exception
is not necessary, simply retrieves the continuation itself) to restart the
process.

Obviously a lot of details need still to be worked out :o)

But the hard part has always been, until now, how to get the continuation
in the right place.  This was hard because I was looking at the composite
service.  What is new here is the idea that you have a wrapper around the
target service (or rather, its messaging adapter).

For background on the problem see http://www.acooke.org/cute/NotesonSta0.html

Andrew

Porqi - the POJO POrquestrator

From: "andrew cooke" <andrew@...>

Date: Sun, 21 Jan 2007 19:45:59 -0300 (CLST)

I've started work on a small library to implement this.  It assumes Spring
and uses factories and dynamic proxies to wrap POJOs.

So far I have the basic framework - the wrapper factories - almost
complete.  Next I need to add a strategy for a particular continuation
library that will be responsible for managing threads, state etc.  The
first implementation will do nothing, of course, but will allow testing. 
The persistence will be a separate pluggable strategy.

The code is pretty cute - it's amazing the level of metaprogramming
possible in pure Java (well, not so pure with the continuation libraries).

Andrew

Asynchronous Java

From: "andrew cooke" <andrew@...>

Date: Tue, 30 Jan 2007 08:27:19 -0300 (CLST)

This works - at least, I've just got some test cases running with a
library that converts Java from sychronous to asynchronous calls.  I don't
yet have the stored state, but that should be a small amount of additional
work (the architecture is modular - I just need continuations based thread
manager).

Here's the test code.  Depending on whether "Pojo" is injected into
"Composite" via a service method or not (ie one specified in the
interface) it is called either synchronously or asynchronously.

  public void testSynchronousCall() throws Throwable {
    assertEquals(1, service.callCount(Target.COMPONENT));
    assertTrue(service.sameThreadName(Target.COMPONENT));
    assertEquals(3, service.callCount(Target.COMPONENT));
  }

  public void testAsynchronousCall() throws Throwable {
    assertEquals(1, service.callCount(Target.SERVICE));
    assertFalse(service.sameThreadName(Target.SERVICE));
    assertEquals(3, service.callCount(Target.SERVICE));
  }

public interface CompositeIface {
  boolean sameThreadName(Target target);
  int callCount(Target target);
  public void setService(PojoIface service);
}

public interface PojoIface {
  String threadName();
  int callCount();
}

Andrew

Comment on this post