Andrew Cooke: C[omp]ute

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

C[omp]ute

Personal Projects

Last 100 entries

HowTo Make POJO Workflows

Porqi - the POJO POrquestrator

Asynchronous Java