| 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.

C-ORM: docs, API.

Last 100 entries

Credit Card Processing for Cat Soft LLC; Discover new movies on demand in our online cinema; Tasting; Credit Card Processing for Cat Soft LLC; Apple + Kiwi Jam; Hit Me; Increase Efficiency with GPS Vehicle Tracking for Cat Soft LLC; Sudoku - CSP + Chaos; Recycling Electronics In Santiago; Vector Displays in OpenGL; Call Center Services for Cat Soft LLC; And Anti-Aliased; OpenGL - Render via Intermediate Texture; And Garmin Connect; Using Garmin Forerunner 230 With Linux; Payroll Service Quotes for Cat Soft LLC; (Beating Dead Horse) StackOverflow; Current State of Justice in China; Now Is Cat Soft LLC's Chance To Save Up To 32% On Mail; Axiom of Determinacy; Ewww; Fee Chaos Book; Course on Differential Geometry; Increase Efficiency with GPS Vehicle Tracking for Cat Soft LLC; Okay, but...; Sparse Matrices, Deep Learning; Sounds Bad; Applebaum Rape; Tomato Chutney v4; Have to add...; Culturally Liberal and Nothing More; Weird Finite / Infinite Result; Your diamond is a beaten up mess; Maths Books; Good Bike Route from Providencia / Las Condes to Panul\; Iain Pears (Author of Complex Plots); Plum Jam; Excellent; More Recently; For a moment I forgot StackOverflow sucked; A Few Weeks On...; Chilean Book Recommendations; How To Write Shared Libraries; Jenny Erpenbeck (Author); Dijkstra, Coins, Tables; Python libraries error on OpenSuse; Deserving Trump; And Smugness; McCloskey Economics Trilogy; cmocka - Mocks for C; Concept Creep (Americans); Futhark - OpenCL Language; Moved / Gone; Fan and USB issues; Burgers in Santiago; The Origin of Icosahedral Symmetry in Viruses; autoenum on PyPI; Jars Explains; Tomato Chutney v3; REST; US Elections and Gender: 24 Point Swing; PPPoE on OpenSuse Leap 42.1; SuperMicro X10SDV-TLN4F/F with Opensuse Leap 42.1; Big Data AI Could Be Very Bad Indeed....; Cornering; Postcapitalism (Paul Mason); Black Science Fiction; Git is not a CDN; Mining of Massive Data Sets; Rachel Kaadzi Ghansah; How great republics meet their end; Raspberry, Strawberry and Banana Jam; Interesting Dead Areas of Math; Later Taste; For Sale; Death By Bean; It's Good!; Tomato Chutney v2; Time ATAC MX 2 Pedals - First Impressions; Online Chilean Crafts; Intellectual Variety; Taste + Texture; Time Invariance and Gauge Symmetry; Jodorowsky; Tomato Chutney; Analysis of Support for Trump; Indian SF; TP-Link TL-WR841N DNS TCP Bug; TP-Link TL-WR841N as Wireless Bridge; Sending Email On Time; Maybe run a command; Sterile Neutrinos; Strawberry and Banana Jam; The Best Of All Possible Worlds; Kenzaburo Oe: The Changeling; Peach Jam; Taste Test; Strawberry and Raspberry Jam; flac to mp3 on OpenSuse 42.1; Also, Sebald; Kenzaburo Oe Interview

© 2006-2015 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